Re: [arch-general] [arch-dev-public] heads up: /lib removal
So... this upgrade has been more fun than expected. At the moment there appears to a "limitation" in pacman so I would recommend updating like:
Step 0) open a root shell - this can be used to recover if anything goes wrong
Step 1) run: pacman -Qo /lib/* Deal with (either via updating from the repo or rebuilding) anything not owned by glibc
Step 2) run: find /var/lib/pacman/local -name files | xargs grep "^lib/$" This should only return glibc. If not, rebuild those packages not to own the /lib directory
Step 3) pacman -Syu
If something goes wrong (you will see a message like "call to execv failed"), use your root shell to do: /usr/lib/ld-2.16.so /bin/rm -r /lib /usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib
Note that all this should have been unnecessary and the instructions given by falconindy should have been enough. But there appears to be a genuine pacman bug in conflict checking where it ignores other packages owning a directory when it checks if it can be removed. Hopefully this can be fixed soon... There may be something else going on with here too, but we are unsure as of yet.
Note that pacman will detect when there are files in /lib that do not belong to glibc before upgrade, just not if some other package owns /lib only (with no files). So all the cases I tested (folder and files in /lib, both owned and unowned by packages) do not result in the error.
Allan
From the pacman -Qo /lib/* command I discovered a module directory with some left over kernels modules. I checked /usr/lib/modules and had the modules for my current kernels so I did the stupid thing and sudo rm -Rvf /lib/modules. Don't jump yet, because Allan's procedure worked perfectly after that.
Actually for such a massive upgrade I think things went well. Myra -- Life's fun when your sick and psychotic!
participants (1)
-
Myra Nelson