SlayerProof32, thanks for the response. Yes, I both reinstalled and updated GRUB (that was actually the solution to a previous boot problem involving Ubuntu messing up GRUB, so it was the first thing I tried).
In a sense, this issue has been overtaken by events in my own case. The fallback initramfs boot option didn’t suffer from this error. In another thread here, I was advised how to make that the default boot option, so I can now boot without this error coming into play.
The actual problem has not been solved, though, and if anyone else runs into it, it will still need a solution, so I won’t mark this as solved.
But for others experiencing the problem:
- Temporary workaround: use the GRUB selection “Advanced options for Manjaro Linux” and select the option marked “fallback initramfs”.
- Permanent workaround to avoid the problem: make the fallback initramfs option the default boot option (see How to make fallback boot the default).
Please make sure that the UUID of your devices are the same as the ones it says it can’t find.
Strit, as I indicated in my previous post, I’ve implemented a workaround to avoid the problem, so I can’t easily go back and do diagnostics or verify what Manjaro thought were the UUIDs.
However, there was nothing that I changed in terms of hardware or software. I just booted Manjaro normally and successfully, and then ran the package manager to install the updates.
The next step was that I rebooted into openSUSE and then Ubuntu (in that order), and updated those. Those two distros had only a few updates each, minor stuff that shouldn’t have affected anything else (they all share GRUB, but that wasn’t updated by either other distro).
Then I rebooted into Manjaro just to verify that it wasn’t affected, and the default boot thought Manjaro was hibernated and that the UUIDs were changed; the fallback initramfs boot didn’t have an issue. Having Manjaro reinstall and update GRUB didn’t affect the problem, so there is no way by which updates in the other distros could have affected Manjaro.
If the UUIDs and the hibernated status actually changed, it would appear to be the result of the Manjaro updates. However, the fact that the fallback boot didn’t have an issue suggests that the symptom may be an artifact (and it seems like that could only have come from the Manjaro updates).
@fixer1234, I had your same issue, what caused you to hibernate was the missed file
amd-ucode because your OS were upgraded to Illyria 18.0-rc which did not come with the installed file
You can check from the comment 68 of my topic Boot EFI stopped working in a removable external HDD on Mac mini.
And see the instructions and my comment in another same topic:
This maybe a combination of some mentioned possibilities.
AFAIK fallback just loads all possible modules, instead of the normal that loads selected. This means UUIDs are not wrong. Maybe an mkinitcpio module change.
You could rebuild initcpio
sudo mkinitcpio -P sudo update-grub
Also verify your installed ucodes, intel, amd and remove the un-needed. Of course, update grub after that.
And check - compare grub entries flags, normal vs. fallback.
gusbemacbe, what you wrote sounds consistent. Trying to follow the threads you linked to, one talked about AMD being split to be consistent with Intel. The machine with the problem is Intel-based, and that thread read like Intel shouldn’t have been affected. I wasn’t able to follow what the solution is. One thread seemed to indicate that Manjaro should be reinstalled from scratch.
The situation is a bit strange. AMD and Intel cover the vast majority of machines. If both are affected, and the problem is that the update left out a key file (or no longer requires it but failed to update a configuration that looks for it), this should impact a lot of users rather than just a few.
The simple solution… As you are always stuck in the rootfs like me, unfortunately you have to reinstall, then to follow the instructions of the comment #2 of [Testing Update] 2018-10-08 - Upstream Updates (if your PC is an Intel-based, install only intel-ucode and remove amd-ucode) and the instructions of @AgentS . Pray that the book and the grub work.
WE just do not know which branch and version of OS you are using.
If you do not want to reinstall and never give up on fixing the boot and grub, I think @gohlip can help you. He is very good at it and knows very well this issue.
petsam, my workaround was to make the fallback the default boot, so it included a modification before what you suggested.
I’m still a Linux novice, and more of a user. I’m evaluating Manjaro as a potential replacement for Mint KDE. If I had the expertise, time, and inclination to verify what’s in the update packages and rebuild things, I’d be looking at Arch, instead. I kind of rely on a stable-class distro getting the big things right.
I keep finding that Manjaro is a nice wrapper for Arch and keeps things easy if you just use it to get work done and do the automated basics. But there seem to be a lot of holes and edges where you suddenly find yourself dealing with Arch. I’m getting the impression that Manjaro isn’t really a Mint replacement for novice users, it’s more of an interface for Arch users, or people for whom Arch is a good fit.
Mint novice users is not the same as Manjaro novice users. The difference is, Manjaro users, novice or not can/will be able to read English and willing to learn how the system works.
My above advice was for Newbies.
Have your own way, as it’s your right.
As I had mentioned, if the uefi installation is on a removable disk, once it is removed, the disk will not boot up.
First , after installation, do not remove the disk.
Make sure everything works.
To make it removable, perform grub-install with --removable.
When removed and plugged back in. you have to go to boot-setup key (F8 ~ F12) to boot the removable.
I had repeated this several times.
Shall not repeat it again.
Even if this (removable is not an issue), there can be many other reasons for not booting up in another system. A graphic card installed for one system will not work for the other. And there are others too, A swap for example in fstab specified for the internal. And more.
So we should always make sure it works for one before taking it to another system.
That much is pretty clear.
Otherwise we will make others helping out go nuts besides driving ourselves nuts.
Now put into one system and do not remove disk after installation.
If you still have a problem
Start a new topic.
I will not continue here.
As for intel-ucode and amd-ucode, there should not be any problem whether or not it is needed or present or not. As long as update-grub is performed after any installation or removal of microcode and manjaro is the default grub.
gusbemacbe, I’m in the stable path with KDE. The computer is an old Windows 7 laptop, so BIOS-based rather than UEFI. Reinstalling entails a lot of redoing the customization; days of work. It’s a pain in the butt, which was an attraction of the rolling release. I’ll reinstall if necessary, but if it’s anything close to a regular requirement, Manjaro loses a lot of its luster.
I’m not seeing any relevant instructions in your comment #2 link.
I’m not familiar with the nitty-gritty components of the OS, or installing and removing relevant/irrelevant chunks of stuff to build my own system, or figure out what the distro got wrong. If I run into a critical one-time problem with the system I am relying on, and can find detailed instructions, I’ve been known to dig in and get it fixed. But I’m just evaluating Manjaro, and I keep running into situations that require inordinate learning time and hands-on intervention at a level I’m not really prepared to engage in, especially on a regular basis. I suspect Manjaro isn’t a good fit for me.
I have a workaround for the immediate issue, so in this case, I don’t need to solve the underlying problem. Thanks for your input. It sounds like a good start for other users who may land here with the same problem.
BTW, I saw gohlip’s message above. That ends with a statement about the microcode issue not being relevant if GRUB is updated. I did update GRUB, so maybe my symptoms have a different cause.
Yes, it is a lot and a lot of work, I have reinstalled 12 times due to broken boot-loader because my HDD is external and is removable, but also because of the missed
*-ucode files and I did not know and/or understand what happened with the boot and grub until I have checked that topic, read those instructions and figured what happened.
Yesterday I reinstalled 17.1.2, but after running
sudo pacman -Syyu, I was upgraded to 18.0-rc1 without being aware and I have checked using
lsb_release, I was too scared, then I had to follow the instructions because I am afraid of getting stuck again in the rootfs.
We hope the developers fix the broken boot and grub and also the missed
*-ucode files in the next release candidate.
This is obviosly not the typical Manjaro user experience. If it were, Manjaro would not be rated #1 on Distrowatch. The average user should have no difficulty installing Manjaro.
Of course some hardware combinations are problematic with Linux. That is not a Manjaro shortcoming, but is usually the result of the hardware manufacturer refusing to release open source drivers. Generally that is the same situation with most other distros. Manjaro is certainly no worse than most others in that regard.
Generally most Manjaro installs are problem free and do not require a great amount of work to get operating. Obviously some hardware poses greater challenges to get working on Linux. Saying Manjaro “is a lot and a lot of work” is a gross exaggeration when it comes to the average install.
IMO the only area that requires more effort with Manjaro is in performing maintenance tasks, which naturally require more intervention than on a static distro.
Too bad, Apple computers are too and too closed-source. Better I get a new PC with a new SSD and get rid of removable and external HDD, but I fear I buy the wrong processors, wrong motherboards and wrong video cards because I do not know if they are compatible with Linux or whose hardware manufacturers accept to release open source drivers.
Are you referring to https://wiki.manjaro.org/System_Maintenance?
Yes that section of the wiki is certainly pertinent. Do you know about pacnew files and how to deal with them yet?
The main amount of extra work is simply keeping apprised of update issues by following the update thread. That way you won’t get blind sided by a hardware breakage that is a known issue. As long as you read the update notices you should be able to avoid most breakages.
There will of course also be more frequent updates on a rolling distro, so that of course entails more work to keep your system operating properly.
Then it was my fault. I love the command
-Syyu the which I run daily and I was too blind for ignoring the breakages. I should have read the announcements topics before making something stupid. If I was not blind, I would save myself from 12 times.
I’m not saying it was your fault, but reading the update thread is the surest way to avoid breakages. This discussion is really off topic to the original issue on this thread, so I will leave my comments at that.
You are mis-using the forum support IMHO. Either you need help and follow instructions, or close the topic as “I know best what I need” marking your post as a Solution…
I am too frustrated with your way you dealt with your issue with several topics, to commend calmly, so I leave it to your imagination…