You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using 2022.02 tag ONIE with grub-2.04 and saw this issue at the end of NOS installation. Please check below log.
========================================================================
... (Skipped)
Support tarball created:/mnt/ubuntu/ufispace/install/onie-support-ufispace_icelake_common.tar.bz2
INFO:Update ONIE grub configuration..
329.010661]ext4 filesystem being mounted at /tmp/tmp.DqqOHK supports timestamps until 2038 (0x7fffffff)
INFO: Previous boot Order: 0000,0002,0006,0003,0004,0005
INFO: Regular GRUB install..
Installing for x86 64-efi platform. grub-install: error: GRUB was not built with efivar support; cannot register EFI boot entry.
ERROR: grub-install failed on:/dev/sda
INFO: Current boot Order: 0000,0002,0006,0003,0004,0005
ONIE: Rebooting...
After tracing the install.sh of demo_install_uefi_grub, we found the difference was that the demo code used "--no-nvram" parameter and used efibootmgr tool to configure the boot option/order, while some NOS did not have "--no-nvram" and thus grub-install(in grub-2.04) would need efivar support for boot option/order manipulation. https://github.com/opencomputeproject/onie/blob/2022.02/demo/installer/grub-arch/install.sh#L293
The above log showed the error and the installer failed to set boot order using grub-install, so after installation the BIOS booted to ONIE again with boot order unchanged.
So my question is, do we have to build the Grub with efivar supported to cover different NOS's installation behavior? If so, how do we do it?
We had "UEFI_ENABLE = yes" configured in the machine.make but it seemed not to work for building grub with efivar support.
Please kindly help on this issue, thanks.
Jay
The text was updated successfully, but these errors were encountered:
Hi - thanks for the use of output and contextual details in filing this.
My first question is: am I correctly understanding your question:
Grub is being built without EFI support, so it cannot modify nvram to add boot entries when running grub-install.
A NOS that uses --no-nvram (which, as I understand it, is used when one wants an install to be present, but without having nvram modified ) installs fine, (probably because it is not attempting to perform the unsupported NVRAM operations ) but is also not selected when the system reboots ( though I'd hope it would be present as a boot option - probably through UEFI's ability to discover configurations by reading the EFI partition )
A NOS that does not use --no-nvram has the efivar error because it is trying to exercise code that Grub was not built to support.
It currently looks like the problem is that ONIE grub needs to be built with efivar support (which makes sense, since it can modify NVRAM unless a --no-nvram specifies not to ), and the question is: How to do that, because UEFI_ENABLE = yes does not seem to be doing the job.
If I've read that all correctly - my second question is: is this reproducible on the x86 KVM virtual platform, and if so, exactly how is it being built/run? ...as that's about the extent of my debug options these days.
From all this I'd think the default should be to have UEFI / NVRAM support on by default, but I'm open to the possibility that there is more to it than that.
Hi @ehdoyle ,
Thanks for your prompt response!
Yes I think you correctly understood my questions according to your description.
I'm not sure why and whether different NOS vendors use grub-install with or without "--no-nvram", but you're right, ONIE grub may need to be built with efivar support (specifying --no-nvram shouldn't be a must).
As we can see from below patch description, by doing this, there're some benefit we can get. https://github.com/opencomputeproject/onie/blob/master/patches/grub/2.04/efi-variable-storage-minimise-writes.patch
For now, we'll check with our vendor if they can modify the install.sh based on demo OS's, and see how we can build ONIE grub with efivar and efiboot libraries. Please also update if you have the answer.
Hello everyone,
We're using 2022.02 tag ONIE with grub-2.04 and saw this issue at the end of NOS installation. Please check below log.
========================================================================
... (Skipped)
Support tarball created:/mnt/ubuntu/ufispace/install/onie-support-ufispace_icelake_common.tar.bz2
INFO:Update ONIE grub configuration..
329.010661]ext4 filesystem being mounted at /tmp/tmp.DqqOHK supports timestamps until 2038 (0x7fffffff)
INFO: Previous boot Order: 0000,0002,0006,0003,0004,0005
INFO: Regular GRUB install..
Installing for x86 64-efi platform.
grub-install: error: GRUB was not built with efivar support; cannot register EFI boot entry.
ERROR: grub-install failed on:/dev/sda
INFO: Current boot Order: 0000,0002,0006,0003,0004,0005
ONIE: Rebooting...
========================================================================
After tracing the install.sh of demo_install_uefi_grub, we found the difference was that the demo code used "--no-nvram" parameter and used efibootmgr tool to configure the boot option/order, while some NOS did not have "--no-nvram" and thus grub-install(in grub-2.04) would need efivar support for boot option/order manipulation.
https://github.com/opencomputeproject/onie/blob/2022.02/demo/installer/grub-arch/install.sh#L293
The above log showed the error and the installer failed to set boot order using grub-install, so after installation the BIOS booted to ONIE again with boot order unchanged.
So my question is, do we have to build the Grub with efivar supported to cover different NOS's installation behavior? If so, how do we do it?
We had "UEFI_ENABLE = yes" configured in the machine.make but it seemed not to work for building grub with efivar support.
Please kindly help on this issue, thanks.
Jay
The text was updated successfully, but these errors were encountered: