Bug#557645: grub-pc: fails to boot Xen system

2009-11-24 Thread Ian Campbell
On Mon, 2009-11-23 at 18:19 +0100, Felix Zielcke wrote:
 
 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. 

This seems like a pretty major (and gratuitous) change in behaviour. Is
there anyway for an OS to determine whether the command line starts with
the image filename or not? If not then how are OS's expected to cope
with being booted by either Grub-legacy or Grub2?

 Unfortunately both behaviours conform to the multboot specification.

That may be so, but given that existing OSs (written to conform to the
old behaviour) expect things to be one way, what is the rationale for
changing it?

Ian.

-- 
Ian Campbell

Trust everybody, but cut the cards.
-- Finlay Peter Dunne, Mr. Dooley's Philosophy




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#557645: grub-pc: fails to boot Xen system

2009-11-23 Thread Thomas Schwinge
Package: grub-pc
Version: 1.97~beta3-1
Severity: important

This is a very odd issue.  Originally I began reporting it in this
thread; linking directly to the most useful message:
http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2009-October/002479.html

I bisected this erroneous behavior to the grub-pc package!  (Uh?!)

The gist is that with certain versions of GRUB, the Xen system won't
boot, but instead only drop into the (initramfs) rescue shell.

  * 1.96+20080724-16 (stable): system boots;
  * 1.97~beta3-1~bpo50+1 (stable backports): system doesn't boot;
  * 1.97~beta3-1 (testing): system doesn't boot;
  * 1.97+20091115-1 (unstable): system doesn't boot.

This is absolutely reproducible -- I wouldn't believe it myself at first,
why should GRUB be responsible for this problem, as the kernel (plus Xen
hypervisor) had already been loaded -- so I did a few back-and-forth GRUB
installations, but from the set above only 1.96+20080724-16 allows for
booting the Xen system.  All this is not relevant for directly booting a
(non-Xen) Linux kernel: here the version of GRUB doesn't matter.

I snipped out the uninteresting parts of grub.cfg below, but you can see
that the Xen and non-Xen entries are essentially the same.


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


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/vg0-boole--root / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg0-boole--data /media/data ext3 
rw,relatime,errors=continue,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/sda
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
terminal 
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/09_custom ###

menuentry Xen 3.4, Debian GNU/Linux, Linux 2.6.31-1-xen-amd64 {
insmod lvm
insmod ext2
set root=(vg0-boole-root)
multiboot /boot/xen-3.4-amd64.gz noreboot dom0_mem=15
module /boot/vmlinuz-2.6.31-1-xen-amd64 
root=/dev/mapper/vg0-boole--root ro console=tty0
module /boot/initrd.img-2.6.31-1-xen-amd64
}

[...]

### END /etc/grub.d/09_custom ###

### BEGIN /etc/grub.d/10_linux ###
menuentry Debian GNU/Linux, linux 2.6.31-1-xen-amd64 {
insmod lvm
insmod ext2
set root=(vg0-boole-root)
search --no-floppy --fs-uuid --set af75f12b-963d-4aff-a0f0-ed3f49c577a2
linux   /boot/vmlinuz-2.6.31-1-xen-amd64 
root=/dev/mapper/vg0-boole--root ro  
initrd  /boot/initrd.img-2.6.31-1-xen-amd64
}

[...]

}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###
*** END /boot/grub/grub.cfg

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages grub-pc depends on:
ii  debconf [debconf-2.0]   1.5.28   Debian configuration management sy
ii  grub-common 1.97~beta3-1 GRand Unified Bootloader, version 
ii  libc6   2.10.1-7 GNU C Library: Shared libraries
ii  ucf 3.0024   Update Configuration File: preserv

grub-pc recommends no packages.

Versions of packages grub-pc suggests:
pn  desktop-base  none (no description available)
pn  genisoimage   none (no description available)

-- debconf information:
  grub2/kfreebsd_cmdline:
  grub-pc/linux_cmdline: fillme
* grub2/linux_cmdline:
  grub-pc/chainload_from_menu.lst: true
  grub-pc/kopt_extracted: false
* grub-pc/install_devices: /dev/sda
  grub-pc/postrm_purge_boot_grub: false
  grub2/kfreebsd_cmdline_default: quiet
* grub2/linux_cmdline_default:


Regards,
 Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#557645: grub-pc: fails to boot Xen system

2009-11-23 Thread Felix Zielcke
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=15
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