Bug#604080: Xen domU fails to boot after install
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
Reply to: