[ARM Unstable Update] 2020-12-11 - BREAKAGE EXPECTED - Boost, Python 3.9, KDE-Apps, Gnome, Cinnamon, Systemd, Qemu

Hello ARM community.

This is hhhhuuuuugggggeee! One of the biggest updates to end the year. It might take a while to get it actually stable. So we recommend to switch over to arm-testing branch if you need a working machine!


Some highlights, which partly might break your system:

  • Systemd is now at 247
  • KDE Plasma 5.20.4 got released
  • KDE Apps are now at their December Release
  • Cinnamon is now at 4.8.0
  • Most of the Kernels got updated.
  • Python 3.9 update rolled in. We hope to rebuild all needed packages real soon. If you use AUR packages, we recommend to install rebuild-detector before applying this update.
  • Boost got updated, which need some rebuilds of our packages too
  • KDE-Git packages got updated as usual
  • Gnome got updated to 3.38.2
  • QEmu is at 5.2.0
  • Regular updates by Arch-ARM project

Upstream Notifications:

Older notifications

The nss package requires manual intervention:
Arch Linux - News: nss>=3.51.1-1 and lib32-nss>=3.51.1-1 updates require manual intervention
The packages hplip and firewalld requires manual intervention:
Arch Linux - News: hplip 3.20.3-2 update requires manual intervention
Arch Linux - News: firewalld>=0.8.1-2 update requires manual intervention


Package changes from Fri Dec 11 10:41:49 CET 2020 can be found here.


Testers needed on arm-unstable branch

We are in need of testers for our arm-testing and arm-unstable branches.
So if you are adventurous and want newer software quicker, we would love for you to help us test out the new packages in arm-unstable branch.

All you have to do to switch to this branch is:

  • Edit /etc/pacman-mirrors.conf and change Branch = arm-stable to Branch = arm-unstable.
  • Run this command: sudo pacman-mirrors -f5 && sudo pacman -Syyu. This will generate a new mirrorlist for you, sync your databases with the new mirror and update your system using the arm-unstable branch.

We would then love for you to give feedback in our update posts in #manjaro-arm:arm-unstable-updates. That way we can better find and fix bugs, before they hit arm-stable branch. Thank you!


  • No issue, everything went smoothly
  • Yes there was an issue. I was able to resolve it myself.(Please post your solution)
  • Yes i am currently experiencing an issue due to the update. (Please post about it)

0 voters

1 Like

Broke my wifi. I have the network settings but no device. This was after updating the rpi bootloader update. But restoring previous version does not fix the issue. Still investigating.

Edit: I just went through a wild ride to get may system back up. A crazy set of events that do not add up in my mind. But I am now in sync with arm-unstable and everything seems to be working again. tl;dr ZFS from the AUR was removed from my system.

The cause of the wifi failure was this, but it is not occurring now:

[    4.484369] ------------[ cut here ]------------
[    4.490108] WARNING: CPU: 1 PID: 105 at crypto/rsa-pkcs1pad.c:540 pkcs1pad_verify+0x154/0x180
[    4.499704] Modules linked in: cfg80211(+) rfkill brcmutil zram zsmalloc
[    4.507479] CPU: 1 PID: 105 Comm: systemd-udevd Not tainted 5.10.0-rc7-1-MANJARO-ARM #1
[    4.517004] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[    4.524534] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
[    4.531681] pc : pkcs1pad_verify+0x154/0x180
[    4.537062] lr : public_key_verify_signature+0x204/0x334
[    4.543493] sp : ffff800011c936d0
[    4.547868] x29: ffff800011c936d0 x28: ffff80001146b020 
[    4.554218] x27: 000000001f030000 x26: 000000000000010e 
[    4.560583] x25: ffff0001053fac00 x24: ffff000103f94c00 
[    4.566948] x23: ffff0001053fa200 x22: ffff0001043a5ac0 
[    4.573284] x21: ffff800011c93788 x20: ffff000103faff80 
[    4.579612] x19: ffff0001053fa200 x18: 0000000000000002 
[    4.585944] x17: 0000000000000002 x16: 0000000000000000 
[    4.592268] x15: ffff800010bb28a0 x14: 0000000000000004 
[    4.598738] x13: ffff0001053fabff x12: ffff80001067e8d8 
[    4.605131] x11: 0000000000000007 x10: 0101010101010101 
[    4.611719] x9 : ffff8000105bc834 x8 : 0000000000000100 
[    4.618358] x7 : 0000000000000000 x6 : 0000000000000600 
[    4.624651] x5 : 0000000000000000 x4 : fffffe0003f2bfc0 
[    4.631568] x3 : 000001ffffe00002 x2 : 0000000000000600 
[    4.638431] x1 : 0000000000000000 x0 : 0000000000000000 
[    4.645095] Call trace:
[    4.649525]  pkcs1pad_verify+0x154/0x180
[    4.655267]  public_key_verify_signature+0x204/0x334
[    4.661811]  x509_check_for_self_signed+0xb8/0x13c
[    4.668199]  x509_cert_parse+0x16c/0x1e4
[    4.673659]  x509_key_preparse+0x30/0x1b0
[    4.679436]  asymmetric_key_preparse+0x6c/0xb0
[    4.685464]  key_create_or_update+0x184/0x434
[    4.691186]  regulatory_init+0x194/0x294 [cfg80211]
[    4.697488]  cfg80211_init+0x80/0xe8 [cfg80211]
[    4.703307]  do_one_initcall+0x54/0x2d0
[    4.708424]  do_init_module+0x60/0x29c
[    4.713344]  load_module+0x21e4/0x2820
[    4.718014]  __do_sys_finit_module+0xb8/0xfc
[    4.723187]  __arm64_sys_finit_module+0x2c/0x40
[    4.728556]  el0_svc_common.constprop.0+0x84/0x1f0
[    4.734181]  do_el0_svc+0x30/0xa0
[    4.738331]  el0_svc+0x20/0x30
[    4.742216]  el0_sync_handler+0x1a4/0x1b0
[    4.747052]  el0_sync+0x174/0x180
[    4.751196] ---[ end trace 2d981802ef97f839 ]---
[    4.756845] cfg80211: Problem loading in-kernel X.509 certificate (-22)
[    4.764385] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    4.774067] cfg80211: failed to load regulatory.db

Edit 2: I was able to successfully install ZFS 2.0, previously had the git version installed.

Edit 3: I updated my recovery SD and it went smoothly.

I’ve updated my rpis before reading this post but for now, it’s almost ok…

I still have questions about rebuild-detector (I have Pamac 10.0.0beta-1& Pacman v5.2.2 - libalpm v12.0.2 ) :
When I use checkrebuild I have warnings

warning: config /etc/pacman.conf line 19: unknown option ‘SyncFirst’

Is it due to my configuration or due the tool ?

It listed 3 AUR packages that are out of date because they were compiled with the older python version (3.8) :

foreign python-asttokens
foreign python-wgtools
foreign wgmgr

So, I tried to use, for instance, “pamac reinstall python-asttokens” and I always get the following error:

Error: target not found: python-asttokens-2.0.4-1

I can ask for info “pamac info python-asttokens”

Name : python-asttokens
Version : 2.0.4-1
Description : Annotate AST trees with source code positions
URL : GitHub - gristlabs/asttokens: Annotate Python AST trees with source text and token information
Licenses : Apache 2.0
Repository : AUR
Installed Size : 104.7 kB
Depends On : python python-six
Make Dependencies : python-setuptools
Packager : Unknown Packager
Maintainer : WhyNotHugo
First Submitted : 11/08/17
Last Modified : 12/03/20
Votes : 4
Build Date : 12/03/20
Install Date : 12/03/20
Install Reason : Explicitly installed

I don’t understand what I did wrong.

All help will be welcome

With AUR packages you should use pamac build instead, so:
pamac build python-asttokens

The reason pamac info gives info, is because you have the package installed.

1 Like

I noticed that my Plasma desktop is no longer “accelerated” (meaning Kwin crashes, disabling OpenGL stuff) on my Pinebook Pro after the update to mesa 20.3. It used to be.

I found this MR on the Mesa gitlab, which looks like it could be related.
If it is, it will be fixed when Mesa 20.3.1 releases on the 16th.

2 Likes

The PAMAC wiki page is definitely too old ! https://wiki.manjaro.org/index.php/Pamac
@Strit with your help, I was able to reinstall/rebuild all my old python3.8 packages.

kinda switched over to unstable, but hit a snag, fixed it then hit a road block, then it just fell off a cliff.
Note 1) Pinephone screen too small for window layout I recommend for small screen users to use nano to edit $sudo nano /etc/pacman-mirros.conf (I think this is fixed in later beta versions)

note 2) sudo pacman-mirrors -f5 && sudo pacman -Syyu
seemed to go ok, but … the snag… kept getting “unable to lock database”, so per a different thread.
visone

Hi!
You need to delete de db file and regenerate again

sudo rm /var/lib/pacman/db.lck
sudo pacman -Syyu

note 3) back on track packages were downloading then it could not update geary, nothing updated and sent back to terminal prompt. I don’t have more details on this because… cat trying to eat icecream, got icecream away from cat… Pinephone locked screen, and now lock screen password not working. Tried the startup 123456 didn’t work.

So … I just plan on downloading the latest unstable beta version and reloading with that.
Beta3 (2020-12-11) Download

Humm… something is going on. can’t boot any image of Manjaro. the Jumpdrive works great, so I have access to the emmC. I flashed images successfully before, but now i have tried several different images and nothing will boot Manjaro. It loads the Logo, with the spinner below, goes a few cycles, and hangs. What do i need to change in the boot script to not boot silent, but watch what is getting loaded?

8GB & 4GB RPi4 updated to arm-unstable booting on SD and NFS.

I do not know when it began, the issue likely predates my first use of the net HOOK.
But if the hook is activated in your mkinitcpio.conf, the wifi driver crashes and you end up with no wifi device. The net hook is required for booting via NFS.

Dec 14 18:20:36 client kernel: ------------[ cut here ]------------
Dec 14 18:20:36 client kernel: WARNING: CPU: 0 PID: 123 at crypto/rsa-pkcs1pad.c:540 pkcs1pad_verify+0x154/0x180
Dec 14 18:20:36 client kernel: Modules linked in: cfg80211(+) rfkill brcmutil overlay zram zsmalloc
Dec 14 18:20:36 client kernel: CPU: 0 PID: 123 Comm: systemd-udevd Not tainted 5.10.0-rc7-1-MANJARO-ARM #1
Dec 14 18:20:36 client kernel: Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
Dec 14 18:20:36 client kernel: pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
Dec 14 18:20:36 client kernel: pc : pkcs1pad_verify+0x154/0x180
Dec 14 18:20:36 client kernel: lr : public_key_verify_signature+0x204/0x334
Dec 14 18:20:36 client kernel: sp : ffff800011d9b6d0
Dec 14 18:20:36 client kernel: x29: ffff800011d9b6d0 x28: ffff80001146b020 
Dec 14 18:20:36 client kernel: x27: 000000001f030000 x26: 000000000000010e 
Dec 14 18:20:36 client kernel: x25: ffff0001045ff800 x24: ffff000103c90d00 
Dec 14 18:20:36 client kernel: x23: ffff0001045ff000 x22: ffff000103e6dac0 
Dec 14 18:20:36 client kernel: x21: ffff800011d9b788 x20: ffff000100890480 
Dec 14 18:20:36 client kernel: x19: ffff0001045ff000 x18: 0000000000000002 
Dec 14 18:20:36 client kernel: x17: 0000000000000007 x16: 0000000000000000 
Dec 14 18:20:36 client kernel: x15: ffff800010bb28a0 x14: 0000000000000004 
Dec 14 18:20:36 client kernel: x13: ffff0001045ff7ff x12: ffff80001067e8d8 
Dec 14 18:20:36 client kernel: x11: 0000000000000007 x10: 0101010101010101 
Dec 14 18:20:36 client kernel: x9 : ffff8000105bc834 x8 : 0000000000000100 
Dec 14 18:20:36 client kernel: x7 : 0000000000000000 x6 : 0000000000000600 
Dec 14 18:20:36 client kernel: x5 : 0000000000000000 x4 : fffffe0003ef2400 
Dec 14 18:20:36 client kernel: x3 : 000001ffffe00002 x2 : 0000000000000600 
Dec 14 18:20:36 client kernel: x1 : 0000000000000000 x0 : 0000000000000000 
Dec 14 18:20:36 client kernel: Call trace:
Dec 14 18:20:36 client kernel:  pkcs1pad_verify+0x154/0x180
Dec 14 18:20:36 client kernel:  public_key_verify_signature+0x204/0x334
Dec 14 18:20:36 client kernel:  x509_check_for_self_signed+0xb8/0x13c
Dec 14 18:20:36 client kernel:  x509_cert_parse+0x16c/0x1e4
Dec 14 18:20:36 client kernel:  x509_key_preparse+0x30/0x1b0
Dec 14 18:20:36 client kernel:  asymmetric_key_preparse+0x6c/0xb0
Dec 14 18:20:36 client kernel:  key_create_or_update+0x184/0x434
Dec 14 18:20:36 client kernel:  regulatory_init+0x194/0x294 [cfg80211]
Dec 14 18:20:36 client kernel:  cfg80211_init+0x80/0xe8 [cfg80211]
Dec 14 18:20:36 client kernel:  do_one_initcall+0x54/0x2d0
Dec 14 18:20:36 client kernel:  do_init_module+0x60/0x29c
Dec 14 18:20:36 client kernel:  load_module+0x21e4/0x2820
Dec 14 18:20:36 client kernel:  __do_sys_finit_module+0xb8/0xfc
Dec 14 18:20:36 client kernel:  __arm64_sys_finit_module+0x2c/0x40
Dec 14 18:20:36 client kernel:  el0_svc_common.constprop.0+0x84/0x1f0
Dec 14 18:20:36 client kernel:  do_el0_svc+0x30/0xa0
Dec 14 18:20:36 client kernel:  el0_svc+0x20/0x30
Dec 14 18:20:36 client kernel:  el0_sync_handler+0x1a4/0x1b0
Dec 14 18:20:36 client kernel:  el0_sync+0x174/0x180
Dec 14 18:20:36 client kernel: ---[ end trace 0f472a12ddda9418 ]---

I moved your post from the x86_64 thread to the ARM thread. :wink:

1 Like

Well, after hunting this down, it turns out the dump is not what breaks wifi. The dump is caused by the kernel attempting to load the regulatory.db but it is not loading the required /usr/lib/crda/pubkeys/sforshee.key.pub.pem. The kernel config sets CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y which requires validating but .pem is not used. I think libnl should validate, I do not know enough on this topic.
Will this prevent nfsroot over wifi? Maybe, untested.

But this is not the cause of the missing wifi devices, and so what is? I am not exactly sure. But the good news is I know a “fix”. It seems adding net to HOOKS causes the need for:

FILES=(/usr/lib/firmware/updates/brcm/brcmfmac43455*)

But now I can nfsboot on wired without breaking wifi.

Edit: Adding another group of files cleans up another boot error but it does not seem to effect anything. I believe user space applies the required configurations.

FILES=(/usr/lib/firmware/updates/brcm/brcmfmac43455* /usr/lib/firmware/brcm/brcmfmac43455*")

Actually it is /usr/lib/firmware/regulatory.db.p7s but this will not happen unless you have crda and wireless-regdb installed.

https://github.com/torvalds/linux/commit/90a53e4432b12288316efaa5f308adafb8d304b0

I messed with this a for a while. I loaded both the regulatory dbs and several other things into the initramfs. I could get the kernel to load the database but it failed to validate it. So I never cleared up the dumps. It could be that I am still missing something else on the initramfs but I don’t see any clues as to what that could be.

Here is the stuff that I tried:

MODULES=(cfg80211 rfkill brcmfmac brcmutil i2c_brcmstb crypto_user)
BINARIES=(/usr/bin/crda /usr/lib/crda/regulatory.bin /usr/lib/firmware/regulatory.db /usr/lib/firmware/regulatory.db.p7s)

I just noticed that I put the databases as binaries, probably should have been as FILES but I don’t think it mattered, as they were placed in the initramfs.

FILES=(/usr/lib/udev/rules.d/85-regulatory.rules /usr/lib/crda/pubkeys/sforshee.key.pub.pem  /usr/lib/firmware/brcm/* /usr/lib/firmware/updates/brcm/* /usr/lib/firmware/raspberrypi/bootloader/stable/*)

Edit: It feels like maybe a crypto module or something is missing. The dump is harsh for simple failed to validate which should be handled more gracefully anyway. But it could be other things too, like the RPi4 firmware. I don’t have a deep enough understanding.

I was under the impression this was required now. Is it optional? I would hate to run afoul of the US Government. :wink:

Hmm, in looking at the commit, this is the error I received:

loaded regulatory.db is malformed or signature is missing/invalid

Which would mean the country is not being set. I messed around with that too some. Maybe I need to take another shot at this.

Eh, still no dice. This is like the systemd + nfsroot issue… something that should work, does not. It bugs me, but I’ll survive. :slight_smile:

Next odd issue:
After a fresh install and subsequent update to unstable. On the second reboot my RPi4 experienced a wifi issue which the effect would hang the desktop and very high cpu utilization but nothing of note when running top.
I think the issue is /usr/lib/systemd/system/NetworkManager.service.d/NetworkManager-ovs.conf which has the following:

[Unit]
After=openvswitch.service

I do not have openvswitch installed, so no systemd service. So I changed it to:

[Unit]
#After=openvswitch.service

Then rebooted and wifi reappeared and worked properly.
I got the hint from checking the status of NetworkManager and noticed failed ovs.

Edit: My daily driver which is also on arm-unstable, also without openvswitch, does not have the problem with the setting above.

So I am not sure, maybe a timing issue? The two with the issue are on SD while this one is on SSD.

Not sure this is worth a thread:

(3/4) upgrading graphviz                           [##################] 100%
Warning: Could not load "/usr/lib/graphviz/libgvplugin_gdk.so.6" - It was found, so perhaps one of its dependents was not.  Try ldd.
Warning: Could not load "/usr/lib/graphviz/libgvplugin_gtk.so.6" - It was found, so perhaps one of its dependents was not.  Try ldd.
Warning: Could not load "/usr/lib/graphviz/libgvplugin_gdk.so.6" - It was found, so perhaps one of its dependents was not.  Try ldd.
Warning: Could not load "/usr/lib/graphviz/libgvplugin_gtk.so.6" - It was found, so perhaps one of its dependents was not.  Try ldd.

$ ldd /usr/lib/graphviz/libgvplugin_gdk.so.6

libgdk-x11-2.0.so.0 => not found

I guess it needs a dependency added. Installing gtk2 appears to resolve the issue.

Edit: And then I work through my orphan packages and graphviz is removed, so I removed gtk2.

A post was split to a new topic: Arm device update issue