“Error: Boot loader didn’t return any data” when booting up Xen guest

Error: Boot loader didn't return any data

I have come across this error two or three times before, and each time I spend hours trying to figure out how to get my virtual machine to boot.  This blog post is just to document a fix so that I can refer back to it, and hopefully it will help people out if they’re experiencing the issue as well.

I have a Xen server with a Debian 6 guest, booted using pygrub.  This error is shown usually after an (kernel) update on the guest and the boot configuration automatically regenerates in a format that is incompatible with pygrub.

The quickest way I’ve fixed it is by editing the /boot/grub/menu.lst file in the guest. You can access this by mounting the guest filesystem on the host (if using LVM, something like mount /dev/vg0/guest_img /mnt/guesttest).

At the top of the file, I believe Xen puts its own configuration in, which works.  This is an example of what I have:

[code]
default=0
timeout=10
title vmlinuz-2.6.32-5-amd64
root (hd0)
kernel /boot/vmlinuz-2.6.32-5-amd64 console=hvc0 root=/dev/xvda1 ro
initrd /boot/initrd.img-2.6.32-5-amd64
[/code]

First, check that these paths are pointing to the correct kernel version. If you do a kernel upgrade or a distribution upgrade but didn’t overwrite this file, you may need to update this manually.

After that, there are other options in the “automagic kernels list”. At the bottom of the list there may be one or more generated options. I just commented those out like so:

[code firstline=”100″]
#title Debian GNU/Linux, kernel 2.6.32-5-amd64
#root (/dev/xvda1)
#kernel /boot/vmlinuz-2.6.32-5-amd64 root=UUID=a85d0414-770e-4fa4-9473-b4b99b6fb987 ro
#initrd /boot/initrd.img-2.6.32-5-amd64</code>

#title Debian GNU/Linux, kernel 2.6.32-5-amd64 (single-user mode)
#root (/dev/xvda1)
#kernel /boot/vmlinuz-2.6.32-5-amd64 root=UUID=a85d0414-770e-4fa4-9473-b4b99b6fb987 ro single
#initrd /boot/initrd.img-2.6.32-5-amd64

### END DEBIAN AUTOMAGIC KERNELS LIST
[/code]

Save the file, and unmount the filesystem. The virtual machine should then boot!

A preventative measure for this is to edit the file when you update the kernel so that you don’t get stuck on a reboot.

Related

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.