Need help recovering from glibc upgrade [SOLVED]

Question

I recently did pacman -Syu on a system because I was having trouble with a softphone utility. I installed Arch on this laptop perhaps 6 months ago and have not done many upgrades since that time. Of course I've been waylaid by the recent glibc changes and I'm trying to recover. I think I've gotten a good deal of the way there by researching the issue and attempting a few solutions. But I'm quite confused by what I'm now seeing, so I want to ask for help here.
First, let me point out that I posted in this forum yesterday about certain events that led to my problems--see that thread at https://bbs.archlinux.org/viewtopic.php?pid=1186089. Essentially, I followed the wrong set of instructions and did pacman -Syu --ignore glibc pacman -Su before doing pacman -U http://pkgbuild.com/~allan/glibc-2.16.0 … pkg.tar.xz. That broke pacman, which, being the most current version, was expecting that glibc version to be on the system.
To remedy the problem I followed the procedure outlined in that thread--namely booting from a USB drive on the affected system and running pacman -U http://pkgbuild.com/~allan/glibc-2.16.0 … pkg.tar.xz --root /mnt/brokenRoot. Things kinda started to work then: pacman would run, but I noted that my mouse cursor was not responding. I decided to try and finish the upgrade and so ran pacman -Syu again using the --ignore glibc switch as suggested at https://wiki.archlinux.org/index.php/De … iki:usrlib.
Things started to get really weird after that. For example, at a certain point during the boot process--I believe when the console is getting ready to switch to framebuffer (or whatever point that's called where screen resolution changes from vga)--and the screen just freezes. The laptop won't accept any keyboard or mouse input and just appears to be hung. I was able to chroot in to the system and cause the sshd daemon to start though, and have discovered that I can ssh in and do things.
I upgraded the kernel again today in an ssh session, which gave some quite strange results: mkinitcipio is searching for modules under /lib, whereas as I understand it, /lib is now supposed to contain nothing and is to be simply a symlink to /usr/lib. But I can't build an init image on this system unless a /modules directory is present under /lib. Well, the /lib directory was there, so I symlinked /usr/lib/modules to /lib and mkinitcpio ran fine after that. So what's up here? Why is mkinitcpio expecting the /modules directory to be under /lib?
Just as weird, there seems to be a newer glibc version. But I can't upgrade to it: I get the message "glibc: /lib exists in filesystem." Now, having read https://wiki.archlinux.org/index.php/De … iki:usrlib I know that there are suggestions for remedying this. But when I run the commands suggested there to try and find out what packages own files in /lib, it looks to me that all files there are owned by glibc 2.16.0-1:
find /lib -exec pacman -Qo -- {} +
error: cannot determine ownership of directory '/lib'
/lib/libthread_db.so.1 is owned by glibc 2.16.0-1
/lib/libnss_files-2.16.so is owned by glibc 2.16.0-1
/lib/libc-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nisplus.so.2 is owned by glibc 2.16.0-1
/lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nisplus-2.16.so is owned by glibc 2.16.0-1
/lib/libanl-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl-2.16.so is owned by glibc 2.16.0-1
/lib/libcidn-2.16.so is owned by glibc 2.16.0-1
/lib/librt.so.1 is owned by glibc 2.16.0-1
/lib/libnss_nis.so.2 is owned by glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
/lib/libc.so.6 is owned by glibc 2.16.0-1
/lib/libpthread-2.16.so is owned by glibc 2.16.0-1
/lib/libcrypt.so.1 is owned by glibc 2.16.0-1
/lib/libnss_db.so.2 is owned by glibc 2.16.0-1
/lib/libutil-2.16.so is owned by glibc 2.16.0-1
/lib/libm-2.16.so is owned by glibc 2.16.0-1
/lib/libpthread.so.0 is owned by glibc 2.16.0-1
/lib/libnss_files.so.2 is owned by glibc 2.16.0-1
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.16.0-1
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libSegFault.so is owned by glibc 2.16.0-1
/lib/libnss_nis-2.16.so is owned by glibc 2.16.0-1
error: No package owns /lib/modules
/lib/librt-2.16.so is owned by glibc 2.16.0-1
/lib/libthread_db-1.0.so is owned by glibc 2.16.0-1
/lib/libnss_hesiod-2.16.so is owned by glibc 2.16.0-1
/lib/libdl-2.16.so is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libpcprofile.so is owned by glibc 2.16.0-1
/lib/libnss_compat-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_compat.so.2 is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/libm.so.6 is owned by glibc 2.16.0-1
/lib/libresolv-2.16.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
/lib/libutil.so.1 is owned by glibc 2.16.0-1
/lib/libcrypt-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_hesiod.so.2 is owned by glibc 2.16.0-1
/lib/libdl.so.2 is owned by glibc 2.16.0-1
/lib/ld-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl.so.1 is owned by glibc 2.16.0-1
/lib/libresolv.so.2 is owned by glibc 2.16.0-1
/lib/libnss_dns.so.2 is owned by glibc 2.16.0-1
/lib/libnss_db-2.16.so is owned by glibc 2.16.0-1
Long story short, I'm quite confused by this. And I have a barely-working system I need to fix.
Can anyone please offer input on what might be going on with this system? And perhaps offer suggestions for straightening out the mess?
Thanks,
James
Last edited by jamtat (2012-11-02 23:55:10)

Answer 1

Ok. So I'm officially dumb--in case that wasn't already apparent. I thought I'd tried upgrading glibc after I'd deleted the symlink to /usr/lib/modules (I deleted it a couple of times). But I was apparently wrong: after just now deleting it upon reading your post, I see that the upgrade has worked and that  the system reboots into its former normal state. So. it looks like it's fixed and like this thread can be marked solved. Still I'm curious: will mkinitcpio continue looking for modules in /lib?
Thanks,
James
Last edited by jamtat (2012-11-03 16:22:09)