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

[Myra Nelson]

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