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-<x>.<y>-<flavour>.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
