On 05/09/2016 06:06 PM, Laszlo Ersek wrote: > 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.) Yes, it always got booted, as it was in front of the boot order list. >> * 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.
Yes, exactly I'm on a Debian based system and the KVM is self build as we have our own repos and want newer versions of KVM/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). Ok, I'll try that also, but I got it working for now (have to retest everything from scratch another time but it looks promising). I changed out the QEMU-pure-efi.fd with the QEMU_CODE-pure-efi.fd and got it working, this is the primary error from my side, without this the VARS file never got written as I used the firmware intended to be used without an separate VAR store. One thing is a little strange for me: For getting the Boot order to work I have to first add an Boot entry with QEMU-disk:\EFI\BOOT\BOOTX64.EFI only after that the bootindex parameter from the QEMU command works, else a "Misc Device" is present in the boot list which also boots my OS, so I guess that it is pointed at BOOTX64.EFI located on the QEMU disk. So if I understand correctly the disk gets recognized but does not gets connected with the bootindex settings (=the FwCfg) but if I add manually an entry this "connection" works. [snip] >>>> 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. Ok, thanks for the tips, I'll read the whitepaper first to get a basic idea. > If everything else fails, just write an email like this. :) OK, will do :) Thanks! Thomas _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
