Date
1 - 17 of 17
Cannot start acrn.efi
|
Ross Burton <ross.burton@...>
Hi,
I'm obviously doing something wrong but am curious if anyone knows what this error message means. Either via adding a boot item with efibootmgr, or by writing a loader for systemd-boot that starts acrn.efi, all I get is this: : Not Found Press any key to continue This is on a NUC. Is that a message from the firmware saying it can't find acrn.efi? Is that acrn.efi saying it can't find the loader it wants to start? Thanks, Ross |
|
|
|
Ross Burton <ross.burton@...>
On Thu, 24 Jan 2019 at 16:27, Burton, Ross <ross.burton@...> wrote:
: Not FoundUsing a EFI shell I managed to determine that this is what happens if you don't pass the loader argument. Something like: fs1:: Not Found Right, that's understood. So now if bootx86 is actually systemd-boot, why does this hang and not do anything: fs1:That's been hanging for 30 minutes so far. Can acrn be started from the EFI shell? Should that have worked? Any tips to debug this? Thanks, Ross |
|
|
|
Hi Ross,
toggle quoted message
Show quoted text
-----Original Message-----You can start it from the EFI shell, it should work. We've had some issues with old-ish bios so if you have not done so yet, I would recommend you upgrade your bios to the latest. That's the system-boot efi binary from a Yocto distro, isn't it? What happens if you start bootx86.efi from the EFI shell directly, do you see the boot menu with all entries from /loader/entries?
|
|
|
|
toggle quoted message
Show quoted text
-----Original Message-----One other thing that crossed my mind. If I was correct above that this is systemd-boot from Yocto, I would assume that the acrn.efi hypervisor was also built with Yocto? If true, I would recommend that you just grab a pre-built acrn.efi from an installation that you know works correctly and try to use that instead. We have seen issues in the past where we could built the hypervisor on a different OS but it would not work.
|
|
|
|
Ross Burton <ross.burton@...>
On Thu, 24 Jan 2019 at 21:22, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote: One other thing that crossed my mind. If I was correct above that this is systemd-boot from Yocto, I would assume that the acrn.efi hypervisor was also built with Yocto? If true, I would recommend that you just grab a pre-built acrn.efi from an installation that you know works correctly and try to use that instead. We have seen issues in the past where we could built the hypervisor on a different OS but it would not work.You're right. I extracted the acrn.efi from a past Clear release and that boots. So, how does one debug acrn not starting up when I compile it? From what I can tell, both myself and the clearlinux spec are both using the same config. Ross |
|
|
|
toggle quoted message
Show quoted text
-----Original Message-----I'm not too sure to be honest. I would start by comparing the compiler and binutils versions you have with the ones from Clear Linux, this is where it's most likely broken. Geoffroy
|
|
|
|
Ross Burton <ross.burton@...>
On Fri, 25 Jan 2019 at 12:43, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote: I'm not too sure to be honest. I would start by comparing the compiler and binutils versions you have with the ones from Clear Linux, this is where it's most likely broken.Same major version. Would the memory settings cause it to not even start up the bootloader? Can I turn on some level of debugging? Ross |
|
|
|
Ross Burton <ross.burton@...>
I guess the big difference is that I'm building git master, whereas
toggle quoted message
Show quoted text
the Clear package is 2019w03.2.160000p. How much testing does master go under? Ross On Fri, 25 Jan 2019 at 13:52, Burton, Ross <ross.burton@...> wrote:
|
|
|
|
toggle quoted message
Show quoted text
-----Original Message-----Nanlin can correct me if I'm wrong but the CI tests the hypervisor on the NUC and also checks that a UOS can be started. Is your system-boot configure to show its menu (at least temporarily)? I'd like to understand if it fails to load the bootloader or if it hangs later on (when loading your SOS kernel).
|
|
|
|
Ross Burton <ross.burton@...>
On Fri, 25 Jan 2019 at 17:43, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote: Is your system-boot configure to show its menu (at least temporarily)? I'd like to understand if it fails to load the bootloader or if it hangs later on (when loading your SOS kernel).No, systemd-boot doesn't show, it just hangs so fails to start the bootloader. Verified it's not user error at boot time by having both my own acrn.efi and Clear's acrn.efi on the same disk and booting both of them. Ross |
|
|
|
toggle quoted message
Show quoted text
-----Original Message-----Thanks for confirming this. Are you able to easily get the same tag to be compiled by your Yocto environment to narrow down if it's a compilation/tooling issue or a regression in master? Geoffroy
|
|
|
|
Ross Burton <ross.burton@...>
On Fri, 25 Jan 2019 at 17:58, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote: Thanks for confirming this. Are you able to easily get the same tag to be compiled by your Yocto environment to narrow down if it's a compilation/tooling issue or a regression in master?So the difference between that tag and 0.5 is minimal: $ git diff v0.5 acrn-2019w03.2-160000p --stat VERSION | 2 +- devicemodel/samples/nuc/launch_uos.sh | 2 +- doc/getting-started/apl-nuc.rst | 36 ++++++++++++++++++------------------ doc/tutorials/create-up2-images.sh | 2 +- doc/tutorials/using_sbl_on_up2.rst | 8 ++++---- efi-stub/clearlinux/acrn.conf | 2 +- 6 files changed, 26 insertions(+), 26 deletions(-) Building my 0.5-based image now. Ross |
|
|
|
toggle quoted message
Show quoted text
-----Original Message-----Then I would be very surprised if the result is different than what you got before... I can't think of any change in those files that would cause such a regression. But hey, this wouldn't be the first I get surprised and am proven wrong! :-)
|
|
|
|
Ross Burton <ross.burton@...>
Huh, against all expectations I think I made it work with 0.5!
Happy with that for now. Shall re-test master again after the weekend. Is there a way to verify that I'm running under the acrn hypervisor without using a special kernel? Some magic flag that can be examined from a standard kernel without the acrn patches? Ross On Fri, 25 Jan 2019 at 18:47, Geoffroy Van Cutsem <geoffroy.vancutsem@...> wrote: -----Original Message-----Then I would be very surprised if the result is different than what you got before... I can't think of any change in those files that would cause such a regression. But hey, this wouldn't be the first I get surprised and am proven wrong! :-) |
|
|
|
toggle quoted message
Show quoted text
-----Original Message-----Well this is unexpected, but I'm very glad in a way you got it to run! I'm really not sure about that. I know that if you run "cpuid -l 0x40000000" from within a Service OS, it will tell you that the hypervisor_id is "ACRNACRNACRN". But I'm not sure whether this is still true if the kernel does not have the ACRN patches in.
|
|
|
|
Ross Burton <ross.burton@...>
On Tue, 29 Jan 2019 at 23:41, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote: root@bob:~# cpuid -l 0x40000000Is there a way to verify that I'm running under the acrn hypervisor withoutI'm really not sure about that. I know that if you run "cpuid -l 0x40000000" from within a Service OS, it will tell you that the hypervisor_id is "ACRNACRNACRN". But I'm not sure whether this is still true if the kernel does not have the ACRN patches in. CPU 0: hypervisor_id = "ACRNACRNACRN" No custom kernel needed, the hypervisor is intercepting the calls. Ross |
|
|
|
toggle quoted message
Show quoted text
-----Original Message-----Thanks for confirming this Ross, it's a good trick to know. Geoffroy
|
|
|