Bug#555985: Missing xen support, regression from grub1
Felix Zielcke 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555985: Missing xen support, regression from grub1
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)
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.
> I would suggest adding new variables to /etc/default/grub:
>
> # Options for the xen hypervisor and kernel command line
> #GRUB_CMDLINE_XEN_HYPERVISOR="dom0_mem=512M"
> GRUB_CMDLINE_XEN_KERNEL="nomodeset"
>
> and this in 10_linux ($3 == /boot/xen-3.4-amd64.gz for example):
>
> xen_linux_entry ()
> {
> cat << EOF
> menuentry "$1" {
> EOF
> prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | sed -e "s/^/\t/"
> cat << EOF
> multiboot ${rel_dirname}/"$3" ${GRUB_CMDLINE_XEN_HYPERVISOR}
> module ${rel_dirname}/${basename}
> root=${linux_root_device_thisversion} ro $2
> EOF
> if test -n "${initrd}" ; then
> cat << EOF
> module ${rel_dirname}/${initrd}
> EOF
> fi
> cat << EOF
> }
> EOF
> }
>
>
> Now the tricky part is when to call that. There can be multiple
> hypervisors installed (/boot/xen-.-.gz). Also multiple
> kernels (/boot/vmlinuz-*xen*). Xen kernels can also be for domU or
> dom0+domU. In dom0 adding a domU kernel makes no sense. On the other
> hand in domU adding non-xen kernels makes little sense.
>
> So maybe /etc/defaults/grub should have a variable listing the pattern
> for images that should be added:
>
> # Add a menuentry for every linux kernel:
> GRUB_PATTERN_LINUX="vmlinu[xz]*"
>
> # Add a menuentry for every xen kernel:
> GRUB_PATTERN_XEN="vmlinu[xz]*xen*"
>
> # Add a menuentry only for dom0 xen kernel:
> #GRUB_PATTERN_XEN="vmlinu[xz]*xen0*"
>
> # Add a menuentry only for domU xen kernel:
> #GRUB_PATTERN_XEN="vmlinu[xz]*xenu*"
>
> and 10_linux could then use those to build its list of images.
> How does that sound? Should I prepare a patch along those lines?
>
> MfG
> Goswin
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.
You should not base the lists on the kernel filenames, but on the
configure flags.
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.
I think Ubuntu's GRUB Legacy has a flag if this is a dom0 or domU. Such
a thing would make sense to me.
But why can it be useful to have multiple Xen hypervisors installed?
--
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
Bug#555985: Missing xen support, regression from grub1
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
}
I would suggest adding new variables to /etc/default/grub:
# Options for the xen hypervisor and kernel command line
#GRUB_CMDLINE_XEN_HYPERVISOR="dom0_mem=512M"
GRUB_CMDLINE_XEN_KERNEL="nomodeset"
and this in 10_linux ($3 == /boot/xen-3.4-amd64.gz for example):
xen_linux_entry ()
{
cat << EOF
menuentry "$1" {
EOF
prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | sed -e "s/^/\t/"
cat << EOF
multiboot ${rel_dirname}/"$3" ${GRUB_CMDLINE_XEN_HYPERVISOR}
module ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro $2
EOF
if test -n "${initrd}" ; then
cat << EOF
module ${rel_dirname}/${initrd}
EOF
fi
cat << EOF
}
EOF
}
Now the tricky part is when to call that. There can be multiple
hypervisors installed (/boot/xen-.-.gz). Also multiple
kernels (/boot/vmlinuz-*xen*). Xen kernels can also be for domU or
dom0+domU. In dom0 adding a domU kernel makes no sense. On the other
hand in domU adding non-xen kernels makes little sense.
So maybe /etc/defaults/grub should have a variable listing the pattern
for images that should be added:
# Add a menuentry for every linux kernel:
GRUB_PATTERN_LINUX="vmlinu[xz]*"
# Add a menuentry for every xen kernel:
GRUB_PATTERN_XEN="vmlinu[xz]*xen*"
# Add a menuentry only for dom0 xen kernel:
#GRUB_PATTERN_XEN="vmlinu[xz]*xen0*"
# Add a menuentry only for domU xen kernel:
#GRUB_PATTERN_XEN="vmlinu[xz]*xenu*"
and 10_linux could then use those to build its list of images.
How does that sound? Should I prepare a patch along those lines?
MfG
Goswin
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable-i386
APT policy: (1001, 'unstable-i386'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29.4-frosties-2 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages grub-pc depends on:
ii debconf [debconf-2.0]1.5.27 Debian configuration management sy
ii grub-common 1.96+20090725-1 GRand Unified Bootloader, version
ii libc62.10.1-2GNU C Library: Shared libraries
ii ucf 3.0018 Update Configuration File: preserv
grub-pc recommends no packages.
Versions of packages grub-pc suggests:
pn desktop-base (no description available)
ii genisoimage 9:1.1.9-1 Creates ISO-9660 CD-ROM filesystem
pn os-prober (no description available)
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
