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

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.

Just curious, yesterday noticed some first time ever seen program upgrading manjaro-application-utility … tried to find it in XFCE menus, nowhere. tried to find it with whisker menu search “manjaro” and “application” … nothing. Finally launched it from bash, it actually exists and launches and is actually pretty cute nice app. Why it’s not in the menus anywhere?? Is this some kind of easter-egg kinda thing intentional?

In the Gome Editin it is part of the Manjaro Hello application. Perhaps it is the same in XFCE. :slight_smile:

Don’t have manjaro-hello anymore. Never wanted it, never used it. Still would like manjaro-application-utility to be accessible from menus and be like “normal app”. At minimum why couldn’t it be part of the manjaro-settings-manager?? Would make perfect sense.

Until the above happens, or if it doesn’t, you could create a .desktop file in .local/share/applications for manjaro-application-utility and run update-desktop-database ~/.local/share/applications/. Pay attention to the Categories= line (if xfce, X-XFCE-SettingsDialog;Settings; ). This will control where the app appears in the desktop menu and the system settings menu, unfortunately not the Manjaro Settings. The xml file /etc/xdg/menus/xfce-settings-manager.menu, shows menu layout and available categories. desktop-file-edit or exo-desktop-item-edit are helpful tools. I have better luck with the later. There’s also desktop-file-validate.

1 Like

A post was split to a new topic: My internal microphone is no longer detected

It is part of Manjaro Hello in XFCE , through the “Applications” button. I guess that @deemon has removed it on purpose.

Thanks @Skunkie for your suggestion about the update.
After pamac install gjs-git sushi is working again :+1: