One of our users at Loeniks managed to break his Debian VM. After upgrading to Debian 6, he tried upgrading his bootloader to Grub 2. XenServer’s paravirtualized bootloader (pygrub) is unable to handle the newest version of the Grub bootloader in virtual machines, this results in a nice and cryptic error message:
ERROR:Using <class \'grub.GrubConf.GrubConfigFile\'> to parse /grub/menu.lst: [ Traceback (most recent call last):; File \"/usr/bin/pygrub\", line 746, in ?; raise RuntimeError, \"Unable to find partition containing kernel\"; RuntimeError: Unable to find partition containing kernel; ]
At first I wanted to loopback mount the VM’s disk. Google’s results didn’t really point me in the right direction, so I was more or less forced to mess around. Thankfully, my next hunch was to use tabcompletion in it’s most optimal form…
One of the commands returned was xe-edit-bootloader. It seemed too good to be true, but it ended up being the tool I was looking for.
# xe-edit-bootloader Usage: /opt/xensource/bin/xe-edit-bootloader [-u <VM UUID>] [-n <VM name] [-p <partition number>] [-f <filename>] -u: UUID of the VM boot disk you wish to edit -n: Name label of the VM boot disk you wish to edit -p: Partition number to mount (default: none) -f: Location of bootloader config file to edit (defaults: /boot/grub/menu.lst /grub/menu.lst) Either -u or -n must be supplied to specify the VM to edit Set the EDITOR environment variable if desired (default: nano)
-u or -n specifies which VM’s bootloader you want to edit. A list of available VMs can be shown using xe:
# xe vm-list uuid ( RO) : 5e5fc41d-2c42-036a-a342-f0e6f424e7e7 name-label ( RW): Vetinari power-state ( RO): halted
This is one of my own VMs I keep around for testing purposes :) With -p you say in which partition the grub configuration is supposed to reside, usually this is either 0 or 1, but is is more or less dependent on who installed the VM, and how he chose to do so.
All you need to do now is pass on the EDITOR variable so you’ll be able to use a decent editor.
EDITOR=vi xe-edit-bootloader -n Vetinari -p 1
You can now remove the lines that chainload the grub2 loader so that the kernels -that should still be present in the configuration- can now be loaded again. If everything wasn done correctly, XenServer should be able to boot the VM again.