Bug 1368887 - UEFI, ignores boot device order, always wants to boot off SATA CDROM1
Summary: UEFI, ignores boot device order, always wants to boot off SATA CDROM1
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-22 03:28 UTC by Chris Murphy
Modified: 2016-08-23 21:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-23 21:51:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
virsh dumpxml (5.23 KB, text/plain)
2016-08-22 03:29 UTC, Chris Murphy
no flags Details
screenshot (28.37 KB, image/png)
2016-08-22 03:29 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2016-08-22 03:28:26 UTC
Description of problem:

This is a regression, it used to work within the last ~month. Anyway following a reboot from install, even though NVRAM is set to boot off the virtio disk, not CDROM, it boots off the CDROM; so I manually go to Boot Options, uncheck SATA CDROM1, leaving only VirtIO Disk 1 checked, and start the VM. Same thing, it boots off the ISO file specified for SATA CDROM1. So I disconnect the ISO from SATA CDROM 1, and now I get an EFI shell.


Version-Release number of selected component (if applicable):
edk2-ovmf-20160418gita8c39ba-4.fc24.noarch
virt-manager-1.4.0-3.fc24.noarch
qemu-kvm-2.6.0-5.fc24.x86_64


How reproducible:
Always


Steps to Reproduce:
1. Boot option > Check only VirtIO Disk 1
2. Start VM
3.

Actual results:

Insists on booting off CDROM rather than boot option selected (virtio disk); and if no file attached to CDROM, EFI shell. See screen shot.

Expected results:

Should get a GRUB menu.

Additional info:


qemu     31866 30.6  1.5 4277796 128508 ?      Sl   21:14   0:17 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name UEFI,debug-threads=on -S -machine pc-i440fx-2.4,accel=kvm,usb=off,vmport=off -cpu SandyBridge -drive file=/usr/share/edk2/ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/UEFI_VARS.fd,if=pflash,format=raw,unit=1 -m 3072 -realtime mlock=off -smp 3,sockets=3,cores=1,threads=1 -uuid 11831a99-fad2-4e1f-8a31-f521cbf91ff3 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-UEFI/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device ahci,id=sata0,bus=pci.0,addr=0x8 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive if=none,media=cdrom,id=drive-sata0-0-1,readonly=on -device ide-cd,bus=sata0.1,drive=drive-sata0-0-1,id=sata0-0-1 -drive file=/var/lib/libvirt/images/bios-f25wlive-2.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=25,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:fe:40:e3,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=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on

Comment 1 Chris Murphy 2016-08-22 03:29:31 UTC
Created attachment 1192741 [details]
virsh dumpxml

Comment 2 Chris Murphy 2016-08-22 03:29:49 UTC
Created attachment 1192742 [details]
screenshot

Comment 3 Chris Murphy 2016-08-22 03:56:56 UTC
If I reconnect a live media ISO, get to GRUB, I can use 'configfile' to load the grub.cfg off the ESP on VirtIO Disk 1 and boot the system. So it is bootable and has all the necessary components for some reason though the VM will not boot off VirtIO Disk 1.

In a shell from the booted system:
[root@localhost ~]# efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0008
Boot0002* EFI DVD/CDROM	PciRoot(0x0)/Pci(0x8,0x0)/Sata(1,0,0)
Boot0008* EFI Internal Shell	MemoryMapped(11,0x900000,0x11fffff)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)


So yeah it's missing the anaconda>efibootmgr boot menu entry from installation, which did run because it's in the program.log, and it succeeded.

Let's try setting that manually:
[root@localhost ~]# efibootmgr -c -w -L Fedora -d /dev/vda -p 1 -l \\EFI\\fedora\\shim.efi
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0000,0002,0008
Boot0002* EFI DVD/CDROM
Boot0008* EFI Internal Shell
Boot0000* Fedora

And reboot. HUH, that works. And it keeps working through poweroff and a restart of virt-manager.

Uhhh. OK...

Comment 4 Chris Murphy 2016-08-23 21:51:59 UTC
I created a new virtual machine, with ovmf uefi firmware, and did an installation. At reboot, the ISO is "ejected" such that no file is associated with CDROM device, and the system boots the installed system by default, and efibootmgr has a proper boot entry.

Dunno really why it was disagreeable with the older uefi VM instance but I don't think it's worth tracking down right now.


Note You need to log in before you can comment on or make changes to this bug.