5 months into Manjaro: harmless yet unacceptable breakage
I installed Manjaro XFCE on my new HP ProDesk 400 G6 Desktop Mini PC on March 14, and it worked flawlessly and without any incident until today, August 25, when it broke. It shouldn’t have happened so.
OK, I know, I’m running Manjaro unstable, which is basically a customized Arch, automatically rebuilt by Manjaro with a few hours delay and no extra testing. But I had to satisfy some specific requirements:
- I wanted to be able to install the very last version of whatever piece of software I wanted, so it had to be Arch.
- I wanted it to have a neat installer, good defaults, and a tool allowing me to stick to a LTS kernel if I wanted to, because one thing I wanted above all: if something breaks, make it not be the kernel. (My problem with Fedora is that during the 6 months between a release and the next one, the kernel changes to whichever version is the latest one, and I did have breakages with that stupid choice of theirs. Officially, Fedora isn’t a rolling-release distro, yet it always updates the kernel to the latest untested version, with no way to keep tracking a still supported older version!)
- In the Arch realm, only EndeavourOS and Manjaro offer you an easy way to stick to an LTS kernel or to switch between kernel lines, with a major difference: EndeavourOS is only a set of scripts, settings, tools, and a few extra packages atop Arch, whereas Manjaro is a delayed rebuild of Arch with a different set of scripts, settings, and tools, with more consistent customizations, and many more extra packages. Therefore, Manjaro can’t use Arch’s repos directly, and it shouldn’t even use AUR, because most packages in Manjaro are at least 2-3 weeks older than in Arch; and yet, once you’re not using Manjaro stable, but Manjaro unstable, you’re practically using the same packages as in Arch, rebuilt with Manjaro’s settings where applicable, with something like a half day’s delay, and that makes AUR less risky to use in terms of compatibility with Arch.
- EndeavourOS is ugly and stupid, for they simply refuse (as a policy!) to provide any GUI package manager (say, Pamac, but I’m also using Octopi), despite their distro being so noobie-oriented! After all, distros like EndeavourOS do exist because Arch doesn’t have a decent installer, and EndeavourOS also has the online release notes and other documentation translated into a few dozens languages, yet they refuse to be of real help to the users by preinstalling the most demanded GUI tool of all, Pamac! Besides, no matter how much I wanted to like their project in spite of the logical inconsistencies of their approach, it really is ugly! I want an OS to be usable “as is,” without the need to fiddle with the default theme and other default settings; as it happens, XFCE or not, EndeavourOS lacks the elegance and the consistency of Manjaro, hence my qualifier: ugly.
- Now, most people should be happy with Manjaro stable as it is, for it has its own extra repo with a nice choice of packages (including e.g.
freeoffice
andsoftmaker-office-2021
), but I needed two things: (1) faster updates than those provided by Manjaro stable or Manjaro testing; and (2) maximum freedom, i.e. to use AUR. While the reliability of AUR is a hit-or-miss thing, once you know a PKGBUILD is good, you’re having a simple way of building and updating a package. If sometimes AUR’s PKGBUILDs are not in sync with the latest versions of the source code or of Arch’s packages, using AUR with Manjaro stable might lead to the opposite situation: a PKGBUILD is updated for newer libraries than available in Manjaro! That’s why I decided to go for Manjaro unstable, which still makes a better choice than vanilla Arch or most Arch derivatives.
And everything worked quite smoothly.

Until today when, after an update and a reboot, my PC entered the BIOS, because it couldn’t find anything to boot!
I was able to boot using either of Super Grub2 and SystemRescue (which I had on a Ventoy USB stick), so I knew the culprit was not the kernel (which, BTW, was still at 5.15.62-2-MANJARO, with 5.18.19-3-MANJARO as an alternative). So it had to be GRUB, which is the most retarded piece of software ever created on planet Earth! (Yes, I still miss LILO.)
I wanted to know what’s the root cause of the issue, other than the fact that GRUB was fucked up: was it Arch-only? Did it also affect Manjaro stable, or only Manjaro unstable, because of Arch?

The first report I found about this issue was on r/archlinux:
Latest Grub update – Testing Repo – couldnt boot
hi,
I am using the testing repos on both Laptop and Desktop PC.
Yesterday I did an update which had a Grub update (Grub 2:2.06.r322.gd9b4638c5-1).
Laptop worked fine but my Desktop PC was unable to boot. It was entering the BIOS menu since it was not able to boot.
The first time I recover the boot entries with Timeshift and it worked fine. Tried again to install the Grub update and again the Desktop PC failed to boot.
In order to fix this issue I have arch-chroot , reinstall efi , grub installation, mkinitcpio -p and everything worked.
It was a very weird issue , did anyone else had this issue?
Replies:
Same thing happened to me now, right after grub update. Came here to check if this was a personal problem, guess not.
and:
I had same today after grub update. Mine was on stable repos.
In the meantime, the thread grew longer.
Then, someone mentioned it in Manjaro’s forums, at the end of the thread [Unstable Update] 2022-08-19 – Kernels, LibreOffice, KDE Frameworks, AMDVLK, Qemu, KDE-git, Haskell, Python. Meanwhile, the issue was moved to a separate thread, Issues with GRUB on the unstable branch:
Same here means my machine boots into Bios after I updated grub package.
The boot into Bios happened with r322. The update was done ~3 hours ago.
Downside now is after going back I don’t have Grub selection anymore with my dual boot. I’ll fix that later. os-prober does detect my second boot option.
Edit: After a timeshift restore and a new install try of grub 2.06.r322 + all other packages it boots normal now.

What happened next?
Manjaro has reverted the grub
package from version 2.06.r322.gd9b4638c5-1 to version 2.06.r261.g2f4430cc0-1. This, however, only prevents further breakage, but it doesn’t repair the existing ones!
Because, you see, reinstalling the grub
package does NOT fix the issue; one has to reinstall GRUB in the boot partition!
Suggestions to fix GRUB? Here, here, or on Manjaro’s forums here. Since instead of using a Live Manjaro stick, I was able to boot into the Manjaro installation using Super Grub2, this is what I did in my case (no need to manjaro-chroot -a
):
sudo grub-install /dev/nvme0n1p1
sudo update-grub
suro reboot
Any output of this kind:
/usr/bin/grub-probe: warning: unknown device type nvme0n1
is innocuous and can safely be ignored (as I said, GRUB is dumb).

All in all, it’s fixed.
All in all, I took my chances when switching from Manjaro stable to Manjaro unstable five months ago, thus exposing myself to the risk of using Arch packages rebuilt without any relevant delay and without any testing by Manjaro.
All in all, whoever is using anything derived from Arch should know what they’re doing. Such stuff is for power users.
But it’s fucking unacceptable, because GRUB is such a fuckingly stupid yet essential shit (thanks, GNU!) that it shouldn’t be changed without testing as if your life depends on it!
I would have accepted a broken 6.0.0rc2 kernel because, you see, it’s not released yet, and even when it will, one shouldn’t rely on it while it still says 6.0.0.
But to have GRUB break a system is simply intolerable, regardless of the distro and branch. How can I recommend Linux as a desktop (not as a fucking container) to anyone? No wonder some people who like throwing their money out of the window go for Apple’s crap: even if nowadays their hardware isn’t what it used to be, at least their OS boots all the time.
Fucking software developers. Aren’t they always willing to change something that works, just because they can?
Well, unless I win the lottery (which I can’t, because I’m not playing), I’ll stick to Manjaro unstable. On the old laptop, I might however install Manjaro stable, without any use of AUR whatsoever. Just to have a more reliable backup machine.
Agreed, grub2 is an over-complicated piece of shit.
I still use grub-legacy (from slackbuilds.org) with an ext2 boot partition.
I’ve tried grub2 a time or two in the past, but why go to all the trouble when grub1 still works?
You may want to try syslinux. It’s simpler than grub2 and is supported on Arch.
I want to try Arch linux /derivative but keep getting discouraged when I hear stories about breakage.
GRUB problems are not unique to distributions like Manjaro or Arch. I remind you my problems with Neptune. For some time, at each update I have had exactly your problem and had to boot with Super Grub2 and then reinstall GRUB on /boot once back in the session.
Super Linux !
I’ve been always tempted to switch to
systemd-boot
, but usually I fall to the “if it ain’t broken …” adage, now with this breakage I went and made the switch, and oh-boy! how easy was that, why didn’t I do that from the beginning, I wonder why?!GRUB won’t fail that often, no matter how annoying it is when it does fail.
systemd-boot
isn’t a magic bullet; nothing beats the simplicity of LILO, except that it doesn’t support UEFI, and ELILO is dead.Furthermore, there is no one-click way to install
systemd-boot
, except maybe when installing Manjaro Architect. There are a few tedious steps to take by hand, which is ridiculous; less ridiculous when you remember that Arch couldn’t be bothered to maintain a real installer, but even Manjaro’ssystemd-boot-manager
only does half of the job — the second half!The Arch page for systemd-boot is a intimidating; generally, Arch has good documentation to help you fix bugs, not do things.
For Manjaro, this page is very helpful: Manjaro with systemd-boot (sd-boot). Still, there is a lot to do by hand. In my case:
Then:
— edit
/etc/fstab
and change/boot/efi
to/boot
— install
systemd-boot-manager
Run:
I guess
sudo sdboot-manage setup
would have replaced both commands.And it works, BUT it destroyed my hibernation! Now I have to remember how I made hibernation work and fix it.
Since I’m on a laptop, and Zram (Zswap disabled) for swapfile functionality, all goes to ram, and so I prefer “Sleep” over “Hibernate” for reasons you -surely?!- know. I hope you find a fix, and please do post it if you find one.
I gave up using
systemd-boot
and returned to GRUB. For hibernation, read Hibernation in Manjaro—For the Lucky Ones.Tiny update:
■ Why some Arch users hate Manjaro, no single user on the stable branch suffered the grub incident from last week. I don’t hate Manjaro, and I don’t blame Manjaro! It was my choice to run Manjaro unstable! It was Arch’s fault all along, who didn’t catch the upstream fuckery by GRUB’s maintainers. Zero QA for “stable” upstream packages!
■ EndeavourOS released this on August 26: Full transparency on the Grub issue (UPDATE 29-08-22). Insights:
It also relays to The latest grub package update needs some manual intervention.
Some day, I’ll explain why I don’t run EndeavourOS.
So Arch/Manjaro/Endeavor pushes the grub2 update with borks the system — causes it be unbootable. Can Arch Linux packages be ‘blacklisted’ or locked from being updated?
I’m just curious. Thanks.
Of course, pinning a package so that it won’t be upgraded is possible in Arch/Manjaro/Endeavor; see 2.1.3 Skip package from being upgraded (groups can also be pinned).
Basically, edit
/etc/pacman.conf
, uncomment the already existingIgnorePkg
, and make it e.g.IgnorePkg=grub
Two notes, though:
1. The recent GRUB issue is an extremely rare incident, I wouldn’t block it from upgrading just for that. (OTOH, why would I need to upgrade GRUB, especially knowing it’s dumb already, and its updates are poorly tested?)
2. Generally speaking, stuff may break because the expected versions of some packages aren’t available, so make sure you know what packages and/or groups you have blocked and for what reason.
One more interesting read: Explaining the actual GRUB reboot issue in detail.
Important fact:
grub-mkconfig
is automatically called, but notgrub-install
.Note:
From a comment:
Also:
The Arch way:
And:
Simply put:
However:
No, I don’t. And no, it’s not fine.