EndeavourOS Boot via Grub fails on MSI Motherboards

General system Kernel, boot, graphics & hardware
1

After a CMOS CLR due to a MB temperature below zero deg Centigrade (most probably), it is not possible to boot into EndeavourOS any more. Surprisingly, a similar problem appears after major Windows updates. CentOS and Ubuntu are immun and boot alright.

Rescue Option 1:

https://wiki.archlinux.org/title/systemd-boot
efibootmgr --create --disk /dev/nvme1n1p2 --loader "\EFI\EndeavourOS-grub\grubx64.efi" --label "EndeavourOS-grub" --verbose

does not work as MSI MBs are peculiar about efibootmgr not accepting it.

Rescue Option 2:

https://wiki.archlinux.org/title/GRUB#Default/fallback_boot_path

mv esp/EFI/grub esp/EFI/BOOT
mv esp/EFI/BOOT/grubx64.efi esp/EFI/BOOT/BOOTX64.EFI

does not work as then in BOOT and identical .efi exists but NVMe does not know about them.

Rescue Option 3:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub --removable

does not work, too, due to not installing the NVMe entry for me.

Option 4:

re-install works!

Question 1: which command does the installer run which fixes the problem?

Question 2: why are other OS immun? (EDIT)

For reference, EFI files in comparison - Secure Boot is off:

[root@localhost EFI]# ls -al ubuntu/
total 3488
drwx------. 2 root root    4096 Dec 13  2020 .
drwx------. 7 root root    4096 Jan  1 13:04 ..
-rwx------. 1 root root     108 Sep  9 12:53 BOOTX64.CSV
-rwx------. 1 root root     117 Sep  9 12:53 grub.cfg
-rwx------. 1 root root 1734528 Sep  9 12:53 grubx64.efi
-rwx------. 1 root root  856232 Sep  9 12:53 mmx64.efi
-rwx------. 1 root root  955656 Sep  9 12:53 shimx64.efi

[root@localhost EFI]# ls -al endeavouros-2723/
total 148
drwx------. 2 root root   4096 Dec 25 20:42 .
drwx------. 7 root root   4096 Jan  1 13:04 ..
-rwx------. 1 root root 143360 Dec 25 20:42 grubx64.efi
2

not really understand what that means :wink: it errors out ? and running this inside chroot after installing grub into installed system from there?

3

The grub-install command run by Calamares varies based on what it detects but one difference is it uses --force

Here is the relevant code:

1 Like
4

not really understand what that means :wink: it errors out ? and running this inside chroot after installing grub into installed system from there?

yes that is following the instructions closely; it says, it has successfully installed. Here “fails” means did not work, rather (edited above).

5

Any ideas as to why other OS are immun?

6

Yes. But did you repair it already? Is it still failing? Did you use The Force?

Ubuntu and RHbased systems use Secure boot signatures/certificates and installation methods.
The one that reset EnOS entry, probably has a reason to reset only the non-certified (non-SecureBoot) entries. (vendor or WinOS)

1 Like
7

What is the hardware? I have lots of MSI boards.

inxi -Faz | eos-sendlog
8 
[root@Z590 ~]# inxi -Faz | eos-sendlog
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6006    0    24  100  5982     29   7344 --:--:-- --:--:-- --:--:--  7369
https://clbin.com/M8vtJ
9

Just tried now: The Force fixes the problem! :slightly_smiling_face:

--removable just (also) puts it under /BOOT, I guess.

If aware, then one may have arch-root occasionally to fix boot issues which is sort of OK.

1 Like
10

There is a new UEFI update for that board that has new CPU Microcode and adjustments for the pci-e lanes.

Version 7D09v14
Release Date 2022-01-12

  • Update CPU Microcode
  • Adjust PCIe Lanes setting
1 Like
11

Thanks, I missed that and updated BIOS with due diligence: guess what happened :upside_down_face:

BTW, is --removable really required?

12

Not in normal circumstances.

1 Like
13

It wouldn’t boot again? I would find this strange. All i know is that on dual boot Windows i have Secure Boot disabled, CSM turned off and I set to UEFI only not UEFI [legacy]. I also remove the secure boot keys before turning off secure boot. In Windows i have the fast start up feature in power management turned off.

1 Like
14

Right. So have I, all of the above. It took a while to figure removing the secure keys as well. Mind you, this time I did not.

However, that behaviour has always existed with EnOS since a few years and even on MSI (EDIT) AMD boards - for me, that is. I have not tweaked anything. I have a multi-boot Windows, EnOS, Ubuntu, CentOS.

Ubuntu and RHbased systems use Secure boot signatures/certificates and installation methods.
The one that reset EnOS entry, probably has a reason to reset only the non-certified (non-SecureBoot) entries. (vendor or WinOS).

That probably explains it but I have not been able to follow all of it.

15

I haven’t experienced this at all but then again i don’t run Ubuntu or Centos. I do run Windows and EOS. I would assume that the issue has something to do with those secure boot signatures/certificates on those distro’s and grub.

1 Like
16

https://bbs.archlinux.org/viewtopic.php?id=250928

supports the argument kind of.

17

Those posts are 2008. UEFI specification was barely 4 years old. UEFI specs have changed and I’m sure there were lots of issues prior. I’m just not seeing this on any MSI boards i have currently. :man_shrugging:

1 Like
18

A diff between my and your configuration might reveal the problem? :innocent:

19

Maybe but as i said before I’m not using Ubuntu or Centos. I have triple boot Eos currently and i do use grub but i also use rEFInd as a boot manager.

1 Like
20

rEFInd could be a solution. I am going to try Alma to facilitate arch-chroot when having to re-install grub every other month.

I guess, no one else on multi-boot is having these issues?