Bug 1368887

Summary: UEFI, ignores boot device order, always wants to boot off SATA CDROM1
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: berrange, crobinso, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-23 21:51:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
virsh dumpxml
none
screenshot none

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.