[Stable Update] 2024-07-01 - Kernels, Systemd, KDE Gear, LibreOffice, Firefox, Wine, Qemu

I wonder if a command that checks for which package “owns” the file might be helpful? I don’t have that index.js file on my system, so just replace /etc/fstab with your files path…

pacman -Qo /etc/fstab                                                                                                                     1 ✘ 
/etc/fstab is owned by filesystem 2024.04.07-1

If that lists a package, it might be interesting to check if you actually use/need it, and minimally temporarily (or permanently) uninstall it while you run the update.

Once a package is identified, it might be interesting to check to see if shows up in a list of orphans pamac list -o or foreign pamac list -m or pacman -Qm packages… this could help you evaluate if you really need the package going forward or not.

For example, I always check for orphans and foreign packages every update. I have a handful of AUR packages I’ve installed, so seeing additional entries in the list of foreign packages tells me that Manjaro dropped a package from their repositories that can now only be found in AUR… and if Manjaro dropped it, and I don’t recall using it, it gets uninstalled.

I traditionally use the pamac-gui to manage my foreign/orphan packages, and also found it good to set it’s advanced preference to Remove unrequired dependencies… I find this helps to keep the orphan list down.

Typically the only orphans I see are the developer/build tools required to build an update to any of my AUR packages. One could leave the build tools around, but they’re generally small and can quickly be re-downloaded when needed, so I usually clean them out too as part of my routine.

One more suggestion for identifying blocking stuff - regardless if installed or uninstalled

read whogotit; sudo pacman -Fyx $whogotit
/usr/lib/node_modules/npm/node_modules/cidr-regex/dist/index.js
[sudo] password for teo: 
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 multilib is up to date
usr/lib/node_modules/npm/node_modules/cidr-regex/dist/index.js is owned by extra/npm 10.8.1-1

So the only package that has this file in the repos is npm and it cannot conflict with anything from there. So to have a conflict or wrong permissions, the user has done someting unsupported - like installing something from aur, or installing with sudo pip or sudo npm (probably the case here - and npm messed the permissions of the system files).

1 Like

This should get you part of the way:

pacman -Qs

I think I have the same problem. Is this only with kernel 5.4 (which I use as well)?

I previously had very bad performance with kernels other than 5.4 and it’s also still LTS.

Make a Timeshift backup so you can easily roll back. Then try installing the latest LTS kernel (currently 6.6) and if you experience issues with it you can try the second latest LTS kernel, third latest, etc (although unrecommended as they would be at version 5.xx but nonetheless newer than your current one).

Another easier workaround for libvirt with ufw combination is to edit /etc/libvirt/network.conf, and add

firewall_backend = "iptables"

See libvirt - ArchWiki

6 Likes

This works indeed.

Ran into aforementioned libvirt/ufw issue. Tried to switch to firewalld with nft backend, but then had issues with Docker networking (apparently still no full support for nftables).
The fix for editing /etc/libvirt/network.conf and setting the firewall_backend = "iptables" got me working again.

1 Like

Ok thanks. I tried kernel 6.1 and updating gives no problems. If I try to boot into kernel 5.4 again fails.

Is the general conclusion that Kernel 5.4 is not usable anymore, or is this just something with my system?

It appears to be an issue for all users since this release. I take it has to do with the massive systemd update.

2 Likes

Thanks this also works for me!