On 05/09/16 17:36, Thomas Lamprecht wrote: [snip]
> Ok, the OS did sets this up but when I start qemu without disk it starts > the UEFI shell nonetheless, if I pass a disk to the VM it will always > boot from this disk, still won't keep the changes which I'm making in > the UEFI UI. > > In the shell I see the BOOTX64.EFI: > ls fs0:\EFI\BOOT\BOOTX64.EFI > > and can add it with > bcfg boot add fs0:\EFI\BOOT\BOOTX64.EFI "Test Entry" > > But it does not survives a reboot. > > So for reference, I do now the following: > > * VM powered down > > * start it with the adapted command, this time the full command without > snipping in case I falsely removed some important information: > >> /usr/bin/systemd-run >> --scope >> --slice qemu >> --unit 7003 >> -p KillMode=none >> -p CPUShares=1000 /usr/bin/kvm >> -id 7003 >> -chardev socket,id=qmp,path=/var/run/qemu-server/7003.qmp,server,nowait >> -mon chardev=qmp,mode=control >> -pidfile /var/run/qemu-server/7003.pid >> -daemonize >> -smbios type=1,uuid=e2e058bc-740e-4737-8430-a73959a6188b >> -drive >> if=pflash,format=raw,unit=0,readonly,file=/usr/share/kvm/OVMF-pure-efi.fd >> -drive >> if=pflash,format=raw,unit=1,file=/var/lib/vz/images/7003/vm-7003-efi.raw >> -name disposable-3 >> -smp 4,sockets=1,cores=4,maxcpus=4 >> -nodefaults >> -boot menu=on >> -vga qxl >> -vnc unix:/var/run/qemu-server/7003.vnc,x509,password >> -cpu host,+kvm_pv_unhalt,+kvm_pv_eoi >> -m 6196 >> -k de >> -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f >> -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e >> -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 >> -chardev socket,path=/var/run/qemu-server/7003.qga,server,nowait,id=qga0 >> -device virtio-serial,id=qga0,bus=pci.0,addr=0x8 >> -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 >> -spice >> tls-port=61001,addr=localhost,tls-ciphers=DES-CBC3-SHA,seamless-migration=on >> -device virtio-serial,id=spice,bus=pci.0,addr=0x9 >> -chardev spicevmc,id=vdagent,name=vdagent >> -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 >> -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 >> -iscsi initiator-name=iqn.1993-08.org.debian:01:468faae9322b >> -drive if=none,id=drive-ide2,media=cdrom,aio=threads >> -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 >> -drive >> file=/var/lib/vz/images/7003/vm-7003-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,cache=none,aio=native,detect-zeroes=on >> -device >> virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 >> -netdev >> type=tap,id=net0,ifname=tap7003i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on >> -device >> virtio-net-pci,mac=62:33:37:36:38:63,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 This looks fine to me. > > * install the OS (a debian based one) So this implies your IDE CD-ROM gets booted, right? (This works as expected -- the virtio-block disk is attempted first, but that is not yet bootable, so we continue to the IDE CD-ROM. Good.) > > * reboot > > * the VM boots the CD ISO again (bootindex says otherwise) Indeed. I have experience with Fedora and RHEL guests; and following the steps above, at this point I would reboot the guest from within the LiveCD (or the installer would automatically reboot the guest), and at next boot, the installed OS would come up. > > * changing the boot order via UEFI UI does not persist (also setting > resolution, for example) Wow, that's bad. The resolution change is a pretty good test. It should Just Work (TM); it is even testable without any disk or CD-ROM images. ... I can see your QEMU binary is called "/usr/bin/kvm" -- if I recall correctly, that is the name under which Debian (and maybe Ubuntu?) hosts provide QEMU. Can you try the same, with upstream QEMU, from the command line (not systemd)? You could also save and paste the OVMF debug log somewhere (please search the OVMF README for "debugcon"). Note however that for me the debug log is most useful if you set PcdDebugPrintErrorLevel to 0x8040004F in the DSC files (= enable the DEBUG_VERBOSE bit), and then rebuild OVMF. I think it would be best if you could split up and name the log files according to which boot they describe (installation, first boot after installation etc). [snip] >> Right, option >> >> -global driver=cfi.pflash01,property=secure,value=on >> >> is bogus. >> >> I do understand that you tried to invoke QEMU without this option, and >> saw no improvements. However, assuming you installed the guest OS with >> this option in place to begin with, the boot option that the OS >> installer created had surely never reached the right storage (the >> varstore pflash chip). > > The initial start and installation of the VM was without the "global > driver=cfi.pflash01,property=secure,value=on" I introduced it only later on. > > What is a little strange is that *with* this it seems to work a little > better (better is relative here), better as in the changed settings are > kept when doing OS reboot or a OVMF reset. > But as I learned from your explanation the reason for this would be the > fallback to NvVars-on-ESP emulation, where this works somewhat but the > real persistent efivars changes do not. Yes, I think we understand how and why, with the secure property, the variables "almost work". I don't understand why the variables don't work without the property; they should. >>> I'd be glad for any help regarding this! :-) >> Hope this helps, > > I helps really a lot, thanks for the great and detail rich explanation, > I always learn a lot from your posts! > btw. regarding a more auto didactic method to find answers for those > question, is there something recommendable? I'd guess reading the UEFI > spec and OVMF code would be helpful, the latter is - while sounding > really interesting - maybe a little problematic as current university > semester hasn't ended yet and work needs also a little time and I need > some off time from a computer screen here and then :) I recommend reading the OVMF whitepaper (although it is quite long and a bit outdated now). For example, the boot option filtering / reordering is described in it in excruciating detail :) I also recommend browsing the OvmfPkg commit messages (from git-log / git-blame). I really try my best to be detailed, I reference QEMU commits when appropriate, and so on. If everything else fails, just write an email like this. :) Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
