Bug 614869

Created attachment 432073 [details]
anaconda.log

Created attachment 432074 [details]
program.log

Created attachment 432075 [details]
storage.log

Created attachment 432076 [details]
syslog

Can we also get /boot/grub/grub.conf and /boot/grub/device.map , please?

Also, have you seen anything like this when not mixing-and-matching ide and virtio devices?

Created attachment 432345 [details]
grub.conf

Created attachment 432346 [details]
device.map

(In reply to comment #6)
> Also, have you seen anything like this when not mixing-and-matching ide and
> virtio devices?    

With 3 virtio devices the system was able to boot successfully.

So, when I try to replicate this, I get edd info that doesn't match *any* of my drives. When that happens, anaconda is basically guessing as to which drive is bootable.  I think what's happening is that we're getting bad EDD data, and the drive we pick happens not to be the bootable one.

Bouncing this to the bios to fix the data.

Assigning to Gerd, as he worked on the virtio EDD code recently.

What is exact qemu command line and seabios package version?

Created attachment 435484 [details]
domU xml configuration

(In reply to comment #13)
> What is exact qemu command line and seabios package version?    

I've used virt-manager, not qemu directly. The XML config file for the guest is attached.

seabios-0.5.1-2.el6.x86_64

(In reply to comment #15)
> Created an attachment (id=435484) [details]
> domU xml configuration
> 
> (In reply to comment #13)
> > What is exact qemu command line and seabios package version?    
> 
> I've used virt-manager, not qemu directly. The XML config file for the guest is
> attached.
Unfortunately I can't pars this XML into command line that virt-manager actually use.
Can you see what is the command line in ps output please? If it contains boot=on
can you run manually without it.

> 
> seabios-0.5.1-2.el6.x86_64    
OK. Latest one.

During install QEMU command line is:

/usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name t1 -uuid 5598ec0b-b065-315f-fb21-bc49ef09876d -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/t1.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -no-reboot -boot c -kernel /var/lib/libvirt/boot/virtinst-vmlinuz.Uw0qul -initrd /var/lib/libvirt/boot/virtinst-initrd.img.eY3YZL -append method=http://qafiler.bos.redhat.com/redhat/rel-eng/RHEL6.0-20100730.5/6/Server/x86_64/os -drive file=/var/lib/libvirt/images/dvd-2.img,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/var/lib/libvirt/images/disk1.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/var/lib/libvirt/images/disk2.img,if=none,id=drive-ide0-0-1,format=raw,cache=none -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b3:0b:84,bus=pci.0,addr=0x5 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3


After install is complete and system reboots the QEMU cmd line is:

/usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name t1 -uuid 5598ec0b-b065-315f-fb21-bc49ef09876d -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/t1.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/dvd-2.img,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/var/lib/libvirt/images/disk1.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/var/lib/libvirt/images/disk2.img,if=none,id=drive-ide0-0-1,format=raw,cache=none -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b3:0b:84,bus=pci.0,addr=0x5 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3


The original description in comment #0 is a bit misleading. The system is not hanging at the grub shell . The last lines are:

Starting SeaBIOS (version ...)

gPXE (....)

Booting from Hard Disk...

I have an upstream patch desactivating boot=on support for IDE devices 

https://www.redhat.com/archives/libvir-list/2010-July/msg00691.html

which may solve the issue, but I'm a bit afraid of pushing it in RHEL-6
at this point, as it got virtually no testing except from my own,

Daniel

(In reply to comment #10)
> So, when I try to replicate this, I get edd info that doesn't match *any* of my
> drives. When that happens, anaconda is basically guessing as to which drive is
> bootable.  I think what's happening is that we're getting bad EDD data, and the
> drive we pick happens not to be the bootable one.
How do you verify edd info. I am looking at /sys/firmware/edd/int13_dev80 and it points to first ide device but anaconda by default choose virtio to be bootable which is /sys/firmware/edd/int13_dev83.

Not sure if this helps much, but I've ran some tests on this.

I'm running qemu-kvm by hand (command-line below) with one virtio disk and two ide disks.

Partitioning (like the original report)
---------------------------------------

sda1 /boot
sda2 /

sdb1 swap
sdb2 /home

vda1 /usr

Results
--------

1. If I select the sda drive as a bootable device and install grub on it (default setup) I get an unbootable system. No matter what I do, I can't boot

2. If I select the vda drive as a bootable device and install grub on it, I can boot *if* I start the VM with "-boot order=c,menu=on" and choose to boot from the virtio disk. Choosing the second IDE disk works too (wth?) but choosing the first doesn't

I have all relevant information with me: the disks and screenshots of the relevant install steps. I can attach them on demand (would pollute the BZ otherwise).

I didn't test with libvirt yet, but I believe we will get the same results, unless setting boot=on on IDE drives changes anything.

Also note that:

1. The host runs: rhel6, qemu-kvm-0.12.1.2-2.106.el6.x86_64 and seabios-0.5.1-2.el6.x86_64

2. I'm installing F13

3. Command-line:

sudo /usr/libexec/qemu-kvm -M rhel6.0.0 -enable-kvm -m 2G -drive file=disks/dvd-2.img,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=disks/disk1.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=disks/disk2.img,if=none,id=drive-ide0-0-1,format=raw,cache=none -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -boot order=c,menu=on -cdrom /mnt/isos/linux/Fedora-13-x86_64-DVD.iso -vnc :0 -monitor stdio -usb -usbdevice tablet

(In reply to comment #20)

> 1. If I select the sda drive as a bootable device and install grub on it
> (default setup) I get an unbootable system. No matter what I do, I can't boot

Okay, dropping the boot=on from the virtio disk makes this work for me.

*** Bug 621175 has been marked as a duplicate of this bug. ***

I have a late update for this one: I've ran virt-install tests. Results below (setup the same as described in comment #20).

rhel6.0 (or what works)
-----------------------

- Using all (three) disks as IDE disks

- Using all (three) disks as virtio disks

NOTE: The first '--disk' must be the bootable one.

rhel6.1 (or what doesn't work, but should)
------------------------------------------

- Fancy setups, like trying to make the second '--disk' the bootable one (even when all disks are IDE or virtio)

- When mixing IDE and virtio and having the virtio disk as the first '--disk' (this BZ)

- When mixing IDE and virtio and having the IDE disk as the first one (that's BZ bug 621175, there's a easy workaround though)

As discussed in this thread:

  http://post-office.corp.redhat.com/mailman/private/virt-devel/2010-August/msg00102.html

The solution for this one seems to be adapting libvirt to recognize the existence of seabios. Qemu needs to export this information someway, though.

Assigning to Gleb, as he's handling this with Daniel Veillard.

For 6.1, boot=on is out (See https://bugzilla.redhat.com/show_bug.cgi?id=643681)

Does this make this one a dupe?

(In reply to comment #28)
> For 6.1, boot=on is out (See
> https://bugzilla.redhat.com/show_bug.cgi?id=643681)
> 
> Does this make this one a dupe?
Correct.

*** This bug has been marked as a duplicate of bug 643681 ***