Am Montag, den 23.11.2009, 15:12 +0100 schrieb Thomas Schwinge:
> And now for a strange thing, perhaps the reason for all this
> misbehavior:
>
> Failed Xen system boot, in (initramfs) rescue shell:
>
> (initramfs) cat /proc/cmdline
> ro console=tty0
>
> Where did the root=... go?!
>
> On the other hand, successful (non-Xen) Linux kernel boot, same GRUB
> version:
>
> $ cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-2.6.30-2-amd64
> root=/dev/mapper/vg0-boole--root ro
This is due to a change inside the multiboot code.
Previous versions and also GRUB Legacy passed the filename as first
parameter to the multiboot image and to all modules.
Now it doestn't do this any more.
Unfortunately both behaviours conform to the multboot specification.
To restore the old behaviour use this:
multiboot /boot/xen-3.4-amd64.gz /boot/xen-3.4-amd64.gz noreboot
dom0_mem=150000
module /boot/vmlinuz-2.6.31-1-xen-amd64
/boot/vmlinuz-2.6.31-1-xen-amd64 root=/dev/mapper/vg0-boole--root ro
console=tty0
I don't think we should do anything more then adding this to Readme.Debian
and/or NEWS.Debian.
Unfortunately this was missed so thanks for the report.
This is more a bug in the Xen hypervisor which needs to be fixed.
But if it's still not fixed there when grub-mkconfig gains Xen support then we
have to handle this there.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
