From ArchWiki
Revision as of 23:26, 30 October 2013 by Calimero (talk | contribs) (Add subsection to deal with common apps: 403 on; add fallback link)
Jump to: navigation, search

Safety precaution

Before making any manual changes to directories, or files pertaining to a critical library like glibc, take note of the following:

Install busybox

Install busybox, which is a statically linked executable that can provide basic command line functionality without using shared libraries.

pacman -S busybox

This will install busybox (by default) to /bin/busybox. This way, in case an error is made and libraries can't be found by the system (for example when doing ls, cp, mv, etc...), you can fall back to using busybox directly like this:

/bin/busybox ls

mv, not rm

If you are considering deleting critical directories, move them to a temporary location such as /root/, rather than deleting them. That way, if something goes wrong, you can move them back, perhaps using busybox if necessary. You can always delete after you confirm that the operation was successful.


In many cases, if the output of grep '^lib' /var/lib/pacman/local/*/files looks like this, there may be leftover files/directories in /lib/modules from old kernels.

What I personally did (which fixed the issue) was delete /lib/modules via rm -rf /lib/modules and then a pacman -S linux to reinstall the kernel. However, some people would find that risky, so consider manually deleting old directories in /lib/modules left by old kernels. (Also, see below)

Leftover Directories in /lib/

The example directory /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.


grep '^lib/' /var/lib/pacman/local/*/files does not find /lib/modules/ as it is not owned by any package. pacman -Qo /lib/* does find it. As we see, the files that are left in this folder is for old kernels, and should thus be safe to delete - as long as a new kernel is used.

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

Link is broken; the package can still be found here:

--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)

I think this is pretty clear now. I don't think the people who are removing /lib or files owned by glibc bothered to read this page. thestinger (talk) 13:24, 30 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)

Issue 4

On a fresh installation an attempt to
 pacman -U<arch>.pkg.tar.xz
fails with:
error: failed to commit transaction (conflicting files)
glibc: /usr/bin/tzselect exists in filesystem
glibc: /usr/sbin/zdump exists in filesystem
glibc: /usr/sbin/zic exists in filesystem ? -- Karol (talk) 03:57, 22 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.

Unclear which folder to remove in /lib related to /lib/modules

As for the modules-directory in /lib it should be clearer that you should remove /lib/modules, and not just /lib/<kernel_version>-ARCH.

Some people may have modules left in there that they need (possibly from AUR packages), so suggesting to remove that is going to lead to issues. There aren't really copy-and-paste instructions we can give for this that are safe, people know their own systems and which stuff they've installed that they're going to need to reinstall after the upgrade (or even move to /lib manually). The page does say that all files/directories in /lib not owned by glibc (no directories can be owned, so maybe it needs to be clear that none should be left) have to be gone for the upgrade to continue. thestinger (talk) 18:45, 22 July 2012 (UTC)


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)

That's just a problem in and of itself, you should be aware of all local packages (not from the repositories) on your system (pacman -Qm), which would apply for the really old lib32 packages before there was a multilib repository. The command that lists files owned by packages in /lib will list out whatever problem packages exist related to this upgrade already. thestinger (talk) 13:22, 30 July 2012 (UTC)

Online fix if --force was used when installing glibc with /usr/lib -> /lib symlink

[root@d-box /]# /usr/lib/ /bin/mv /lib /old_lib

[root@d-box /]# /usr/lib/ /bin/ln -s /usr/lib /lib

[root@d-box /]# LD_LIBRARY_PATH=/old_lib /usr/lib/ /usr/bin/pacman -S glibc

(but if 32bit replace /usr/lib/ with /usr/lib/

Rackspace Cloud users

This issue has already been forwarded to the engineering and development team and they are already aware of the issue. Ultimately they will deploy a newer Arch image with these updates already applied, however that is still in the works. In the meantime, here is a work around for getting the current image completely up to date:

# Ignoring glibc and filesystem for now since they require some special treatment.
pacman -Syu --ignore glibc --ignore filesystem
# The netcfg update deprecates the way how our provisioning sets networking configuration. This is the fix.
sed -i 's/NETWORKS=(last)/NETWORKS=(eth0 eth1)/' /etc/conf.d/netcfg
# The version of xe-guest-utilities from the image has kernel26-xen as a dependency. Removing and reinstalling with a more current build.
pacman -R xe-guest-utilities kernel26-xen
pacman -S patch
tar xzvf xe-guest-utilities.tar.gz
cd xe-guest-utilities
makepkg -s --asroot
pacman -U xe-guest-utilities-6.0.2-1-x86_64.pkg.tar.xz
pacman -S filesystem --force
mv /var/run/* /run
unlink /var/run/daemons/daemons
rm -rf /var/run
ln -s /run /var/run
pacman -S glibc
# This should show that everything is up to date.
pacman -Syu


why is this changing the way how var/run is relatively linked, what is the reason for the stuff between pacman -S filesystem --force and pacman -S glibc gtmanfred (talk) 22:27, 1 August 2012 (UTC)
RackSpace Cloud has upgraded their image, therefore rendering this issue fixed. Zachera (talk) 06:27, 8 January 2013 (UTC)