Bug#555985: Missing xen support, regression from grub1

[Goswin von Brederlow]

Felix Zielcke <fzielcke at z-51.de> writes:

> reassign 505517 grub-common
> reassign 555985 grub-common
> forcemerge 505517 555985
> thanks
> Am Freitag, den 13.11.2009, 02:37 +0100 schrieb Goswin von Brederlow:
>> Package: grub-pc
>> Version: 1.96+20090725-1
>> Severity: normal
>> 
>> Hi,
>> 
>> grub2 does not add entries for xen hypervisor and kernels. After
>> reading the docs I managed to create an entry manually like this:
>> 
>> menuentry "Xen 3.4, kernel 2.6.31.5 git 20091113" {
>>     insmod ext2
>>     set root=(hd0,1)
>>     search --no-floppy --fs-uuid --set 69c9f9d8-4772-4391-9111-e66ef6b49ac6
>>     multiboot /xen-3.4-amd64.gz dom0_mem=512M
>>     module /vmlinuz-2.6.31.5-xen-00513-g47dfde5 nomodeset
>>     module /initrd.gz
>> }
>
> For the record which isn't yet anywhere documented and because you still
> use an older grub2. (Though I wonder why you use an old grub2 package in
> conjunction with a 2.6.31 xen kernel)

Never change a running system. Grub2 updates in sid don't have the best
track records so I tried to avoid updates.

> With newest releases you have to double the filename both in multiboot
> and module line or add a dummy parameter but the filename would
> reassemble GRUB Legacy's behaviour.
> I.e. with 1.97 change it to
>     multiboot /xen-3.4-amd64.gz /xen-3.4-amd64.gz dom0_mem=512M
>     module /vmlinuz-2.6.31.5-xen-00513-g47dfde5 /vmlinuz-2.6.31.5-xen-00513-g47dfde5 nomodeset
>
> Both (GRUB 2's and GRUB Legacy's) complies with multiboot specs.

> AFAIK the Kernel team still hasn't decided if squeeze will ship for sure
> with Xen Dom0 support or not. And AFAICS there's no Xen kernel flavour
> in squeeze or sid. So for us this isn't that important.

Xen dom0 support is planing to go into the vanilla kernel, estimated
to be in 2.6.34 or 2.6.35. And I don't think it is going to go away
any time soon. Even if Debian does not ship a Xen Dom0 kernel in
squeeze there will be many users that use one anyway. Please do
consider this important. It would be a real shame if Xen support in
Debian breaks because grub2 is missing a few lines of shell script.

> You should not base the lists on the kernel filenames, but on the
> configure flags.

Ok, I will look into that then.

> Somewhere in the GRUB Legacy reports is a bug that update-grub added a
> *xen* kernel as Xen dom0 which has nothing at all to do with the Xen
> virtualization software.
> Apart of this, I don't really have an opinion about how the Xen kernels
> should be handled inside grub-mkconfig.
> If the Xen hypervisor provides a /etc/grub.d/10_hypervisor_xen then they
> have control over the generated menu entries.
> The disadvantage though would be they can only use variables
> from /etc/default/grub if either we export them in grub-mkconfig or they
> source the file again.

Also all Xen capable kernels would be listed with Xen first followed
by all kernels as bare metal. Is that desired? Or would it be better to
list each kernel with xen and bare metal each sorted by version. The
later would require 10_linux to support xen.

> I think Ubuntu's GRUB Legacy has a flag if this is a dom0 or domU. Such
> a thing would make sense to me.

With pv-ops there are 3 kinds of kernels:
bare metal
bare metal + domU
bare metal + domU + dom0

The three kinds can be detected by the config file (as you suggested
above). But there should still be an option to list or not list each
kind of kernel to keep the menu short.

> But why can it be useful to have multiple Xen hypervisors installed?

For the simple fact that you may want to update to a new hypervisor
but have the option to boot the old one if it breaks.

MfG
        Goswin