Warum die Präsenz heute eine Weile down war...
Diesen Beitrag schrieb ich 12 Jahre und 3 Monate zuvor; die nachfolgenden Ausführungen müssen heute nicht unbedingt noch genau so funktionieren. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
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…