Why `grub-install` cannot be safely automated?

Hi @joekamprad,

I just continue from the other topic…
So there’s nothing I need to fix really… I was just updating the grub theme and then see that the endeavour theme was removed. I look it up and and see that it’s related to the grub issue a long time ago… So I then found the removal announcement here https://endeavouros.com/news/artemis-nova-is-here/

This is purely to indulge my curiosity, but why grub-install make it difficult to safely automate for EOS ? And why then did you need to ship vanilla grub ?

EDIT: I’m sorry for digging up an age old matter for nothing.

No issue with digging on old thread but no one will see your post aside from the persons involved.

The theme removal was more about removing the need to maintain this, and it was also the cause of issues before already. There is really no need to have the bootloader menu themed at all nor to use something like plymouth or similar… users indeed can setup what ever they want , we will still support issues but we do not want clutter installed by default.

The issue with automation is similar, it is not possible to do this in a safe way in case users setup grub in a non default way, may start using grub from a second install with another OS? and may removing grub to use systemd-boot without uninstalling grub ? It would need a complex script / hook service running to do the automation for updating grub files and rebuild grub.cfg others creating implementations doing this like Garuda if i remember. We do try here to stay close to arch, plus we are going a more modern way now using dracut and systemd-boot where default selection inside install process is systemd-boot.

But same as i said for theming users can decide to use what ever they want, you can find AUR builds to automate grub updates or ask in the forum i am sure you will get help on creating this in a working way.

EndeavourOS is providing a simple Desktop with basic setups to start setting up what you need.
And we are as close to arch as we can to avoid issues for the user and maintainment, as we are only a very small bunch of people behind EndeavourOS, doing all this aside from our day to day Jobs and in our free-time.

But this minimalism pays off a lot for stability and issue less running of the OS.


Thank you for the explanation!
In terms of automation, what are the potential issues ? I thought it only involves running grub-install and then sudo grub-mkconfig -o /boot/grub/grub.cfg ?

Some users may have a custom install where ESP is not mounted at /boot/efi which is the default path for grub-install to install the efi binary. Other mount points may be /boot or /efi.

For those cases --efi-directory=/path/to/ESP/mountpoint should be added to grub-install.

Also, I personally don’t update my efi entry in the UEFI settings (NVRAM) each time grub gets updated so I add the --no-nvram option to grub-install.

These are a couple of examples why automation of grub-install may be a bit “awkward”.

1 Like