On Fri, 2012-02-10 at 16:46 -0800, Alex Bradley wrote:
> (Resending after reopening bug.)
>
> I encountered this bug in a fresh squeeze install this week. I believe
> the problem was that my dom0 was using ext4 filesystems (and not
> ext3), while my domU was using an ext3 root filesystem. Therefore, the
> initramfs created for dom0 did not include the ext3 module and domU
> could not boot.
An initramfs built on a given installation should not be expected to
work on a different installation.
By the way, I can't recommend using ext4 on Linux 2.6.32.
> After running the following commands on dom0, the domU booted successfully:
>
> root@xen2:~# echo ext3 >> /etc/initramfs-tools/modules
> root@xen2:~# update-initramfs -u
>
> I suspect this may be more a bug in xen-tools than in initramfs-tools.
> Before encountering this bug, I had already had to add "xen-blkfront"
> to /etc/initramfs-tools/modules to fix the problem described in bug
> #640099. Perhaps the more general problem here is that xen-tools is
> creating domUs with initramfs that are tailored for dom0 and not domU.
> For instance, the boot output below also shows an attempt to find the
> dom0's LVM volumes, which are irrelevant for the domU.
[...]
Indeed, if that's what xen-tools does by default then it is horribly broken.
I'll reassign the bug.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
Attachment:
signature.asc
Description: This is a digitally signed message part