Confirmed fixed the bug. Thanks!

I was not able to trigger the bug after a half dozen logout/login to the same user. However, I do notice that thee are a lot of geoclue processes that are not cleaned up:

 fedora33# ps -fe | grep sfalco
 sfalco       911       1  0 11:11 ?        00:00:00 /usr/lib/systemd/systemd --user
 sfalco       912     911  0 11:11 ?        00:00:00 (sd-pam)
 sfalco      1130       1  0 11:11 ?        00:00:00 /usr/libexec/geoclue-2.0/demos/agent
 sfalco      1749       1  0 11:12 ?        00:00:00 /usr/libexec/geoclue-2.0/demos/agent
 sfalco      2357       1  0 11:13 ?        00:00:00 /usr/libexec/geoclue-2.0/demos/agent
 sfalco      2966       1  0 11:13 ?        00:00:00 /usr/libexec/geoclue-2.0/demos/agent
 sfalco      3560       1  0 11:14 ?        00:00:00 /usr/libexec/geoclue-2.0/demos/agent
 sfalco      4187       1  0 11:15 ?        00:00:00 /usr/libexec/geoclue-2.0/demos/agent
 sfalco      4794       1  0 11:16 ?        00:00:00 /usr/libexec/geoclue-2.0/demos/agent
 sfalco      5228     911  0 11:17 ?        00:00:00 /usr/bin/dbus-broker-launch --scope user
 sfalco      5229    5228  0 11:17 ?        00:00:00 dbus-broker --log 4 --controller 11 --machine-id 453c53fe1e0e40538136bd60780043d7 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000

I was able to build KiCad for aarch64.

Works fine. Thanks for the rapid fix.

I tried merging bcm283x-firmware-20200306-1.163d84c.fc32.aarch64.rpm into several images:

Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz Fedora-Workstation-32-20200307.n.0.aarch64.raw.xz Fedora-Workstation-32-20200308.n.0.aarch64.raw.xz

In all cases, the dracut shell bug is still present.

Works properly. Thanks!

I tried this build and it fixes #1765939 and #1770478. Thanks!

This update has been unpushed.

I rebuilt kicad with it and it resolved the issue.

Works great. And a very necessary upgrade since so many people have switched to the 2.0 protocol.

This does not need to be pushed to users because there are no functionality changes. However, a spec file change has been committed, to fix future builds.

Kernel 4.18.16-200.fc28.armv7hl fixes a serious Ethernet issue on ARM Wandboards. As such, it is important to make this kernel available as an update to Fedora as quickly as possible.

Restoring the old soname behavior fixes my issue. I am able to install and run the -6 build with no problems. Great job!

Restoring the old soname behavior fixes my issue. I am able to install and run the -6 build with no problems. Great job!

It does not work for me. I ran that exact command. All it did was create:

libbaccats.so -> /etc/alternatives/libbaccats.so

It did not create:

libbaccats-9.0.7.so -> libbaccats.so

I'd like to request that you delete your "libbaccats-9.0.7.so -> libbaccats.so" symlink on your machine. Then run the command and see if "libbaccats-9.0.7.so -> libbaccats.so" is re-created for you.

If alternatives creates "libbaccats-9.0.7.so -> libbaccats.so" for you, then there is something that is keeping it from working properly for me. I'd like to figure out what that is...

I may not be using alternatives correctly. As per the readme, if I do:

alternatives --config libbaccats.so

then I only get:

lrwxrwxrwx   1 root root        31 Jun 11 10:13 libbaccats.so -> /etc/alternatives/libbaccats.so*

What command did you use to create the link:

lrwxrwxrwx. 1 root  13 May 14 09:35 /usr/lib64/libbaccats-9.0.7.so -> libbaccats.so

I see in your 'ls' that your libbaccats-9.0.7.so has a different date from your other files, so I'm wondering how it got created.