Full transparency on the GRUB issue - Updated 2022-08-29

[limotux]

@dalto

There is no need for a vote

Thanks a lot @dalto

[anon11595408]

@npaladin2000

that would give the dev team a much better sense of what the community is looking for regarding features and use cases

Let me get this, clearly. So you’re looking for a way for the blind leading the blind?

[anon11595408]

Endeavour should auto install SMB and Bluetooth

Coming to this place, people have to accept that EnOS is NOT a better Windoze, nor does it aspire to be such a thing at all.

[dalto]

Since this is an announcement, please try to stay on-topic here.

[anon11595408]

As hard as it may get, I’ll try my best. - Promise!

[petsam]

I would applaud using existing native utilities for UEFI systems, without any bootloader, in any possible extend.
As we know, UEFI can boot Arch kernels directly, with just a UEFI entry (with efibootmgr).

No bootloader, end of voting

By coincidence, several months ago, I had developed a custom script for automating this, for my own needs, which are not many (no encryption, no subvolumes etc). I suppose it could be extended to discover relevant settings (extra parttioning setup etc.).

[npaladin2000]

I’m all for minimalism when possible (I mostly just boot to zen these days, so I’d just need that and the recovery mode for it) but I really don’t want to lose the ability to boot my Timeshift backups, so grub would have to still be around as a boot option anyway. Of course, I haven’t USED any of my Timeshift snapshots yet either, but I probably won’t need them until after I get rid of my capability to boot to them, that’s just how life works sometimes

The other part is that UEFI utilities are just that…UEFI utilities. Which means it won’t work in a VirtualBox VM (or anything else that boots in BIOS mode). I think that’s why there’s a hesitance to change anything regarding the bootloader, the current (grub) setup works for a huge number of situations.

[anon11595408]

@npaladin2000

I really don’t want to lose the ability to boot my Timeshift backups, so grub would have to still be around as a boot option anyway. Of course, I haven’t USED any of my Timeshift snapshots yet either, but I probably won’t need them until after I get rid of my capability to boot to them, that’s just how life works sometimes

Have you tried pretending your system is down, and restoring any Timeshift backup yet? I guess not?!

→ Exercise before you speak.

Oooops!!! - I am OT, again! Sorry, @dalto !

[joekamprad]

@npaladin2000

Maybe so but the recent issue has generated a lot of interest in the subject. Might not be a bad thing for the community as a whole to discuss as well, that would give the dev team a much better sense of what the community is looking for regarding features and use cases.

i do not say anything against this, but not here… it is very confusing for someone having the grub issue reading to 2500 unrelated posts only… as io say already and as @dalto already … repeated:

Back to the topic or feel free to start a new thread for other discussions

[serutan]

You got a big shout out for your work from Brodie Robertson (@11:40)…

GRUB Broke My Arch Linux Installation!!

[kiamlaluno]

I had the luck to read the warning on this site before updating. I waited some days to see if there would be a Grub update to fix the issue, and then updated following the instructions given on the pinned post.
For this, I must thank you: You saved me troubles.

I understand that not being able to boot on Endeavour after an update is not the best experience, but I also understand that changing bootloader too quickly could be seen as a knee-jerk reaction.

[jonathon]

Just as a little point of pedantry,

@dalto

What caused the issue

…
If the version of grub you have installed via the grub-install command didn’t support that command

the failure only happens when grub-mkconfig is run in this situation (which is the case in EnOS due to the pacman hook). In vanilla Arch grub-mkconfig is not run automatically, hence the failures there were much more limited than in derivatives where there is an update hook.

[dalto]

@jonathon

the failure only happens when grub-mkconfig is run in this situation

Yes, that has been discussed several places in this topic already.

One such mention is here:

Full transparency on the GRUB issue - Updated 2022-08-29

To be fair, I think you need to look at this from their perspective as well. If you use grub the way Arch ships the package, this issue wouldn’t occur yet some people are trying to place all the blame for this on the Arch team. The situation is complicated which is why I have been trying to not to assign blame anywhere. It took a lot of things including EOS or the end-user automating grub-mkconfig for it to happen. So who’s fault is it? It is grub’s fault because they made the change(excep…

[jonathon]

Sorry, this was a TLDR on my part…

(All of these recent GRUB threads are too long and drain my spirit faster than anything I’ve come across recently…)

[sradjoker]

You’re not the only one

[manuel]

Note that Arch users were left with a time bomb because they don’t call grub-mkconfig automatically. Now, if the Arch user has another reason to call grub-mkconfig later, he/she will encounter the same issue (unless he/she calls grub-install too).

[andrewb]

The Arch grub wiki puzzles me with the Arch users situation and where distros are stuck at. Ref: https://wiki.archlinux.org/title/GRUB#Generated_grub.cfg

The Warning box mentions about the mismatch between bootloader and the config file as you imply. If and when either side of Grub gets updated, this situation could repeat (based on the scenarios and changes obviously). This is what Arch based distros hit, being that the bootloader with grub-install was out of sync.

The Tip box a bit later mentions that one needs to re-run grub-mkconfig after a kernel install. Which most Arch users likely don’t do, but most distros do and took some heat on Arch bug https://bugs.archlinux.org/task/75701 about this.

I have seen Arch BBS and Arch reddit posts of users hitting this Grub issue (one recently, saying they are BIOS/MBR!), not nearly as many as I’d expect or compare to the EOS social sites.

This leads me to feel very sketchy about grub in Arch. Void is still on a Grub version from July 4 2021, but had some build/dependency updates recently. Reference URL.

[dalto]

@andrewb

I have seen Arch BBS and Arch reddit posts of users hitting this Grub issue (one recently, saying they are BIOS/MBR!), not nearly as many as I’d expect or compare to the EOS social sites.

This is probably due to 2 reasons:

• Many Arch UEFI users are using systemd-boot
• Arch doesn’t ship with hooks for running grub-mkconfig

[jonathon]

@andrewb

This leads me to feel very sketchy about grub in Arch

I don’t know why it should. There has been one issue, once, and it was trivially resolved.

[vlkon]

@jonathon

once

That is one more than some people can handle.
This just shows how much is arch linux stable that there is not so many opportunities for the “drama people” to panic about.