[SOLVED] glibc upgrade problem (moved /lib myself)

Question

Hi,
  I went to upgrade my Archlinux system,
  and had to apply both the June and July intervention upgrades described in the announcements.
  Neither of the sets of instructions worked on their own,
  and before I thought of how to combine them properly,
  I tried moving the files from /lib to /usr/lib and making /lib a symlink (to usr/lib),
  so that maybe I could skip the July intervention instructions.
  I didn't break my system (for long), I successfully moved the stuff over,
  and then I ran 
pacman -Syu --ignore glibc --ignore filesystem
pacman -S filesystem --force
  and then the upgrade was mostly done.
  But then upgrading to glibc still doesn't work.
  From pacman -Su,
  I get the output
error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem
glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
glibc: /usr/lib/libSegFault.so exists in filesystem
glibc: /usr/lib/libanl.so.1 exists in filesystem
glibc: /usr/lib/libc.so.6 exists in filesystem
glibc: /usr/lib/libcidn.so.1 exists in filesystem
glibc: /usr/lib/libcrypt.so.1 exists in filesystem
glibc: /usr/lib/libdl.so.2 exists in filesystem
glibc: /usr/lib/libm.so.6 exists in filesystem
glibc: /usr/lib/libmemusage.so exists in filesystem
glibc: /usr/lib/libnsl.so.1 exists in filesystem
glibc: /usr/lib/libnss_compat.so.2 exists in filesystem
glibc: /usr/lib/libnss_db.so.2 exists in filesystem
glibc: /usr/lib/libnss_dns.so.2 exists in filesystem
glibc: /usr/lib/libnss_files.so.2 exists in filesystem
glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem
glibc: /usr/lib/libnss_nis.so.2 exists in filesystem
glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem
glibc: /usr/lib/libpcprofile.so exists in filesystem
glibc: /usr/lib/libpthread.so.0 exists in filesystem
glibc: /usr/lib/libresolv.so.2 exists in filesystem
glibc: /usr/lib/librt.so.1 exists in filesystem
glibc: /usr/lib/libthread_db-1.0.so exists in filesystem
glibc: /usr/lib/libthread_db.so.1 exists in filesystem
glibc: /usr/lib/libutil.so.1 exists in filesystem
  Running
grep '^lib/' /var/lib/pacman/local/*/files
  returns
/var/lib/pacman/local/gcc-multilib-4.7.0-6/files:lib/
/var/lib/pacman/local/gcc-multilib-4.7.0-6/files:lib/cpp
/var/lib/pacman/local/glibc-2.15-10/files:lib/
/var/lib/pacman/local/glibc-2.15-10/files:lib/ld-2.15.so
/var/lib/pacman/local/glibc-2.15-10/files:lib/ld-linux-x86-64.so.2
/var/lib/pacman/local/glibc-2.15-10/files:lib/libBrokenLocale-2.15.so
/var/lib/pacman/local/glibc-2.15-10/files:lib/libutil.so.1
/var/lib/pacman/local/lib32-glibc-2.15-10/files:lib/
/var/lib/pacman/local/lib32-glibc-2.15-10/files:lib/ld-linux.so.2
  Running
find /lib -exec pacman -Qo -- {} +
  returns
error: No package owns /lib
  So it seems that there was more to be done than just moving the lib files and making the symlink...
  I'm sorry that I went against the instructions,
  but I had to deviate in some way to do this upgrade.
  I just probably deviated in the wrong direction.
  Does anyone know how I can finish upgrading my system?
  I can think of things to try, but I don't want to be wrong and make it worse.
Deschutron
Last edited by Deschutron (2012-07-26 12:06:04)

Answer 1

If not, you should be okay forcing the glibc update at this point.
I did.
It worked.
My system is saved.
Thank you very much.
What follows is information about what I did since your post, in case it helps anyone else.
Are you sure that you've updated all the file locations for glibc?
No. I don't understand the structure of pacman well enough to know that there isn't another set of files I have to edit.
I had gcc-multilib and glibc complaining when I tried pacman -Su
I did see a thread where someone said that uninstalling everything that complains, except for glibc, allows glibc to upgrade.
I tried to run pacman -R gcc-multilib, but a package complained that it needed gcc, as if gcc and gcc-multilib are the same thing.
I gave up on that lead there.
After the advice here,
I tried figuring out what --force does.
man pacman said that it does "Bypass file conflict checks and overwrite conflicting files."
Then I tried finding out what conflict checks get done.
I looked at the pacman source code and learnt nothing useful.
Then I looked inside the package archive for glibc. (/var/cache/pacman/pkg/glibc-2.16.0-2-x86_64.pkg.tar.xz)
Inside, it was in the structure of a root file system, with presumably the set of files it would try to copy into my system.
I saw that all the files getting complained about were symlinks in both the archive and my system.
I couldn't just delete them all off my system because /lib was one of them.
I looked at the other files in the archive, and there was only one file I was afraid of it overwriting - locale.gen,
so I backed up locale.gen, and did
pacman --force -S glibc
That ran without complaints.
Then I ran
pacman -Su
That ran without complaints and upgraded about 5 things.
Then I rebooted, and I could succesfully start X and visit this webpage.
Also, I installed my system in early June. That's why I didn't try the "for installs that have not been updated during 2012" package.
I didn't know why that was there, so I didn't know that it would apply to me.
Or if the way the wiki article did apply to my exact situation is something else, then I still haven't found it.