RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 614869 - VM doesn't boot after install
Summary: VM doesn't boot after install
Keywords:
Status: CLOSED DUPLICATE of bug 643681
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: seabios
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Gleb Natapov
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-15 12:40 UTC by Alexander Todorov
Modified: 2013-12-09 00:50 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-04 18:49:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
anaconda.log (29.11 KB, text/x-log)
2010-07-15 12:46 UTC, Alexander Todorov 		no flags Details
program.log (48.92 KB, text/plain)
2010-07-15 12:47 UTC, Alexander Todorov 		no flags Details
storage.log (290.11 KB, text/x-log)
2010-07-15 12:47 UTC, Alexander Todorov 		no flags Details
syslog (39.94 KB, application/octet-stream)
2010-07-15 12:47 UTC, Alexander Todorov 		no flags Details
grub.conf (783 bytes, text/plain)
2010-07-16 10:11 UTC, Alexander Todorov 		no flags Details
device.map (63 bytes, text/plain)
2010-07-16 10:11 UTC, Alexander Todorov 		no flags Details
domU xml configuration (2.17 KB, application/xml)
2010-07-30 07:20 UTC, Alexander Todorov 		no flags Details
View All

Description Alexander Todorov 2010-07-15 12:40:37 UTC 
Description of problem:
A KVM domU with several disks will not boot after install.

Version-Release number of selected component (if applicable):
grub-0.97-62.el6
anaconda-13.21.56-1.el6

How reproducible:
Always

Steps to Reproduce:
1. Perform installation on KVM domU which has the following disks:
- vda - virtio disk - 10G (added first in virt-manager)
- sda - IDE disk - 8G - added second via customize guest screen in virt-manager
- sdb - SCSI disk - 1G - added third via the customize guest system screen
2. Partitioning is as follows:
sda1 - /boot, 200M, ext4
sda2 - /, rest of space, ext4
sdb1 - /home, all space, ext4
vda1 - swap, 2048M
vdb2 - /usr, rest of space, ext4
3. By default anaconda will show that bootloader will be installed on sda. I've accepted all defaults about bootloader location. 
4. Complete the install

Actual results:
Install reboots and the system is left at the grub shell

Expected results:
System boots successfully.

Additional info:
What files do you need attached?
Comment 1 Alexander Todorov 2010-07-15 12:46:47 UTC 
Created attachment 432073 [details]
anaconda.log
Comment 2 Alexander Todorov 2010-07-15 12:47:03 UTC 
Created attachment 432074 [details]
program.log
Comment 3 Alexander Todorov 2010-07-15 12:47:16 UTC 
Created attachment 432075 [details]
storage.log
Comment 4 Alexander Todorov 2010-07-15 12:47:26 UTC 
Created attachment 432076 [details]
syslog
Comment 5 Peter Jones 2010-07-15 19:18:22 UTC 
Can we also get /boot/grub/grub.conf and /boot/grub/device.map , please?
Comment 6 Peter Jones 2010-07-15 20:03:33 UTC 
Also, have you seen anything like this when not mixing-and-matching ide and virtio devices?
Comment 7 Alexander Todorov 2010-07-16 10:11:19 UTC 
Created attachment 432345 [details]
grub.conf
Comment 8 Alexander Todorov 2010-07-16 10:11:39 UTC 
Created attachment 432346 [details]
device.map
Comment 9 Alexander Todorov 2010-07-16 10:52:27 UTC 
(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.
Comment 10 Peter Jones 2010-07-28 19:34:21 UTC 
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.
Comment 11 Eduardo Habkost 2010-07-28 20:24:31 UTC 
Assigning to Gerd, as he worked on the virtio EDD code recently.
Comment 13 Gleb Natapov 2010-07-30 06:39:44 UTC 
What is exact qemu command line and seabios package version?
Comment 15 Alexander Todorov 2010-07-30 07:20:48 UTC 
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
Comment 16 Gleb Natapov 2010-07-30 07:44:19 UTC 
(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.
Comment 17 Alexander Todorov 2010-08-02 11:41:29 UTC 
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...
Comment 18 Daniel Veillard 2010-08-02 12:56:55 UTC 
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
Comment 19 Gleb Natapov 2010-08-02 19:18:50 UTC 
(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.
Comment 20 Luiz Capitulino 2010-08-03 20:20:49 UTC 
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
Comment 21 Luiz Capitulino 2010-08-03 22:36:25 UTC 
(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.
Comment 24 David Cantrell 2010-08-24 19:15:37 UTC 
*** Bug 621175 has been marked as a duplicate of this bug. ***
Comment 25 Luiz Capitulino 2010-08-24 22:41:11 UTC 
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)
Comment 26 Luiz Capitulino 2010-08-24 22:51:45 UTC 
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.
Comment 28 Glauber Costa 2010-11-04 18:18:35 UTC 
For 6.1, boot=on is out (See https://bugzilla.redhat.com/show_bug.cgi?id=643681)

Does this make this one a dupe?
Comment 29 Gleb Natapov 2010-11-04 18:49:02 UTC 
(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 ***
Note You need to log in before you can comment on or make changes to this bug.