Warum die Präsenz heute eine Weile down war…

Ein Beitrag aus der Sektion »Techno-Babbel« — ich habe da so ein cleveres Script: es meldet mir, wenn ein Kernel-Update durchgeführt wurde und indessen 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, veranlaßte ich vorhin den Reboot — mit dem Ergebnis, daß 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 mußte also der grub gefixt werden, was ich in diesem Falle folgendermaßen gemacht habe:

Ich habe zwei (relevante) Images fürs System: eines für das Hauptsystem (system.img) und eines für /var (var.img), die 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 bißchen Update :-(