No issues. I believe the solution to all my update problems was to do a clean install – ON A NEW SSD. I am pretty sure my aging SSD though it passed basic tests, gave me pre-failure and old age status in many categories. I am glad I did a clean install. I really like the seat of the pants extra snappy feel from the btrfs file system.
One thing that might help in the future is to familiarize yourself with all the hooks that get triggered during an update… and get a feel for what “success” looks like… and to pay attention to any errors.
Very early on in the process, it is indicated that the old initcpio images (may not use that word) are deleted… as later in the hook process mkinitcpio
is run to rebuild fresh images based on any kernel/etc updates and then follows that up with update-grub
to refresh the image files in it’s list.
If there were problems/errors with the mkinitcpio
or update-grub
hooks, DO NOT REBOOT until you have resolved them manually… and/or in case of a pamac-gui
crash… confirmed the update isn’t still in progress in the background. Something like cat /var/log/pacman.log
should give good progress feedback… and perhaps even a terminal tool like htop
.
Note: If you’ve always used the pamac gui and never clicked the “chevron” (might have been better to say greater than sign “>”) in the lower right corner to watch its recorded sequence of all update events… then much of what I’ve said above will be completely new to you… no worries as /var/log/pacman.log
is your friend… you can scroll through it to see all past updates and hopefully get a sense for what things look like when all goes right. This understanding will help you recognise when things go wrong.
Remember to not take too many adventures this time.
This is why I consider running
pacman-mirrors --country United_Kingdom
before an update to be essential (change United_Kingdom for your country).
I don’t know if this has changed, but some of us were finding the UK mirrors to be unreliable; I waited half the afternoon for them to sync during one of the updates and even then, they were only up for long enough for me to grab all the updates with a little to spare, then disappeared again for another few hours.
I switched my mirrors to Germany for this reason. No issues since.
Also worthy of note: I use pacman -Syu
for system upgrades; Pamac (CLI) ONLY for AUR.
Refresh mirrors:
It’s good to do this fairly regularly. See Manjaro Mirrors.
sudo pacman-mirrors --continent
The update trilogy:
We really should make this into a movie; people might pay attention.
sudo pacman -Syu
pamac update --aur
flatpak update
(The last command relevant only if you use flatpak).
I do often click on the chevron to view the update log.
The problem was the tool completely removing all logs from my sight, due to just crashing. There could be some crash handling code that would open a bare-bones window with tail -f pacman.log
. That would at least give feedback to the user that work is still being done in the background.
Also, IIRC, pamac will update all main packages and all AUR ones too. I tend to use the pamac-manager GUI because it lets me to uncheck the AUR packages. (I’d rather update them afterwards.) Now I see I should run pacman -Syu
instead of pamac.
(side-note: some AUR packages take a long while to compile, and if any of them fails, all AUR updates are aborted. This forces me to recompile the other packages that did not fail, which is a waste of time.)
Mod edit:- Example syntax corrected. It is recommended to use only one “y
” in the pacman command, like so: sudo pacman -Syu
, unless specifically directed otherwise.
Since the last Manjaro update, I have been facing a problem where the images no longer load, even after installing new kernels, generating new initramfs, and so on.
It always stops at this hook and never moves past it… It looks stuck bootloader
Any suggestions on how to get my Manjaro to load the environment again? I only did the usual updates… Thanks.
No idea what is happening, but you can try moving to a systemd hook array. And maybe put autodetect a little earlier. Kms may also make a difference. And removing Plymouth.
https://wiki.archlinux.org/title/Mkinitcpio
The most common reason for not booting is graphical. Also, on the boot line in grub remove quiet and splash may reveal more messages. Actually start with this.
Of course journal -b -1 might also be helful. From a chroot.
Hi there!
I always boot without splash and quiet to see the logs. I removed a specific driver (amdgpu) and regenerated the initramfs using the ‘autodetect’ option, with the ‘udev’ hook set to run first.
Now, subsystems don’t load and it gets stuck on the displayed message.
[Manjaro’s Kernel Log]
Passwd: manjaroisgreat
The hook has been fixed, but the issue persists
Thanks !
I don’t have more ideas for now, sorry
It certainly went further this time.
“…extra snappy feel from the btrfs file system.”
That is weird, considering it is one of the slowest filesystems around.
You are right it is 0.4% slower then ext4
“When taking the geometric mean of all the file-systems tested”
But has snapshots, compression, checksums and RAID buildt in.
In this test, the standard btrfs mount options were used, meaning compression was disabled (which is obviously important for comparability). This means that deployment with compression enabled can be significantly slower/faster.
I personally recommend enabling zstd compression with btrfs.