[Solved] glibc-Update-fail and broken system when using custom kernel

Question

I had a similar issue with the glibc-update as described in several threads.
I guess, the reason why I ran into the problem was that I'm using a custom-built kernel. So the kernel modules (drivers etc.) under /lib/modules/custom-kernel/ are owned by no pacman package.
At my system, after upgrating via
# pacman -Syu --ignore glibc
# pacman -Su
The upgrade failed and  /lib/modules/ and the files, owned by the glibc-package remained at the still existing directory /lib.
Rebooting the computer in this situation causes a sytem freeze.
Now, here is my sucessful repair, briefly described. Maybe it will help someone:
1. Booting the computer with the Arch Linux net Install image
2. mounting my root partition manually at /mnt
3. performing the following commands:
# cd /mnt
# cp -ar lib/* usr/lib/
# rm -rf lib
# ln -s usr/lib lib
7. removing net install image and rebooting the computer
==> the system works again, but:
# pacman -Su
still produces error messages like:
error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
glibc: /usr/lib/ld-2.16.so exists in filesystem
glibc: /usr/lib/ld-linux.so.2 exists in filesystem
glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem
glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
Now at the last step I did is, what the wiki is seriosly discouraging from I use --force:
# pacman -f -Su
After that my system was repaired
I think using force at that point is OK, because the files will only be replaced which are already moved to the right location.

Answer 1

If you use a custom-built kernel you should really package it up so you can easily avoid this sort of thing just by repackaging.