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

A post was merged into an existing topic: Issue with recent install

A post was merged into an existing topic: Issue with recent install

Thatā€™s a big if, given the patching that Arch is doing is to address issues that have not yet reached an upstream release, e.g.:

I wish people wouldnā€™t assume things when it comes to ā€œstableā€ releases, patching, etc. etc. etc.

2 Likes

Are you honestly being serious here? How on Earth is this issue in EnOS, caused by an automated hook in EnOS, a fault of the Arch developers? How on Earth is the lack of skill of EnOS users to be able to reinstall GRUB using a chroot (which is an incredibly common task that people have to do regularly, after BIOS/UEFI updates, Windows updates, ā€¦, ā€¦) a fault of the Arch developers?

This sort of unrealistic expectation of things never breaking, ever, and that developers needs to make knee-jerk reactions to mitigate issues found by a subset of users (even though those issues are trivially resolved), is why open source developers throw in the towel.

If you want something that doesnā€™t break (except those times when it does) then use a consumer OS.

6 Likes

Well, yes, because updates in Arch didnā€™t expose a problem, so how would anyone know until it hits sufficient critical mass that it gets reported?

2 Likes

Guess you missed the part where it affected Arch users too? Which is why it didnā€™t reflect well on the Arch devs.

So every bug or regression in any piece of software reflects poorly on the Arch devs? Very unrealistic.

2 Likes

Hi @npaladin2000
I found this It's not just Arch having problems with Grub

It seems to be Grub developers not Arch.

Oh i know the Arch devs arenā€™t the only one to grab pre release code from the grub devs. That doesnā€™t absolve then from doing it though, nor from from how they handled the situation. Really just not a good situation all around, so i kinda understand the desire ofsome people to find an alternative. Heck two bootloaders isnā€™t the worst idea, redundancy and all

1 Like

For something as important as a bootloader, when they take near a week to even let anyone know that thereā€™s a high chance for breakage if your use it the way they tell you to, yes. And afterwards blaming it on other distros and falsely claiming Arch users arenā€™t impacted. Yes. They also said they donā€™t have enough testers for this, but released it anyway. Thatā€™s on then too. Sad state of affairs, but thatā€™s what happens with something this serious and significant.

2 Likes

You mean rEFInd? While trying it I noticed it was attempting to boot using Grub which I couldnā€™t understand!
What is the point in bootloader calling another boot loader?

Or Can we have systemd-boot AND Grub?

Itā€™s one bootloader, not the only bootloader. Arch doesnā€™t tell you to install GRUB, thatā€™s up to the user to decide on.

No, there was zero chance of breakage if you use it the way the Arch wiki says to.

So - unless software is thoroughly tested then it shouldnā€™t be released to the repos. Gotcha.

I think you have an incorrect view of what Arch is and how things work, generally. Of course, if youā€™d like to step up and join the Arch releng and/or testing team Iā€™m sure theyā€™d be glad of the extra help.

3 Likes

Yeah i have both installed and have UEFI entries for both. Plus rEFInd can call grub too.

A user should always be prepared for this sort of glitch when using a rolling release distro that tends to take packages from upstream quickly, with minimal patching (and preferrably no patching).

From the Arch wiki page on System Maintenance, the section Upgrading the system:

Make sure to have the Arch install media or another Linux ā€œliveā€ CD/USB available so you can easily rescue your system if there is a problem after updating.

Oh, and by the way:

Users must be vigilant and take responsibility for maintaining their own system.

:point_up:

Also:

ā€¦upgrading packages can raise unexpected problems that could need immediate intervention; therefore, it is discouraged to upgrade a stable system shortly before it is required for carrying out an important task.

8 Likes

not zero :wink: because if you may had just installed a second kernel before the update and your local grub files was installed some times ago you would need to have to run grub-mkconfig and it would be the same issue ā€¦

1 Like

Or used whatever method for creating the config file - grub-mkconfig isnā€™t the only one.

Youā€™re also talking about an edge-case where youā€™re making a change in addition to updating GRUB.

1 Like

Plus if your integrating grub with btrfs snapshots the way the Arch Wiki tells you to do, youā€™d be impacted.

cause of that i used would :wink:
And there are 4 kernels in arch repo so possible it can happen :sunglasses:

2 Likes

Yes indeed - there are plenty of edge-cases that would expose the issue (which is how bugs are found, rather than happy-cases).

1 Like

rEFInd offers you the choice. You can hide the Grub boot or uninstall Grub and then rEFind wonā€™t offer it.
I use rEFInd but maintain a Grub boot as itā€™s generally, but not always, a distros default bootloader.

1 Like