Also due to this issue, many users went through a crash course of partitions (especially getting a the names right), mounting, chrooting and are now probably way more confident in fixing their systems in the future.
Maybe that’s one positive thing to come out of it.
Yes, the amount of complaining I’ve seen is far less than people using our troubleshooting post to solve their issue or seek our help otherwise and still have a bootable system.
They’re even saying that they would visit the forum or other channels before updating in the future which I think is also a positive thing. Very few people have said they’ll move away from or even grub
I’d also like to remind people about that time where updating Ubuntu could more or less completely remove the OS. It was at that time that I installed Ubuntu on my work machine because I thought that it would be less trouble than an Arch-based distro (and on my work machine I really can’t spent too much time tinkering with these kinds of problems…), but lo and behold my first update after getting the laptop uninstalled the kernel and 90% of system relevant packages (all I did was press update now in GUI manager)…
Obviously there were ways to solve this problem and there was quite the elaborate warning message if you knew where to look for (which I ignored since it wouldn’t let me install anything without ‘updating’), but the moral of the story for me is that these kind of ‘accidents’ happen on all distros, not just rolling release ones. (Similar ‘fun’ stuff also happened on Windows to me, but that is a different story…)
This is a big part of the issue with installs also because many users lack the understanding of partitions and partitioning requirements. No one needs to be a technical genius for all things Arch or linux but they do need to understand the things they are attempting to do. Most users who lack the technical knowledge rely on clicking on icons to do anything and if it fails they are stuck. Or they rely on sticking a usb in and launching it expecting everything to just automatically work including the install.
I am not an expert but i try to help in the best way i can in explaining what needs to be done and why with the things that i do have knowledge. I don’t always get it right. Sometimes I’m wrong or i explain it in a way that’s not correct or what ever. Even if i was an expert i wouldn’t be going around on my high horse looking down on those who haven’t reached my level of expertise. You can’t teach everyone your level of expertise. It takes knowledge, time, experience and or training. But you can be helpful and teach them the part that they are dealing with. Every little part adds up to knowledge, experience, time and expertise.
I just want to say that I got bit by this, but overall had a great experience do to the communication of the team and this forum. You guys did great, and I’m just more happy on my decision to use endevouros because of it.
I had a few more issues because I’m encrypted and run on btrfs, but the directions (once I saw the huge banner at the top of the screen) were able to lead me in the correct direction. In the few years now running arch this is the first non-booting issue I’ve ever had and it turned out to be not that bad after all is said and done.
** I did just fully update another endevouros system (right now), and I’m not seeing any warning/message about running grub-install, fyi
Teach them how to fish, don’t catch their fish for them.
They’ll thank you in the long run, assuming they hang around long enough.
No, it is not.
Easy to install is not beginner friendly. Arch requires understanding to maintain and periodically fix going forward. Arch is not set and forget, Arch is not idiot proof.
There are users that don’t even know what a paritition is.
LOL. Until it breaks, then they flounder with zero knowledge and blame everyone else.
If you have no interest in how your system works you should be using a different distro.
Wanky gui installation tools don’t help in the long run, they just keep people ignorant / dumb.
Say it aint so.
What is to understand?
A change was made that required a one off update to the grub efi stub. It is not rocket surgery.
Not even an issue with grub bootloader itself, but with a default uefi entry that arguably shouldn’t be there in the first place.
If users want to access their BIOS do it the standard way, not from your bootloader.
If you want a fix just create a pacman hook to remove or replace /etc/grub.d/30_uefi-firmware post install or update. First thing I do post grub update is nuke that file.
We get it, you like systemd-boot.
Red Hat / Fedora develop systemd, and they still use grub2 by default.
There is no reason to switch from grub other than to cater for the lazy idiots that don’t want to understand how their bootloader works or utiilize its features. Arch wiki grub2 doco is fantastic.
os-prober is crap and not needed, just teach users how to make custom chainload entries in /etc/grub.d/40_custom. It is as easy as creating systemd-boot entries, just different.
For each additional bootable UEFI OS just point it to an efi partition, and chainload the path to the efi stub. Could not be simpler.
menuentry "[OS] Label" {
set root="hd[n],gpt[n]"
chainloader /EFI/[OS]/grubx64.efi
}
systemd-boot is not the answer as it doesn’t support fully encrypted installs.
rEFInd only supports uefi, so it is not the answer either.
Just a question here but how difficult would it be machanically to maintain the bootloader (whatever bootloader) out of Endeavour’s repos, even if it happens to be grub? I mean, new installs would be relatively easy, but for the people already using Arch’s grub, I guess a new EOS bootloader would have to be a dependency on one of the base EOS packages, and conflict with Arch’s grub (and probably Arch’s systemd-boot too) to make sure it gets removed? Sounds a little painful, plus it’s inching a little further away from being Arch-adjacent.
While I have certainly seen this in other places, I have been pleasantly surprised that we haven’t seen much of it here with this issue. There are plenty of people who have needed help to resolve this issue but there hasn’t been a lot of blame, finger pointing or entitled behaviour.
What the perspective of the grub devs is. Keep in mind, this change wasn’t something they actually released so we need to understand if this is something they see as needing to be fixed or if they see it as normal.
Just because this is the first time it has happened doesn’t mean it is a “one-off”. That is part of what we are trying to understand.
Not to point out the obvious but you have no idea which bootloaders we are considering or what our reasoning is.
So everybody is an idiot except you! The Arch wiki is not fantastic. It’s technical information which is written in a way that requires more knowledge than a lot of users have to understand it whether you use Arch or not. It may be an encyclopedia of information. For some it’s good others it’s great for some it’s not helpful if they don’t understand it. What are they to do just not use Arch because you say so.
I din’t know much about Git/Github and how all this works. So anybody writes code and asks the dev(s) to implement this code in the program. That’s what “commit” means, correct? And Arch includes this code, that has not been approved by the Grub dev(s), in their package?
Is that an accepted approach in the Linux world?
Not exactly. A commit means someone with write access to the code has added/removed/changed some code(or some other file). It could have from a contributor or one of the core devs. Either way, one of the grub devs would have either approved or written in the code for it to be commit.
The way it works in most projects is some variant of this:
Multiple commits happen over a period of time.
Eventually the team decides it is time to do a release with a version. i.e. 2.06
I just was faced with this Bug a few days ago and had to fix my system and now I see a new Grub Update, while installing new Updates.
Is the new Version grub-2:2.06.r322.gd9b4638c5-3 again safe to install? Or is it better to hold of the Updates for the foreseeable future?
That version is the same as the prior, it just adds a postinstall message. So if you fixed your system by running grub-install it should be fine. If you downgraded grub, it still has the same “issue” as the last release.
Okay thanks than I’ll risk it as I did the recommended Grub-Install last time, hoping I won’t have to create a new USB Drive
My company doesn’t like the use of Work Equipment outside of work just for burning USB Drives
users went through a crash course of partitions (especially getting a the names right), mounting, chrooting and are now probably way more confident in fixing their systems in the future.
