Description of problem: Boot CentOS 7.4 1708 aarch64 iso from virtio scsi cdrom ok by UEFI on aarch64, and install the os, then shutdown it after reboot and turn to boot from virtio scsi hard disk, it failed all the time. Version-Release number of selected component (if applicable): qemu-kvm-ev-2.9.0-16.el7_4.11.1.aarch64 libvirt-daemon-3.9.0-1.el7.aarch64 AAVMF-20170228-5.gitc325e41585e3.el7.noarch How reproducible: Steps to Reproduce: 1.virsh define the vm 2.virsh edit the vm, set it to boot from cdrom 3.virsh start the vm, use remote-viewer to connect to the vm by vnc protocol, and then virsh console to choose centos iso boot menu, then install the os by vnc 4. reboot after the installation done, then virsh destroy the vm 5.virsh edit the vm, set it to boot from hard disk 6. virsh console and connect by vnc, it failed and drop to UEFI SHELL Actual results: it boot from hard disk failed , and drop to UEFI SHELL Expected results: boot from hard disk OK. Additional info: The OS section of the xml is as following: <os> <type arch='aarch64' machine='virt-rhel7.4.0'>hvm</type> <loader readonly='yes' secure='no' type='rom'>/usr/share/AAVMF/AAVMF_CODE.verbose.fd</loader> <nvram>/var/lib/libvirt/qemu/nvram/centos-container-dbg_VARS.fd</nvram> <boot dev='hd'/> </os> The error info from virsh console is as following: FSOpen: Open '\EFI\BOOT\BOOTAA64.EFI' Success [Bds] DevicePath expand: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0) -> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,FAD459AB-EB71-4136-AA2B-55C82307475B,0x800,0x64000)/\EFI\BOOT\BOOTAA64.EFI [Security] 3rd party image[0] can be loaded after EndOfDxe: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,FAD459AB-EB71-4136-AA2B-55C82307475B,0x800,0x64000)/\EFI\BOOT\BOOTAA64.EFI. InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B9249840 Loading driver at 0x000B8593000 EntryPoint=0x000B8593148 Loading driver at 0x000B8593000 EntryPoint=0x000B8593148 InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF B9379598 ProtectUefiImageCommon - 0xB9249840 - 0x00000000B8593000 - 0x00000000000C2A48 !!!!!!!! ProtectUefiImageCommon - Section Alignment(0x20) is incorrect !!!!!!!! FSOpen: Open '\EFI\BOOT\fbaa64.efi' Success FSOpen: Open '\EFI\BOOT\fbaa64.efi' Success Section 0 has negative size Failed to load image: Unsupported start_image() returned Unsupported Error: Image at 000B8593000 start failed: Unsupported ProtectUefiImageCommon - 0xB9249840 - 0x00000000B8593000 - 0x00000000000C2A48 !!!!!!!! ProtectUefiImageCommon - Section Alignment(0x20) is incorrect !!!!!!!! Unloading driver at 0x000B8593000 Image Return Status = Unsupported
<disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/dev/CentOS-7-aarch64.qcow2'/> <target dev='sda' bus='scsi'/> <alias name='scsi0-0-0-0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/home/dev/CentOS-7-aarch64-Everything.iso'/> <target dev='sdb' bus='scsi'/> <readonly/> <alias name='scsi0-0-0-1'/> </disk>
It seems like a bug for CentOS altarch aarch64 iso or AAVMF. In the UEFI SHELL, I execute FS0:\EFI\BOOT\BOOTAA64.EFI, it return error to me. Shell> FS0:\EFI\BOOT\BOOTAA64.EFI dppath: \EFI\BOOT\BOOTAA64.EFI path: FS0:\EFI\BOOT\BOOTAA64.EFI Section 0 has negative size Failed to load image: Unsupported start_image() returned Unsupported Error: Image at 000B8467000 start failed: Unsupported Unloading driver at 0x000B8467000 But when I change to execute FS0:\EFI\BOOT\fbaa64.efi in the UEFI SHELL, it will boot OK. So the defaut boot option in AAVMF for CentOS should be fbaa64.efi? Shell> FS0:\EFI\BOOT\fbaa64.efi
Yes, i have the same issue as you
I have root caused this bug to a problem in the UEFI shim loader code. I've tested the fix and posted the patch as a pull request to https://github.com/rhboot/shim Hopefully someone with familiarity with that code base can take a look at the patch I posted and provide some code review feedback to help move things along. By the way, I'm guessing someone will want to update the category of this bug? It isn't really a libvirt issue. Thanks, -Maran Wilson
Cool, moving to Fedora shim component. The referenced pull request is https://github.com/rhboot/shim/pull/142
(In reply to Maran Wilson from comment #4) > I have root caused this bug to a problem in the UEFI shim loader code. I've > tested the fix and posted the patch as a pull request to > https://github.com/rhboot/shim > > Hopefully someone with familiarity with that code base can take a look at > the patch I posted and provide some code review feedback to help move things > along. Thanks, Maran I haven't tested your patch, but from the commit log, the patch seems to resolve the issue "failing to load the fbaa64.efi image". But I thought the original bug (this one) is failing to load "FS0:\EFI\BOOT\BOOTAA64.EFI". But when vanlos use the fbaa64.efi, it can be boot successfully without any bugs. @vanlos, do you agree with my description above? Cheers, Jia
(In reply to jia he from comment #6) > (In reply to Maran Wilson from comment #4) > > I have root caused this bug to a problem in the UEFI shim loader code. I've > > tested the fix and posted the patch as a pull request to > > https://github.com/rhboot/shim > > > > Hopefully someone with familiarity with that code base can take a look at > > the patch I posted and provide some code review feedback to help move things > > along. > Thanks, Maran > I haven't tested your patch, but from the commit log, the patch seems to > resolve the issue "failing to load the fbaa64.efi image". But I thought the > original bug (this one) is failing to load "FS0:\EFI\BOOT\BOOTAA64.EFI". But > when vanlos use the fbaa64.efi, it can be boot successfully without any bugs. > > @vanlos, do you agree with my description above? > > Cheers, > Jia It all makes sense because there are two ways to load a EFI program. One way is to invoke it directly on the EFI shell prompt (as @vanlos reported above). In that case, the EFI shell is the SW component that is loading the fbaa64.efi program into memory and executing it. That comes from the EDK2 source code and works just fine. However, the second way to load a EFI program is to use the EFI shell (or it can happen automatically when you boot clean VM with an imported disk image) to launch the shim EFI program (BOOTAA64.EFI) which then, in turn, does the work itself to load the fbaa64.efi. That is where the bug is located -- in the shim code used to compile BOOTAA64.EFI. So in both failing experiments above, BOOTAA64.EFI has already loaded and begun its own execution and then prints out the error message about "Section 0 has negative size" when it tries to load and execute fbaa64.efi itself.
Just a reminder: I've posted a patch that fixes this problem as a pull request to https://github.com/rhboot/shim (pull request #142). The pull request has been reviewed and approved by Javier Martinez Canillas, and waiting to be pulled in. If there is anything else I can help with to either get the proposed patch accepted let me know. I'm also happy to assist in putting together an alternative solution if there is something about the current proposal that is not ideal.
(In reply to Maran Wilson from comment #8) > Just a reminder: I've posted a patch that fixes this problem as a pull > request to https://github.com/rhboot/shim (pull request #142). > > The pull request has been reviewed and approved by Javier Martinez Canillas, > and waiting to be pulled in. > > If there is anything else I can help with to either get the proposed patch > accepted let me know. I'm also happy to assist in putting together an > alternative solution if there is something about the current proposal that > is not ideal. I presume peter will commit it next time he's working on shim code. if a commit hits git before your patch is pulled, try pinging again. At least in Fedora shim isn't updated often so work seems to be batched up
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.