DeveloperWiki talk:Usrlib

From ArchWiki
Jump to navigation Jump to search

Note, if you're on a 64 bit system you may need to uncomment the entry for [Multilib] in /etc/pacman.conf --Zenten (talk) 22:46, 14 July 2012 (UTC)

Leftover Directories in /lib/

The example Folder /lib/modules/3.1.9-2-ARCH/modules.* should also get the note, that all folders under /lib/ should be moved or deleted to let glibc update. I had trouble with leftover fglrx module. Moving manually everything solves the problem.

Fix with leftover directories(needs a Live CD)

I copied all files in /lib to /usr/lib and deleted /lib and/or /lib64 then made links to /usr/lib by those names. Be careful when you do this , when you delete /lib the next command you run should not depend on /lib or the linking has to be done before. As soon as you delete /lib the system will not run any command or boot(init needs /lib), I had to use a Live CD to fix this. After you boot through the Live CD, just remove /lib and/or /lib64 make the system links this would restore the system, now you need to update.

pacman -Syu


At the end of the procedure, it says

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.  Then the final "pacman -Su" will successfully install glibc.

The term rebuilding is unclear to me. Reinstall ? Reboot the system ? The command returns glibc on my system --Martvefun (talk) 08:50, 15 July 2012 (UTC)

It will list packages that own files in /lib. If it only lists glibc, you're almost all set to go, all you have to do is check for unowned files and deal with those. thestinger (talk) 12:16, 15 July 2012 (UTC)
option -l to grep will make the output much more readable

Add subsection to deal with common apps

Can we add a subsection to the "Issue 2" section that deals with known apps that need to be uninstalled and then reinstalled?

Specifically in my case (and others), there is UFW that causes this "Issue 2". Of course, it would be wise to put a statement in there that pacman will keep their old ufw configs as ".pacsave" files but that they manually must merge them back after reinstalling UFW.

Twelveeighty (talk) 01:00, 16 July 2012 (UTC)

Rackspace formerly supported Arch 2010.05 and included a kernel module for packaged as Anyone that is running instances from that original image will be affected by Issue 2:

$ find /lib -exec pacman -Qo -- {} +
 error: cannot determine ownership of directory '/lib/modules/'
 error: No package owns /lib/modules/

Solved by following the instructions to move to lib, but these can very likely be deleted.

 pacman -U<arch>.pkg.tar.xz # <arch> = x86_64 | i686
 pacman -Syu --ignore glibc
 cp -r /lib/modules/ /usr/lib/
 rm -rf /lib/modules/
 pacman -Su

--Dalesaurus (talk) 15:11, 17 July 2012 (UTC)

Issue 2

Too many users are unsure about remaining contents in /lib directly. I propose someone adds the following to the issue 2 in the usrlib wiki as another warning:

"Do not delete or move away any files in /lib owned by your current glibc (2.16.0-1 on up-to-date systems) in any case at this point."

--Indigo (talk) 16:42, 15 July 2012 (UTC)

Issue 3

Please change "folder" to "directory" and "folders" to "directories" -- Filesystems don't have folders, they have directories. Diegoviola (talk) 14:28, 16 July 2012 (UTC)

Also, please change that here as well. Diegoviola (talk) 15:14, 16 July 2012 (UTC)

Quick fix

According to falconindy:

As long as you have a root shell open prior to the upgrade, you can fix this quite easily if it explodes: /usr/lib/ /bin/rm -r /lib /usr/lib/ /bin/ln -s usr/lib /lib

You can't do this as a normal user via su or sudo because the setuid bits are no longer significant when executed directly through the linker.