[SOLVED]DeveloperWiki apparently unfinished with glibc

Question

Recently, I ran into a problem upgrading Arch Linux because I ran into the /lib error ("/lib exists"). I read through the Arch Linux news page, and running the commands shown did not work. There is a link to click on if it didn't work. I clicked on it, and that took me to the https://wiki.archlinux.org/index.php/De … iki:usrlib page. I followed every instruction to the letter and discovered that the ONLY package that held any files or ownership or whatever was glibc. The wiki states that for any file "other than glibc", you can simply upgrade the packages after glibc.
Problem is, the ONLY package that had anything in /lib was glibc, and the wiki says nothing about what to do *IF* the only package is glibc. Here's the section I followed quoted below:
Packages that own files in /lib
If after this the "pacman -Su" still has conflicts with /lib, this is likely because a package on your system other than glibc owns files in /lib. Such packages can be detected using:
$ grep '^lib/' /var/lib/pacman/local/*/files
These packages need rebuilding so as not to include the /lib directory. They can also simply be uninstalled and reinstalled again <b>after upgrading glibc</b>. The the final "pacman -Su" will successfully install glibc if there are no untracked files (see the next section).
Unpackaged files
This means that you have files or folders still in /lib or pacman thinks a package apart from glibc still own /lib. You can see which package own files in /lib by using:
$ find /lib -exec pacman -Qo -- {} +
If any package apart from glibc is listed as owning a file, that package needs to be updated to install its files in /usr/lib. Any files unowned by a package should either be deleted or moved to /usr/lib and any directories within /lib need deleted (after they are empty...).
One common source of files in /lib is left overs from running depmod after upgrading the kernel, but prior to reboot. The kernel modules included with the linux package in the repositories are now stored in /usr/lib/modules.
... after upgrading glibc?? If you can't even upgrade glibc because it has files in the /lib, how can it be changed or upgraded if it won't let you? Seeing no instructions on the page that says anything about *if* it is glibc, I opted to try and uninstall it. Yes, it's broken. Fortunately, it was a new installation and trying to fix it (even with chroot and boot CD to repair) failed, only resulting in a permanent kernel panic, I'm reinstalling.
So can someone please give instructions on what to do *IF* the only package that won't install is glibc because of the /lib so that new people learning Arch can also learn to fix it? I can't fix /lib without upgrading glibc, and I can't upgrade glibc without fixing /lib. So what can possibly be done to fix this if it comes up again?
Last edited by 12o (2012-07-30 03:18:02)

Answer 1

Looks like I'm back to this point yet again. After following the developerwiki and moving the 'modules' folder to another location, the only files located in the /lib folder are owned by glibc as the grep program as informed me. The wiki says to simply run:
pacman -Su
and it should work. It doesn't. Still reports that /lib exists when I try to upgrade glibc. But I did happen to notice one file and need to know what to do with it as I don't want to severely hose up my system again. The file is:
/lib/ld-linux.so.2 is owned by lib32-glibc 2.15-10
I have x86_64 installed, but needed the lib32-glibc 2.15-10 installed to run a 32bit program. The wiki does say something about unpackaged files other than glibc, but does that include lib32-glibc? Nothing specifically mentions it, and glibc might as well be glibc.
Do I re-install the lib32-glibc file, and then run pacman -Su? Or do I delete the ld-linux.so.2 file from the /lib folder? I assume re-install the lib32-glibc package as that seems the most logical. I just don't want to screw anything up.
Thanks for the help.
Last edited by 12o (2012-07-30 02:24:57)