Bug#604080: Xen domU fails to boot after install

November 19th, 2010 - 07:30 pm ET by Daniel Pocock | Report spam
Package: installation-reports

I have an amd64 dom0 with lenny

I successfully run the Debian Installer in a fresh domU

xm create -c xm-squeeze1.cfg install=true
install-mirror=http://mirror.positive-internet.com/debian
install-installer=http://ftp.nl.debian.org/debian/dis...nt/images/



I then tried to do the first boot:

xm create -c xm-squeeze1.cfg


I get this error:

Error: Boot loader didn't return any data!

Root causes:
- Squeeze installs grub 2, which doesn't have any /boot/grub/menu.lst
- pygrub can't seem to identify the boot partition in the MBR created by
the installer
- pygrub on lenny is looking for /boot/grub/menu.lst (actually,
/grub/menu.lst on the bootable partition)

Workaround 1:
- mount the filesystem, possibly using kpartx, manually create
/boot/grub/menu.lst
- tweak the cfg file to tell pygrub to look in the /boot partition
(because it doesn't recognise the grub2 MBR)

bootargs = '/dev/mapper/vg00-squeeze1_disk0p1'

Workaround 2:
- mount the filesystem, possibly using kpartx
- copy the kernel and initrd to the dom0
- modify the cfg file, tell it to use the kernel and initrd from the
dom0 and not use pygrub as bootloader

Suggestions:
- the MBR should be recognisable by the lenny version of pygrub
- better error needed from pygrub when it doesn't find menu.lst
- maybe grub2 should create menu.lst for backwards compatibility? or
maybe some optional tool in the domU can create it?
- maybe a support package is needed for lenny dom0 users? and a helpful
message to let them know it exists?







To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 11 repliesReplies Make a reply

Similar topics

Replies

#1 Ian Campbell
November 20th, 2010 - 06:40 am ET | Report spam

Hi Daniel,

On Sat, 2010-11-20 at 01:17 +0100, Daniel Pocock wrote:
Package: installation-reports

I have an amd64 dom0 with lenny

I successfully run the Debian Installer in a fresh domU

xm create -c xm-squeeze1.cfg install=true
install-mirror=http://mirror.positive-internet.com/debian
install-installer=http://ftp.nl.debian.org/debian/dis...nt/images/



I then tried to do the first boot:

xm create -c xm-squeeze1.cfg


I get this error:

Error: Boot loader didn't return any data!



Unfortunately the version of pygrub in Lenny does not understand grub2
configuration files. You are quite correct that the error message is
rubbish. FWIW it's likely that /var/log/xen/xend.log contains more
information from pygrub, although those messages are also not always
terribly helpful either...

You should be able to cause Squeeze to install grub1 (aka grub-legacy),
although it may be an expert mode installation option only which is less
convenient.

http://d-i.alioth.debian.org/manual...pbs04.html describes how
you can pressed the installation to install grub-legacy instead of grub2
and I think anything you can do in a preseed file you can also add to
the kernel command line when running the installer, so that might be
worth a go.

Root causes:
- Squeeze installs grub 2, which doesn't have any /boot/grub/menu.lst
- pygrub can't seem to identify the boot partition in the MBR created by
the installer



pygrub doesn't care about the contents of the MBR as such, it just
parses the partition table and AFAIK pygrub does know how to find the
bootable partition. There should be nothing Squeeze or grub[12] specific
about this aspect of things,

I think it's just that the pygrub in Lenny doesn't know about grub2
(since Lenny predates any serious consideration of grub2) so doesn't
find any configuration it understands once it has found the right
partition.

- pygrub on lenny is looking for /boot/grub/menu.lst (actually,
/grub/menu.lst on the bootable partition)



pygrub is aware of separate /boot configurations so it will try each
of /boot/grub/* and /grub/* looking for a configuration file.

Workaround 1:
- mount the filesystem, possibly using kpartx, manually create
/boot/grub/menu.lst



or "apt-get install grub-legacy" and let it generate menu.lst for you.

- tweak the cfg file to tell pygrub to look in the /boot partition
(because it doesn't recognise the grub2 MBR)

bootargs = '/dev/mapper/vg00-squeeze1_disk0p1'

Workaround 2:
- mount the filesystem, possibly using kpartx
- copy the kernel and initrd to the dom0
- modify the cfg file, tell it to use the kernel and initrd from the
dom0 and not use pygrub as bootloader



The only other workaround I can think of is to grab the pygrub from a
Squeeze system and use that on your Lenny system. Not great either

Suggestions:
- the MBR should be recognisable by the lenny version of pygrub
- better error needed from pygrub when it doesn't find menu.lst



Yes, this is something Xen upstream is aware of but its one of those
tasks which never quite floats to the top of the list :-(

- maybe grub2 should create menu.lst for backwards compatibility? or
maybe some optional tool in the domU can create it?
- maybe a support package is needed for lenny dom0 users? and a helpful
message to let them know it exists?



Thanks,
Ian.

Ian Campbell

Dibble's First Law of Sociology:
Some do, some don't.







To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#2 Daniel Pocock
November 20th, 2010 - 01:00 pm ET | Report spam
Hi Ian, thanks for the prompt feedback

I've provided more details about some of those points below

Ultimately, I believe Debian 5 (lenny) is still a supported option for
people after the release of squeeze and up to the release date of Debian 7.

For me, this was the only bad experience I had during the install. It
would seem like a great shame not to provide a convenient way for people
to get lenny and squeeze on the same system.

I might be willing to have a deeper look at the problem and see if I can
improve the error messages, etc. However, if such a patch was produced,
would it be adopted in lenny so that users who keep their systems up to
date will be able to run this without effort?

Is it feasible to include some kind of grub1-emulator package in
squeeze, something that lets the squeeze system use grub2, but creating
a valid menu.lst file for pygrub to find? I think this would provide
the smoothest experience for the users who just want the lenny/squeeze
dom0/domU thing to work.

I then tried to do the first boot:

xm create -c xm-squeeze1.cfg


I get this error:

Error: Boot loader didn't return any data!




Unfortunately the version of pygrub in Lenny does not understand grub2
configuration files. You are quite correct that the error message is
rubbish. FWIW it's likely that /var/log/xen/xend.log contains more
information from pygrub, although those messages are also not always
terribly helpful either...




xend.log only told me the pygrub command line, but not the root cause of
the problem

I had to figure it out with Google and guesswork

You should be able to cause Squeeze to install grub1 (aka grub-legacy),
although it may be an expert mode installation option only which is less
convenient.



I can chroot the domU and get grub-legacy, but I'm hesitant to run any
grub commands within the chroot out of concern that it will impact the
dom0's MBR
http://d-i.alioth.debian.org/manual...pbs04.html describes how
you can pressed the installation to install grub-legacy instead of grub2
and I think anything you can do in a preseed file you can also add to
the kernel command line when running the installer, so that might be
worth a go.




Ok, thanks for that suggestion - I will try that too method too
Root causes:
- Squeeze installs grub 2, which doesn't have any /boot/grub/menu.lst
- pygrub can't seem to identify the boot partition in the MBR created by
the installer




pygrub doesn't care about the contents of the MBR as such, it just
parses the partition table and AFAIK pygrub does know how to find the
bootable partition. There should be nothing Squeeze or grub[12] specific
about this aspect of things,



I tried invoking the pygrub script directly against the LV and the
partition within the LV:

/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0
gives an error

kpartx -a /dev/mapper/vg00-squeeze1_disk0 &&
/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0p1
finds the menu.lst I created manually, and displays the menu

If it is not an MBR issue on squeeze1_disk0, why doesn't pygrub find the
boot partition and menu.lst? Does grub2 do anything else to the
partition table? If I run fdisk on that partition table, it complains
about cylinder boundaries:

fdisk /dev/mapper/vg00-squeeze1_disk0

Command (m for help): p

Disk /dev/mapper/vg00-squeeze1_disk0: 6979 MB, 6979321856 bytes
255 heads, 63 sectors/track, 848 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0000373f

Device Boot Start End
Blocks Id System
/dev/mapper/vg00-squeeze1_disk0p1 * 1 32
248832 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/mapper/vg00-squeeze1_disk0p2 32 849
6563841 5 Extended
Partition 2 does not end on cylinder boundary.
/dev/mapper/vg00-squeeze1_disk0p5 32 849
6563840 8e Linux LVM






To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#3 Ian Campbell
November 22nd, 2010 - 08:40 am ET | Report spam
On Sat, 2010-11-20 at 18:48 +0100, Daniel Pocock wrote:

Ultimately, I believe Debian 5 (lenny) is still a supported option for
people after the release of squeeze and up to the release date of
Debian 7.



oldstable is generally supported for a little while after a new stable
release but it is a very much more frozen/conservative style support
even than stable, which is in itself quite conservative in what it takes
in updates. The bar for taking fixes into oldstable is high and is
focused on security fixes and super-critical issues etc.

I might be willing to have a deeper look at the problem and see if I can
improve the error messages, etc. However, if such a patch was produced,
would it be adopted in lenny so that users who keep their systems up to
date will be able to run this without effort?



Ultimately it would be up to the Xen package maintainer and subsequently
the stable release maintainers. I think the first step towards
convincing the Xen maintainer to take patches of this type would be
resolving the issue upstream.

I guess it would depend on how large/intrusive the patch ended up being
so its hard to say up front but personally I have my doubts that a fix
for the pygrub logging crapness issue would make it into Lenny at this
stage of Lenny's life.

However it is still valuable to fix these things either upstream or in
the Debian unstable packaging, even if they cannot go into the current
stable version, so that a future version of Debian can benefit from the
fixes.

Is it feasible to include some kind of grub1-emulator package in
squeeze, something that lets the squeeze system use grub2, but creating
a valid menu.lst file for pygrub to find? I think this would provide
the smoothest experience for the users who just want the lenny/squeeze
dom0/domU thing to work.



I'm sure it would be technically possible but I'm not sure if the grub2
package maintainers would go for it, it would be a largish maintenance
burden for them which is needed only to support Xen.

If you can make the preseeding on the installer command line thing work
I would certainly be open to taking a patch to the Squeeze xm-debian.cfg
example file to detect a Lenny dom0 somehow and automatically append the
necessary runes.

> You should be able to cause Squeeze to install grub1 (aka grub-legacy),
> although it may be an expert mode installation option only which is less
> convenient.
>
I can chroot the domU and get grub-legacy, but I'm hesitant to run any
grub commands within the chroot out of concern that it will impact the
dom0's MBR



I think it won't but I certainly understand the concern!

>> Root causes:
>> - Squeeze installs grub 2, which doesn't have any /boot/grub/menu.lst
>> - pygrub can't seem to identify the boot partition in the MBR created by
>> the installer
>>
>
> pygrub doesn't care about the contents of the MBR as such, it just
> parses the partition table and AFAIK pygrub does know how to find the
> bootable partition. There should be nothing Squeeze or grub[12] specific
> about this aspect of things,
>
I tried invoking the pygrub script directly against the LV and the
partition within the LV:

/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0
gives an error

kpartx -a /dev/mapper/vg00-squeeze1_disk0 &&
/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0p1
finds the menu.lst I created manually, and displays the menu



This manually created menu.lst was present in the pygrub example just
above too?

If it is not an MBR issue on squeeze1_disk0, why doesn't pygrub find the
boot partition and menu.lst?



A bug in pygrub rather than anything to do with the content of the
MBR/partition-table. I think we can trust that the Squeeze installer is
creating a partition table which a physical system would be happy to
boot correctly (otherwise there would be a lot of noise being made!) and
pygrub should/must not need anything more special.

I'm pretty certain this works in more recent pygrubs although I don't
see an obvious smoking gun in the diff between the two. It might be
interesting to instrument up the various probing functions of pygrub and
see why it is rejecting the bootable partition.

I don't have any Lenny domain 0 systems handy but I'm going to install a
Squeeze VM on the system I do have and try running the Lenny pygrub on
it to see if I can reproduce the issue. Your Squeeze VM is a pretty
straight forward "mostly pressed enter" installation, right?

Does grub2 do anything else to the partition table?



I don't know, but partitioning is more a function of the installer (or
the advanced user if they go manual) than grub so I'd expect not.

If I run fdisk on that partition table, it complains
about cylinder boundaries:



I don't know if that indicates a real problem. Cylinder boundaries is a
bit of an obsolete concept for an LVM volume anyway.

Ian.


fdisk /dev/mapper/vg00-squeeze1_disk0

Command (m for help): p

Disk /dev/mapper/vg00-squeeze1_disk0: 6979 MB, 6979321856 bytes
255 heads, 63 sectors/track, 848 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0000373f

Device Boot Start End
Blocks Id System
/dev/mapper/vg00-squeeze1_disk0p1 * 1 32
248832 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/mapper/vg00-squeeze1_disk0p2 32 849
6563841 5 Extended
Partition 2 does not end on cylinder boundary.
/dev/mapper/vg00-squeeze1_disk0p5 32 849
6563840 8e Linux LVM







Ian Campbell
Current Noise: Razor Of Occam - Bite Of Dogmata

"What I've done, of course, is total garbage."




To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#4 Daniel Pocock
November 22nd, 2010 - 04:20 pm ET | Report spam
Ian Campbell wrote:
On Sat, 2010-11-20 at 18:48 +0100, Daniel Pocock wrote:


Ultimately, I believe Debian 5 (lenny) is still a supported option for
people after the release of squeeze and up to the release date of
Debian 7.




oldstable is generally supported for a little while after a new stable
release but it is a very much more frozen/conservative style support
even than stable, which is in itself quite conservative in what it takes
in updates. The bar for taking fixes into oldstable is high and is
focused on security fixes and super-critical issues etc.




I agree with this policy - and I think that any solution should respect
that, while simultaneously aiming to make life easier for people mixing
lenny and squeeze. For many people, virtualization is quite normal
nowadays, and installing into a domU will be their first experience of
squeeze (like for me).

A solution that respects that would simply display some more definite
error messages, maybe directing people to get an additional support
package or obtain a fresher pygrub from backports, maybe with the full
pathname of some README file that gives step by step instructions.


Is it feasible to include some kind of grub1-emulator package in
squeeze, something that lets the squeeze system use grub2, but creating
a valid menu.lst file for pygrub to find? I think this would provide
the smoothest experience for the users who just want the lenny/squeeze
dom0/domU thing to work.




I'm sure it would be technically possible but I'm not sure if the grub2
package maintainers would go for it, it would be a largish maintenance
burden for them which is needed only to support Xen.



I agree it is not the prettiest solution
If you can make the preseeding on the installer command line thing work
I would certainly be open to taking a patch to the Squeeze xm-debian.cfg
example file to detect a Lenny dom0 somehow and automatically append the
necessary runes.




I'm going to do another test run shortly and I'll try that approach and
share the results.

Root causes:
- Squeeze installs grub 2, which doesn't have any /boot/grub/menu.lst
- pygrub can't seem to identify the boot partition in the MBR created by
the installer




pygrub doesn't care about the contents of the MBR as such, it just
parses the partition table and AFAIK pygrub does know how to find the
bootable partition. There should be nothing Squeeze or grub[12] specific
about this aspect of things,




I tried invoking the pygrub script directly against the LV and the
partition within the LV:

/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0
gives an error

kpartx -a /dev/mapper/vg00-squeeze1_disk0 &&
/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0p1
finds the menu.lst I created manually, and displays the menu




This manually created menu.lst was present in the pygrub example just
above too?




In both attempts, it is the same raw disk - I have tried those commands
several times

kpartx seems quite content with the partition table, it successfully
creates the p1 device node from it. pygrub, on the other hand, can't
find the partition by itself when given the whole disk.


If it is not an MBR issue on squeeze1_disk0, why doesn't pygrub find the
boot partition and menu.lst?




A bug in pygrub rather than anything to do with the content of the
MBR/partition-table. I think we can trust that the Squeeze installer is
creating a partition table which a physical system would be happy to
boot correctly (otherwise there would be a lot of noise being made!) and
pygrub should/must not need anything more special.




I agree - as I said, kpartx didn't complain about the table

I'm pretty certain this works in more recent pygrubs although I don't
see an obvious smoking gun in the diff between the two. It might be
interesting to instrument up the various probing functions of pygrub and
see why it is rejecting the bootable partition.

I don't have any Lenny domain 0 systems handy but I'm going to install a
Squeeze VM on the system I do have and try running the Lenny pygrub on
it to see if I can reproduce the issue. Your Squeeze VM is a pretty
straight forward "mostly pressed enter" installation, right?




Yes - it was my first install of squeeze, so I just decided to do the
easy install (not the custom install) and take defaults for whatever I could

Does grub2 do anything else to the partition table?




I don't know, but partitioning is more a function of the installer (or
the advanced user if they go manual) than grub so I'd expect not.




/boot partition is a real partition

The rest of the disk is LVM, with separate volumes for /, usr, var,
swap, tmp, home all created by the installer







To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#5 Miguel Figueiredo
November 22nd, 2010 - 04:30 pm ET | Report spam
A Sábado 20 Novembro 2010 00:17:14 Daniel Pocock você escreveu:
Package: installation-reports



should the BR be moved from installation-reports to a specific package?

Melhores cumprimentos/Best regards,

Miguel Figueiredo
http://www.DebianPT.org




To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
Help Create a new topicNext page Replies Make a reply
Search Make your own search