[ARM Stable Update] 2022-05-06 - Firefox 100, Plasma 5.24.5, Gnome 42 and Kernels

Thanks. I found the file PKGBUILD in: /var/tmp/pamac-build-rock/libkipi/
I guess where I have rock (in pamac-build-rock), is the user name.

Pamac is prone to freezing or crashing. Now on i always use pacman -Syu for upgrades because it’s reliable.

Well, which GUI client have you used? Are you sure it is Pamac (from Manjaro) and not Discover (from Plasma)? Discover is known to be very broken for system updates on Manjaro at the moment. I have summarized the issues here: Discover system updates still very unreliable.

The update breaks the Timeshift program. New images are no longer reflected after we have created it in the program. After rolling back from updates, everything works fine. There are a lot of conflicts during the upgrade with other packages related to manjaro settings.

Running Manjaro minimal install for RPi4 on RPi3 created on SD card using Manjaro ARM Flasher. Not sure if this update created the problem: Failed to find module ‘pkcs8_key_parser’. Description and fix of removing iwd are in this post:


I wonder if enabling CONFIG_PKCS8_PRIVATE_KEY_PARSER in the kernel would make it work again?

Something must have changed some where. This is the second issue involving iwd lately. CONFIG_PKCS8_PRIVATE_KEY_PARSER has not been enabled in the pi kernels and I happened to have the upstream linux-lts installed on my pi4 and it is not enabled there. I checked arch-arm’s aarch64 kernel and it is not there but they do have it enabled with their rpi kernels.

I am going to make the change that arch-arm has for their rpi kernels. @dbeach when linux-rpi4 is through compiling would you grab the kernel here by clicking the “Download” button when it appears. It will be in a zip archive (artifacts.zip) that needs to be unpacked first before installing. Install the kernel and re-install iwd / reboot and see if it works again. Let us know how it turns out.

New link


Like I said above I made the change like arch-arm has it: CONFIG_PKCS8_PRIVATE_KEY_PARSER=m as the iwd .config file wants to load PKCS8_PRIVATE_KEY_PARSER as a module at boot so I did not want to possibly complicate iwd’s process. The compile should be done in about 12m from this post.


New test kernel packages built and link updated above.

If this works, I’ll do the same for the kernels I maintain.

I have reinstalled iwd via pacman -S iwd and have unpacked artifacts.zip. How do I install? I’m a newbie at this task.

sudo pacman -U *.zst

Fixed! Will report on systemd-networkd-wait-online timeout that can’t be remediated and systemd-oomd.socket Userspace Out-Of-Memory (OOM) Killer Socket error when I have time to do so.

1 Like

CONFIG_PKCS8_PRIVATE_KEY_PARSER=m will be all future rpi kernels.

Several of us here messed with systemd-oomd.socket for several days and never did get it to work on the rpi. You can either ignore the error or disable it trying to load up. You can always revisit trying to get it to load up; something may have changed.


I do not use systemd-networkd but I do know that using 2 different network services at the same time will conflict with each other.

I don’t know if it’s just a coincidence but I’ve been experiencing total lockups of my Pinebook Pro since a few hours after this update. The lockups are total. Everything is frozen on the screen and no keys function, except for the power button. The lockup interval varies, apparently randomly, with several hours of use between lockups being typical but I’ve had a lockup occur within just a few minutes after a power-off reset too.

The “run” LED above the keyboard flashes red after a lockup.

I’m considering going back to linux 5.17.1-4 and pinning it (have to review how to do that again in Manjaro).

Any other ideas or suggestions are appreciated!

P.S. I tried to find clues in the journal but I’ll need to look for smoking guns immediately after rebooting from a lockup next time. I don’t understand most of what I see in a system journal either.

For XFCE, Gnome and minimal spins, both NetworkManager and systemd-networkd are enabled by default. As far as I have seen, only the minimal spin running on a Pi3B has the systemd-networkd-wait-online timeout issue where systemd-networkd-wait-online.service ExecStart parameters such as --any, --timeount, and --interface seem to have no effect.

I maintain XFCE and enabling systemd-networkd is something I do not do. It may be done in the tools if it is done. My xfce image here is a few years old. I do not have systemd-networkd.service enabled. I remember a few years back if NetworkManager.service and systemd-networkd.service were enabled at the same time they fought each other for control of the network.

NetworkManager has it’s own wait-online.service.
Both arch NetworkManager and systemd-networkd wiki’s has a box:

I do not mess with minimal images much and really do not know how it’s network is set up.

My system services (at least the ones showing up in terminal listed alphabetically):

If systemd-networkd is getting enabled on xfce, it’s being done automatically from just having systemd-installed. We don’t explicitly enable it on XFCE edition. We do on minimal edition, because it does not use NetworkManager.

Turns out not to be a systemd-networkd problem for the timeout. I moved the Pi3B from connecting directly to FiOS router to a switch port one hop removed. No more timeout! Another error occurs instead of the systemd-networkd-wait-online timeout, one I can’t recall exactly at this time, but one I’m not going to worry about. (On second thought, it could be a systemd-networkd issue with how hardware signals are interpreted.)

I’m not sure when the uboot-pinebookpro-bsp package got updated, but it completely bricked my Pinebook Pro.

Did you flash it to your emmc manually?
Without that it cannot brick the device.