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 1129549 - seabios will lost some bootable device after "sendkey ctrl-alt-delete"
Summary: seabios will lost some bootable device after "sendkey ctrl-alt-delete"
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: seabios
Version: 6.6
Hardware: x86_64
OS: Windows
low
low
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
Jiri Herrmann
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-13 07:32 UTC by Jun Li
Modified: 2016-03-01 10:37 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Soft-rebooted Windows guests cannot detect some of their bootable devices Under certain circumstances, soft-rebooting a Windows guest (for example by using the Ctrl+Alt+Del keys) causes the guest not to detect some of its bootable devices. To work around this problem, perform a hard reboot of the guest - for example by the Shutdown button in the virt-manager interface, or by the "system_reset" command in the QEMU monitor console.
Clone Of:
Environment:
Last Closed: 2016-01-15 16:24:46 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Before "sendkey ctrl-alt-delete" (20.48 KB, image/png)
2014-08-13 07:40 UTC, Jun Li 		no flags Details
After "sendkey ctrl-alt-delete" (16.70 KB, image/png)
2014-08-13 07:40 UTC, Jun Li 		no flags Details
View All

Description Jun Li 2014-08-13 07:32:03 UTC 
Description of problem:
Boot windows guest with two ide disk and other bootable devices. Execute "sendkey ctrl-alt-delete" in HMP after select a bootable device(win8-32 guest).

Version-Release number of selected component (if applicable):
# rpm -qa|grep seabios
seabios-0.6.1.2-28.el6.x86_64
# uname -r
2.6.32-496.el6.x86_64
qemu-kvm-0.12.1.2-2.436.el6.x86_64
Guest:
win8-32

How reproducible:
100%

Steps to Reproduce:
1.boot guest with following cli:
# /usr/libexec/qemu-kvm -name test -machine rhel6.6.0,dump-guest-core=off -cpu SandyBridge,hv_relaxed,enforce -enable-kvm -m 4024 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid b123c5df-d85b-2ce9-5e93-926f4f4ce03b -nodefconfig -nodefaults -rtc base=utc -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 \
-drive file=/home/win8-32.qcow2,snapshot=on,if=none,id=drive-virtio-disk0,format=qcow2,cache=none \
-device ide-drive,bus=ide.1,unit=1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
-netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=24:BE:05:0C:11:18,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5901,addr=0.0.0.0,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on -drive file=/usr/share/virtio-win/virtio-win.iso,id=nic-package,if=none,media=cdrom -device ide-drive,drive=nic-package,id=sys-nic-package,bus=ide.0,unit=1 -drive file=/home/en_windows_8_enterprise_x86_dvd_917587.iso,id=other-driver,if=none,media=cdrom -device ide-drive,drive=other-driver,id=sys-other-driver,bus=ide.0,unit=0 -monitor stdio -qmp tcp::8888,server,nowait -drive file=/home/data-disk.qcow2,if=none,id=data-disk,format=qcow2 -device ide-drive,drive=data-disk,id=sys-data-disk,bus=ide.1,unit=0 -fda /home//file.vfd -drive file=/home/test.img,if=none,id=drive-fdc0-0-0,readonly=on,format=raw  -global isa-fdc.driveA=drive-fdc0-0-0  -boot menu=on
2.Select bootable device(win8-32 guest) during POST.
3.after step2, ASAP execute "sendkey ctrl-alt-delete".
4.Check the bootable system-disk is still existing during POST.

Actual results:
After step4, Can not find the bootable guest system disk on seabios. These two ide disks are all disappeared.

Expected results:
After step4, can find the bootable guest system-disk during POST and can select booting from system-disk again.

Additional info:
Comment 1 Jun Li 2014-08-13 07:40:20 UTC 
Created attachment 926295 [details]
Before "sendkey ctrl-alt-delete"
Comment 3 Jun Li 2014-08-13 07:40:56 UTC 
Created attachment 926296 [details]
After "sendkey ctrl-alt-delete"
Comment 5 Jun Li 2015-03-09 06:12:44 UTC 
Retest this issue with linux guest, do not hit this issue.

Version of components:
seabios-0.6.1.2-29.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.457.el6.x86_64
Guest:
RHEL-Server-6.6-64

Cli and steps are the same with comment 0.

cli:
# /usr/libexec/qemu-kvm -name test -machine rhel6.6.0,dump-guest-core=off -cpu SandyBridge,hv_relaxed,enforce -enable-kvm -m 4024 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid b123c5df-d85b-2ce9-5e93-926f4f4ce03b -nodefconfig -nodefaults -rtc base=utc -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/mnt/RHEL-Server-6.6-64-virtio.qcow2,snapshot=on,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device ide-drive,bus=ide.1,unit=1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=24:BE:05:0C:11:18,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5901,addr=0.0.0.0,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on -drive file=/usr/share/virtio-win/virtio-win.iso,id=nic-package,if=none,media=cdrom -device ide-drive,drive=nic-package,id=sys-nic-package,bus=ide.0,unit=1 -drive file=/home/en_windows_8_enterprise_x86_dvd_917587.iso,id=other-driver,if=none,media=cdrom -device ide-drive,drive=other-driver,id=sys-other-driver,bus=ide.0,unit=0 -monitor stdio -qmp tcp::8888,server,nowait -drive file=/home/data-disk.qcow2,if=none,id=data-disk,format=qcow2 -device ide-drive,drive=data-disk,id=sys-data-disk,bus=ide.1,unit=0 -fda /home//file.vfd -drive file=/home/test.img,if=none,id=drive-fdc0-0-0,readonly=on,format=raw  -global isa-fdc.driveA=drive-fdc0-0-0  -boot menu=on


Hi Amos,
  
   QE has tested with linux guest, do not hit this issue. Any further testing needed, free to update it in the comment. Thx.

Best Regards,
Jun Li
Comment 6 Jun Li 2015-03-09 07:39:16 UTC 
Also re-test with win8-32 guest using comment 5 component, hit comment 0's issue, too.

Version of component:
seabios-0.6.1.2-29.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.457.el6.x86_64
Guest:
win8-32

====================
QE also tests this issue on rhel7, don't hit this issue.
Version of components:
seabios-1.7.5-8.el7.x86_64
qemu-kvm-rhev-2.2.0-5.el7.x86_64
Guest:
win8-32
Comment 7 Amos Kong 2015-03-09 09:29:25 UTC 
The following patches fixed the problem in rel-0.6.2 of seabios upstream.


commit 244caf86f11f5f65d166d91704f64cb673167abc   (key fixing)
Author: Kevin O'Connor <kevin>
Date:   Wed Sep 15 21:48:16 2010 -0400

    Try to hard-reboot on rerun of post even on emulators.
    
    Extend the hard-reboot logic to qemu and kvm.  On qemu, a reboot will
    not reset the memory settings for 0xc0000-0xfffff, so copy that memory
    area manually before rebooting.  Unfortunately, kvm does not keep a
    pristine copy of the BIOS at 0xffff0000, so detect that case and
    shutdown the machine.

commit 5bd01de26257849f36d361018c3ec17aa29b0218
Author: Kevin O'Connor <kevin>
Date:   Mon Sep 13 21:19:27 2010 -0400

    Don't do shadow copying of optionroms when CONFIG_OPTIONROMS_DEPLOYED.
    
    When CONFIG_OPTIONROMS_DEPLOYED is set, there is no need to copy the
    0xc0000-0xf0000 space around - SeaBIOS ignores what's there when it
    that mode.

commit adaf373bae943b8ab516a4e2c1ddf1e9b58cc050
Author: Kevin O'Connor <kevin>
Date:   Mon Sep 13 20:22:07 2010 -0400

    Try to hard-reboot processor on rerun of post under coreboot.
    
    Add several methods for rebooting a processor.
    
    Detect a rerun of POST under coreboot and attempt to reboot the
    processor.
Comment 15 Amos Kong 2015-03-19 08:50:40 UTC 
The shutdown doesn't occur with upstream qemu, so we need to backport some fix of qemu.
Comment 16 Ademar Reis 2015-04-29 14:58:25 UTC 
Looks like this issue is being discussed upstream and different fixes are being proposed. Reverting the BZ back to ASSIGNED.
Comment 18 Gerd Hoffmann 2015-07-08 12:39:46 UTC 
(In reply to Amos Kong from comment #15)
> The shutdown doesn't occur with upstream qemu, so we need to backport some
> fix of qemu.

Well, "some fix" is the memory api (which allows to correctly emulate the chipset settings for the 0xa0000 -> 0xfffff area).  That is _way_ to invasive to be backported to RHEL-6.

So, backporting the patches mentioned in comment 7 is out.

Unfortunately there is no other easy way to handle this.  Invoking a reset is the only way to bring the hardware into a known state.  And that is needed for reliable hardware detection, otherwise the hardware initialization can trip up due to hardware being in some odd/unexpected state.  Which most likely is the reason for the ide drives disappearing here.

Why has this high priority?
Note You need to log in before you can comment on or make changes to this bug.