[Stable Update] 2022-04-15 - Kernels, Mesa, Nvidia, Budgie, PipeWire, LIbreOffice, KDE Frameworks, Wine

Here is the error I get falling the WIKI you provide:

sudo rm -r /etc/pacman.d/gnupg 
rm: cannot remove '/etc/pacman.d/gnupg': Device or resource busy

Not fixed. No help on the WIKI as to fix this problem.

There seems to be something using the directory, are you running another update proces somewhere else?

This command might reveal the process: lsof | grep /etc/pacman.d/gnupg

lsof | grep /etc/pacman.d/gnupg returns nothing.

Howver, skipping the sudo rm -r /etc/pacman.d/gnupg and continuing on to the next step seems to have fixed the problem.

1 Like

A little question, do you recommend to use the new kernel 5.17 if i have a dual boot? I m a little worried that it will break.

There were some nodejs related problems.

I am not sure what caused them, but renaming the /usr/lib/node_modules dir to node_modules.bak solved the problem.

Again there were some warnings…

But everything went okay and update finished.

EDIT (New problem) :

When I booted few minutes ago just before writing this, same problem, like last time happened,

but this time my laptop didn’t go to hibernation. Fixed with same steps as last time. Reinstalled linux516 and linux510, reinstalled grub, updated grub (grub-update).

Would you have installed npm packages system-wide through npm instead of the system package manager?

3 posts were split to a new topic: Shortcuts for screenshot is not working after the update

I installed postcss-cli globally through npm.
Sorry, about the screenshots, the output was so massive, I couldn’t copy them.

And, Another Update regarding this, Like last update, I encountered similar issue, “Boot image not found”,
but this time my laptop did not go to hibernation, instead aforementioned error happened when booting , just before writing this. Solved that just like last time, reinstalled linux516 linux510, reinstalled grub, and updated it grub-update.

Reading this I have to wonder: Did LibreOffice stop crashing on long (novel length) documents? Why I swore off it.

Probably the wrong place to ask, I know. :slight_smile:

Since this update, I have a problem with Déjà Dup:

Message recipient disconnected from message bus without replying

The storage location is a remote Nextcloud server that used to work like a charm.

Any idea to troubleshoot?

Seems like sleeping is still hit or miss. It works only about 70% of the time which makes sleeping extremely unreliable.

Guess sleeping is just one of these things that its just not possible to get working properly on Linux (at least not in my experience, I have never had a laptop where it worked reliably).

8 days later (22-04-29) I finally went to do this upgrade.
After fresh ‘pacman -Syy’, I did ‘pacman -Suuw’
and at the end it got :

error: systemd-libs: signature from "Mark Wagie <mark@manjaro.org>" is unknown trust
:: File /var/cache/pacman/pkg/systemd-libs-250.4-2-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n

and so on.

Does “the issue is resolved” mean this should not happen?
If so, how did it happen for me?

EDIT: it happened because I used ‘w’ with pacman. Details in this reply

Should there be a note in the wiki post …

Btw, I didn’t delete files,
I ran ‘sudo pacman-key --refresh-keys’
then ran ‘sudo pacman -Suuw’ again, and it verified OK.

On my system, that cached file is dated March 17… which is prior to all the manjaro-ring updates.

$ ls -la /var/cache/pacman/pkg/systemd*
-rw-r--r-- 1 root root 9415279 Feb  8 09:38 /var/cache/pacman/pkg/systemd-250.3-3-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root 9414151 Feb 10 13:03 /var/cache/pacman/pkg/systemd-250.3-4-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root 9424928 Mar 11 10:06 /var/cache/pacman/pkg/systemd-250.4-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root 9425072 Mar 17 17:46 /var/cache/pacman/pkg/systemd-250.4-2-x86_64.pkg.tar.zst

It would appear to me that old/cached packages associated to an older key that has now been updated should be removed. As these old/cached packages are sitting in our pacman cache, that’s an issue for us as users to resolve (and I think deletion is a good reaction), not manjaro. That said; I think it would be fair to receive some advise or “best practices” from Manjaro on how to manage this situation.

One easy (although wide sweeping) way to do this (assuming your using KDE) would be to open the the pamac gui and purge the cache; although that could be an issue if you ever wanted to downgrade a package.

I think the command you found is the best solution… purging cached packages that no longer match the keyring (I’m assuming that’s what it does) sounds like a good thing to do. I’m going to look more into pacman -Suuw to see if I should add it to my “post update” tool chest.

1 Like

I’m running 5.17 kernel just fine, but that being said I ALWAYS keep the last 2 working LTS kernels on my system as well so that if the latest kernel won’t boot I can simply reboot and select a different kernel from the grub menu. I’d recommend at a bare minimum to always keep at least 1 other LTS kernel that works with your system so that if for whatever reason the latest stable kernel breaks anything you have a quick and easy way to get working until the issue is resolved.

1 Like

issue is probably more due to the MB manufacturer and bios not following established standards strictly. I haven’t had any issues with sleep or hibernation with my HP elite book laptop that has been running manjaro for a couple of years now. That being said I have an old cheap thinkcentre desktop that clear linux or red hat won’t recognize it as EFI but debian or manjaro can boot efi just fine, The problem is all the manufacturers tend to cut corners especially when the standards are new and then never get around to fixing them or can’t fix them after release. Windows has had issues with sleep and hibernation for years and still do. It’s not always the softwares fault it usually is the hardware/UEFI/bios implementation of sleep.


that message also says the file could be corrupt. have your tried deleting

sudo rm /var/cache/pacman/pkg/systemd-libs-250.4-2-x86_64.pkg.tar.zst

so that the system re-downloads the file?

No, sorry, it doesn’t.

It updates all the keys in the keyring.
(And takes about half an hour to do it!)

It’s not for post-update, it’s pre-update, use it to start with.

‘w’ downloads packages but does not do the upgrade (does not install them).
I prefer to make sure all the packages are in (and some potential problems solved) before running the upgrade.

The extra ‘u’ allows downgrading as well as upgrading. It has no effect unless the Manjaro team marked a package to be downgraded, which happens rarely.

When the packages are all in, I do ‘sudo pacman -Suu’ to run the upgrade,
and it uses the already-downloaded packages.

At the end of my post I wrote

For me, the problem was solved already.
The file was not corrupt.
The problem was that one signing key had been changed, but was not in the keyring.

The point of the message was that this issue should be mentioned in the wiki post if it can still affect other people, despite the fact that @Yochanan said the keyring had been updated. (Maybe the new keyring file has not been pushed to the stable repo?)

I was replying to @Yochanan, and he is well aware of the nature of the problem, so I didn’t describe it in more detail. (It has been discussed elsewhere in these forums and on reddit.)

I got it: it happened because I used ‘w’ with pacman (only download).
Then not until you start to install the update do you get
“Some packages should be upgraded first…
… archlinux-keyring-20220424-1 manjaro-keyring-20220421-1”.

When using -Suw, the download finishes before the keyring is updated,
and then the old keyring is used to check the downloaded files,
and packages signed with a new (unknown) key cause that error.

Could this be regarded as a bug in pacman?
It should update its keys before downloading with the ‘w’ option…

Thanks, 5.15 works fine, so it ll be my “backup” kernel, i want to try 5.17 to see if the permormance change.