Ubuntu 12.04 Bootprobleme bei Xen-DomU nach Kernelupgrade
Das hat mich schon etwas Zeit gekostet. Ich habe einen Xen-Host mit
Ubuntu 12.04, auf dem mehrere Xen-DomU laufen. Auf einer davon habe ich
mit apt-get dist-upgrade unter anderem den Kernel aktualisiert. Mit
dem Ergebnis, das nach init 6 die DomU nicht mehr startete.
Expliziter Start auf der Dom0 brachte das hier:
$ sudo xm create openldaptest.cfg
Using config file "/etc/xen/openldaptest.cfg".
Error: Boot loader didn't return any data!
Die Logdatei /var/log/xen/xend.log gab auch nichts Interessantes her.
Pygrub kann ich auch von Hand starten, mal sehen, was das bringt:
$ sudo /usr/bin/pygrub -n /dev/camion/openldaptest
Using <class 'grub.GrubConf.Grub2ConfigFile'> to parse
/boot/grub/grub.cfg
WARNING:root:Unknown directive load_video
WARNING:root:Unknown directive terminal_output
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive export
WARNING:root:Unknown image directive recordfail
WARNING:root:Unknown image directive gfxmode
WARNING:root:Unknown image directive recordfail
WARNING:root:Unknown directive submenu
WARNING:root:Unknown image directive recordfail
WARNING:root:Unknown image directive gfxmode
WARNING:root:Unknown image directive recordfail
Traceback (most recent call last):
File "/usr/bin/pygrub", line 763, in <module>
raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel
Das ist schon mal interessant. Pygrub findet keine Partition, die einen Kernel enthält, hat aber die Datei /boot/grub/grub.cfg von der richtigten Partition in der Mangel. Vergleiche ich das mit den Meldungen von pygrub bei einem funktionierenden System,
Using <class 'grub.GrubConf.Grub2ConfigFile'> to parse
/boot/grub/grub.cfg
WARNING:root:Unknown directive load_video
WARNING:root:Unknown directive terminal_output
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive export
WARNING:root:Unknown image directive recordfail
WARNING:root:Unknown image directive gfxmode
WARNING:root:Unknown image directive recordfail
WARNING:root:Unknown image directive linux16
WARNING:root:Unknown image directive linux16
WARNING:root:Unknown directive else
WARNING:root:Unknown directive else
WARNING:root:Unknown directive source
Dann fällt als erste unterschiedliche Zeile beim nicht funktionierenden
System die Zeile mit Unknown directive submenu auf. Also schaue ich
in /boot/grub/grub.cfg nach, wo dort submenu steht.
Da in dem LVM-Container für die Systemplatte Xen-DomU das Abbild der gesamten Platte mit mehreren Partitionen enthalten ist, muss ich zunächst den Offset zur Systempartition ermitteln. Das geht relativ einfach so, wie im QEMU-Buch beschrieben:
$ sudo fdisk -lu /dev/camion/openldaptest
Disk /dev/camion/openldaptest: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders, total 8388608 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0006d275
Device Boot Start End Blocks Id System
/dev/camion/openldaptest1 2048 7706623 3852288 83 Linux
/dev/camion/openldaptest2 7708670 8386559 338945 5 Extended
Partition 2 does not start on physical sector boundary.
/dev/camion/openldaptest5 7708672 8386559 338944 82 Linux swap / Solaris
$ expr 512 \* 2048
1048576
$ sudo mkdir /tmp/mnt
$ sudo mount /dev/camion/openldaptest /tmp/mnt -o loop,offset=1048576
Noch einfacher geht das mit diesem Skript von pixelbeat.org.
Damit konnte ich das Dateisystem der fehlerhaften DomU bequem anschauen und bearbeiten.
$ sudo chroot /tmp/mnt
# grep submenu /boot/grub/grub.cfg
submenu "Previous Linux versions" {
Das ist zumindest ein Hinweis. Die Directive submenu hängt mit älteren Kernelversionen zusammen.
# ls /boot
System.map-3.2.0-33-generic initrd.img-3.2.0-33-generic
System.map-3.2.0-35-generic initrd.img-3.2.0-35-generic
abi-3.2.0-33-generic memtest86+.bin
abi-3.2.0-35-generic memtest86+_multiboot.bin
config-3.2.0-33-generic vmlinuz-3.2.0-33-generic
config-3.2.0-35-generic vmlinuz-3.2.0-35-generic
grub
Zum Test kopiere ich eine Datei grub.cfg von einer Sicherung über die
/boot/grub/grub.cfg und ändere alle Vorkommen von 3.2.0-33 in
3.2.0-35. Anschließend verlasse ich die chroot-Umgebung, hänge
die Systempartition der DomU aus und teste pygrub damit:
$ sudo pygrub -n /dev/camion/openldaptest
+------------------------------------------------------------------------+
| Ubuntu, with Linux 3.2.0-35-generic |
| Ubuntu, with Linux 3.2.0-35-generic (recovery mode) |
| Memory test (memtest86+) |
| Memory test (memtest86+, serial console 115200) |
+------------------------------------------------------------------------+
Use the - and . keys to select which entry is highlighted.
Press enter to boot the selected OS, 'e' to edit the
commands before booting, 'a' to modify the kernel arguments
before booting, or 'c' for a command line.
Damit haben wir das Problem erledigt. Nun funktioniert auch der Neustart mit xm:
$ sudo xm create openldaptest.cfg
Using config file "/etc/xen/openldaptest.cfg".
Started domain openldaptest (id=21)
Natürlich habe ich noch das alte Kernel-Image mit apt-get autoremove
entfernt.