[arch-general] [arch-dev-public] heads up: /lib removal

Myra Nelson myra.nelson at hughes.net
Sun Jul 8 00:46:40 EDT 2012

> 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.


Life's fun when your sick and psychotic!

More information about the arch-general mailing list