Its probably because when you have flashed your key, your system was in bios so the key is also in bios mode. When you are in UEFI, you can’t use a device that use the bios mode.
No it doesn’t. The command worked flawlessly for many years.
During the shim lock problem I also tried the proper commands and they would trigger the same problem.
On my first chroot, I downgraded and used grub install … And it worked just fine.
The command is wrong but it works
You can read the other thread where this was discussed.
I see.
I wonder why don’t we do it for EndeavourOS.
I am thinking of having your hook and your script by default as I assume they will work with almost any hardware.
I wonder why? There must be logic and reason for sure.
So, this is the answer.
So, I should create the bootable flash disk with the OS in UEFI mode to be able to boot from it.
OK, I got some work to do.
Thank you
Because it is too risky to make assumptions about every user’s setup. The script I gave you earlier in this thread forces the user to adapt the options to fit their needs. My more complicated script does still make assumptions, namely, that the boot device is the same device that contains the root filesystem. This is not always the case and should not be assumed for every user. Many dual and multi-boot systems with more than one hard drive will not fall into my script’s assumption.
Even Debian has to ask the user for input when reinstalling grub during an update. It does not happen often with the stable release, but it can. Afaik, pacman does not have the capability to do an interactive reinstallation of grub to the hard drive when the grub package is upgraded.
1 Like
The ISO should be able to boot in either mode regardless the boot mode of the system on which it was created (if I am not mistaken 
)
The crucial thing here is which boot mode supports the system that it is going to be installed on.
One could simply go into the firmware settings and check.
I know that its the case in a vm context, but for me its related to the fact we directly use the iso.
Regardless the boot mode of the “host” system, you could for example use dd to write the iso onto a usb flash drive.
The resulting usb is capable of booting in either mode since it is the way the iso is created.
What mode it will boot up in reality, depends on the firmware (settings) of the system it is going to be used on.
Just tried, you right. So its only a problem with windows ? 
Sure I understand the point.
But does this mean that other distros doing this automatically are taking some risk of breaking things?
Maybe the machine is too old, as far as I remember it is over 10 years old! or it is me who is too old and can’t do it! I should consider this possibility.
At least with Debian based systems, the answer is no since Debian will pop up a dialog box asking where to reinstall grub if it needs to. This only ever happened to me during an upgrade from one stable release to the next. Static release Linux distros will use the same version of grub the the duration of the stable release, so reinstallation is a very rare thing. Static releases will apply security patches to grub as needed, but the version remains the same.
1 Like
It could be that it doesn’t support UEFI.
The only way of knowing would be to go into the firmware settings and check.
1 Like
I see, and thank you very much @eznix for the fruitfull enlighting conversation.
I really learned a lot from you.
Thank you very much. I really appreciate it.
I haven’t seen anything EFI there!
So, it is the machine that is too old!
It sounds like a legacy/bios/mbr system then.
systemd-boot is out of the question since it only works with UEFI.
If you wish, you could subscribe to the following link in a rss reader to follow the development on Grub in Arch:
https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/commits/main/PKGBUILD?format=atom
You would know then a bit in advance that a grub update is incoming.
If you want to ignore updates to grub temporarily, instead of adding it to IgnorPkg in pacman.conf, you could use --ignore with your pacman update command:
sudo pacman -Syu --ignore grub
This is true on UEFI only if it has CSM enable and or legacy boot support.
Sure!
1 Like
Might be worded differently in Bios/firmware settings. Just converted my installation from grub to systemd-boot yesterday as I did not have systemd-boot selectable during install even when my system was supposed to be in UEFI mode. After mucking about found my motherboard notes it under CSM combability and even when its set on automatic instead of enabled installer reads it as legacy bios mode.
Turning CSM completely off fixed things. It should be noted that turning it off also broke the Grub and stopped the machine from booting. I was already prepared to chroot due to switching to systemd-boot.
UEFI has quite universally been supported since 2010/2011, so if the machine is ~10 years old there’s a high possibility that UEFI is supported, but it might be named differently in the firmware settings.
I did some searching around;
Your inxi indicates boot to be in uefi-[legacy]. Found Fujitsu laptop from the same time period, Lifebook AH512 (Yours is AH531), which has UEFi possibility but is disabled via CSM compatibility mode.
For AH512 model this can be changed via following settings, these should be same for your system.
- Security – Secure Boot Configuration – Secure Boot Option : [Disabled]
- Advanced – Boot Configurations – Fast Boot : [Disabled]
- Advanced – Boot Configurations – CSM : [Disabled]
1 Like