Critical grub-install failure. Systems possibly non-bootable?

Software
1

Greetings!

As I was wrapping up the usual batch of updates / upgrades on my systems before the holidays, I encountered a seemingly critical problem with my pair of ROC-RK-3328-CC (Renegade) boards. I ran apt-get update as usual and then apt-get upgrade on them both. The upgrade command warned me that the updated kernel was being held back, which it always does, but I allowed it to continue as I usually upgrade the kernel standalone after the other packages. When the upgrade process ran, on both systems, I received the following output:

Setting up grub-efi-arm64 (2.06-3~deb11u5) …
Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: efivarfs_set_variable: failed to create /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c for writing: Read-only file system.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only file system.
Failed: grub-install --target=arm64-efi
WARNING: Bootloader is not properly installed, system may not be bootable
Generating grub configuration file …

The output was identical on both systems so I googled it and found some documentation from 2021 here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990966

That thread halfway seems to indicate that this might not actually be a true problem I am seeing but when you look at the /sys/firmware/efi/efivars/ filesystem it is indeed mounted ro and the Boot0000-… file is absent and as is mentioned in the thread that could keep the system from booting. After poking around google a little more I proceeded with my normal pattern of running apt autoremove (to remove the outdated 6.0.11 kernel) and then apt-get upgrade --with-new-pkgs (to install 6.0.15) and those 2 procedures completed with no errors being reported.

So for the moment I am leaving the pair sitting just as they are since they are running just fine, but I won’t try a reboot until I can get some clarification as to whether this is indeed a possible boot-preventing problem or if it is just overzealous background noise. I did session capture the entire process on both nodes so I can paste it over here if that would help, but I didn’t see a point at this stage as everything else ran nominally.

Cheers!

1 Like
2

On PC systems, the motherboard stores state. This includes EFI variables to tell the motherboard where the boot files are located. GRUB expects everything to be like PC systems where EFI variables are stored on NVMEM. On PCs, nobody moves SSDs but if you do, your system becomes unbootable because the EFI variables stored the boot file location. This is inherently a non-starter on SBCs.

As the SBCs have MicroSD cards for storage which are moved all the time, we don’t have non-volatile storage on the boards themselves so there is no state and we see it as an bad idea to store state. If you move your MicroSD card, it becomes un-bootable in another system which would be really frustrating for users and frankly kind of dumb.

The error can be safely ignored and has no impact on the existing GRUB already installed. You can update the installed GRUB by running grub-install with the --no-nvram flag but even this is not necessary for the proper operation of your machine.

Just to break down how GRUB works:

  1. grub deb package is install via apt
  2. grub-install runs and installs modules to /boot/grub directory and EFI miniloader into /boot/efi
  3. grub-update updates /boot/grub/grub.cfg with the menu entries like when everytime you update the kernel

In your case a new version of grub was released and updated (1). grub-install fails on lack of writable EFI variables (2) but this is inconsequential. You can run sudo grub-install --target=arm64-efi --no-nvram --force-extra-removable instead which does the same thing. You can run sudo grub-update but it’s optional.

1 Like
3

Thanks very much for the detailed explanation! It all makes perfect sense and was much more helpful than replies I’ve received elsewhere in the past that were just terse answers with no details. On both systems I ran grub-install --target=arm64-efi --no-nvram --force-extra-removable which ran smoothly and finished reporting “Installation finished. No error reported.” which was nice. I also ran update-grub on both systems and it ran smooth as well. I assumed that you meant run “update-grub” as usual and not “grub-update” as typed since the latter doesn’t seem to exist.

1 Like
4

Yes, update-grub. It rewrites /boot/grub/grub.cfg

1 Like