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..
A fallback entry not only removes modules from the intrd file (initramfs-xxx.img) but also removes microcode from booting.
A simple troubleshoot is to manually remove "/boot/intel-ucode.img" at the initrd line (of the 'normal' entry) and see if that boots..
It it boots that means the microcode is not installed or incorrectly and nothing to do with said modules.
If it still does not boot, then the modules that is incorporated into the initrd files somehow have issues with that particular system.
I think in most cases (which is rare) it is the former.
petsam, I'm not sure how to respond. I didn't really understand your source of confusion on my other thread. I asked a question, received a clear, concise answer, marked that answer as the solution, and added a note to that author that it was a success.
On this question, there is clearly an issue with the latest updates. I used a workaround for myself and posted that for anyone else who wants to go that route. However, it doesn't solve the underlying problem. I have plain vanilla hardware, so it is not likely to be some weird situation specific to my system.
Having done my workaround, I'm no longer in a position to try to unravel the actual problem, which I assume will be shared by others. I left this open so that anyone else experiencing the same problem and working through the solution could add an actual direct solution.
If every issue is treated as a unique problem for one user, then this thread can be closed, and every other user who experiences the problem can post the same question again, and people can spend time addressing the issue over and over with each user.
I added several posts here to document as much as I could about my own case to provide whatever clues it can. You provided a suggestion about rebuilding initcpio, which I indicated was essentially the workaround I employed. The difference was that I followed instructions in the other thread (which I linked to here) to first remove autodetect, so that the default GRUB entry became the fallback version. So I can't comment on whether simply rebuilding it without change would also have solved the problem.
You also suggested verifying and cleaning up installed ucodes. In my case, it's too late to see if that would change anything. But even if I could try it, you provided no instructions, assuming that anyone using Manjaro should be familiar with customizing things at that level. Even gohlip's instructions, above, are not adequate, I wouldn't have a clue where to look or exactly what to change. If I needed to pursue it, I'm sure one of you would provide novice-level instructions.
There are three kinds of computer users, ones for whom the computer is a tool to get work done and they rely on it to work without getting under the hood to build it themselves, ones for whom the computer is a tool but they need to be able to strip it and rebuild it, and ones somewhere in the middle who rely on it to work without intervention but are willing on rare occasions to do simple maintenance without automated tools.
Arch is clearly one of the distros that is only practical for people willing and interested in being their own mechanic. Manjaro is a great wrapper when it works, and I can see why a lot of people are attracted to it. But I'm finding that it isn't practical for users who just want to install and use something that can be relied on to work. I've been evaluating it for some weeks and routinely need to tinker with "low-level" stuff on plain vanilla hardware. The stuff that breaks is at a technical level and frequency that I haven't experienced with any other distro targeted at novice users.
With a novice-oriented distro, the forum should be a safety net, not a user manual. I've been a happy Linux user for many years. With Manjaro, I'm dealing with issues I haven't had to deal with before. I've had to refer to this forum extensively, and needed to access the forum with my own questions a number of times, and have gotten solutions. I have muddled through Manjaro and this forum to the best of my ability.
If you find it frustrating trying to help, that would kind of reinforce the observation that Manjaro isn't a good fit for someone lacking the knowledge or interest in taking extensive personal responsibility for their OS.