Warum die Präsenz heute eine Weile down war…

Ich habe da so ein cleveres Script: es meldet mir, wenn ein Kernel-Update durchgeführt wurde und daher ein Reboot der Maschine fällig ist. Reboots sind unentspannt oft notwendig bei einem Ubuntu-System, aber über Monate hinweg keine Updates zu machen ist auch suboptimal. Also gut.

Nachdem ich das Nölen des Cron-Jobs („Nun reboote die verdammte Kiste doch endlich!“) lange genug ignoriert hatte, veranlasste ich vorhin den Reboot — mit dem Ergebnis, dass die Maschine nicht mehr hochkam. Einloggen auf dem Hostsystem, per xvncviewer draufgeguckt — schwarzer Bildschirm, weißer Cursor (der nichtmal blinkte). Und als das System, das üblicherweise innerhalb von einer halben Minute durchgebootet hat, nach sechs Minuten noch immer nicht wieder lief wurde mir klar: wir haben ein Problem.

Um es kurz zu machen: es war ein Zusammenspiel von zwei Faktoren. Zum einen hat das Update mir den grub zerschossen, und zum anderen wurde ein Kernel installiert, der (bei gefixtem grub) beim Booten bei Freeing unused kernel memory einfach stehen bleibt. Als erstes musste also der grub gefixt werden, was ich in diesem Falle folgendermaßen gemacht habe: ich habe zwei (relevante) Images fürs System – ein system.img für das Hauptsystem und ein var.img für /var – die jeweils gemountet werden müssen.

$ file system.img var.img 
system.img: x86 boot sector; partition 1: ID=0x83, active, starthead 1, startsector 63, 31455207 sectors
var.img:  x86 boot sector; partition 1: ID=0x83, starthead 1, startsector 63, 41929587 sectors

Die müssen mit Offset gemountet werden, also erstmal die Offsets rausfinden:

$ parted system.img unit B print
Model:  (file)
Disk /vm/ux/system.img: 16106127360B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number  Start   End           Size          Type     File system  Flags
 1      32256B  16105098239B  16105065984B  primary  ext3         boot

$ parted var.img unit B print
Model:  (file)
Disk /vm/ux/var.img: 21474836480B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number  Start   End           Size          Type     File system  Flags
 1      32256B  21467980799B  21467948544B  primary  xfs

So, und mit dieser Information können die Images nun auch gemountet werden:

$ mount system.img /mnt -o loop,dev,offset=32256B -t ext3<
$ mount var.img /mnt/var -o loop,offset=32256B -t xfs
$ mount --bind /dev /mnt/dev

Dann ein chroot in das gemountete System vornehmen, /proc mounten, grub-pc rausschmeißen und grub installieren:

$ chroot /mnt
chroot$ mount /proc
chroot$ dpkg -P grub-pc
chroot$ apt-get install grub
chroot$ exit

Damit verlassen wir das chroot und befinden uns wieder im Host-System. Jetzt müssen wir den MBR irgendwie in das System-Image stopfen. Dazu schnappen wir uns schonmal die UUID des Boot-Devices — die finden wir in der fstab des Gast-Systems, also im konkret vorliegenden Falle in /mnt/etc/fastab (nach dem Eintrag für / schauen). Das ist nun der wirklich unschöne Part an der Sache:

$ cd /tmp
$ echo "(hd0) system.img" >> device.map
$ grub --device-map=/tmp/device.map
grub>root (hd0,0)
grub>setup (hd0)
grub>quit
$ echo "(hd0) UUID=$UUID" >> /mnt/boot/grub/device.map
$ chroot /mnt
chroot$ update-grub
chroot$ exit

Danach zur Sicherheit die erzeugte menu.lst nochmal prüfen; insbesondere ist es sinnvoll, die quiet– und splash-Einträge rauslöschen, damit beim Booten auch ersichtlich ist, was schief geht. Bzgl. des Kernels, der komische Dinge tut: hier genügte es (vorerst), im grub ESC zu machen und den bisherigen Kernel auszuwählen — der funktioniert weiterhin anstandslos. Dann die Images unmounten:

$ umount /mnt/dev
$ umount /mnt/var
$ umount /mnt/proc
$ umount /mnt

Jetzt kann die VM wieder wie gewohnt gestartet werden. Bei mir lief hernach wieder alles. Ziemlich viel Affentanz für so ein bisschen Update…