Difference between revisions of "DeveloperWiki:usrlib"
m (Protected "DeveloperWiki:usrlib" ([edit=sysop] (indefinite) [move=sysop] (indefinite))) |
(→Issue 2: The final "pacman -Su" still has conflicts in /lib) |
||
Line 50: | Line 50: | ||
find /lib -exec pacman -Qo -- '{}' \+ | 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 be moved to /usr/lib and any directories within /lib need deleted (after they are empty...). | + | 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 on a kernel update. For example: | ||
+ | |||
+ | error: No package owns /lib/modules/3.1.9-2-ARCH/modules.* | ||
+ | |||
+ | If no other files are in /lib/modules, you can safely remove that directory. | ||
+ | |||
If after this the "pacman -Su" still has conflicts with /lib, this is because a package on your system other than glibc thinks it owns the /lib folder. Such packages can be detected using: | If after this the "pacman -Su" still has conflicts with /lib, this is because a package on your system other than glibc thinks it owns the /lib folder. Such packages can be detected using: |
Revision as of 15:06, 14 July 2012
All files in the /lib directory have been moved to /usr/lib and now /lib is a symlink to usr/lib.
During this update, pacman will identify a conflict in the /lib directory with the message:
error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded.
Firstly... DO NOT USE --force! This will seriously break your system. If you are coming to this guide too late and you have already used --force... there are ways to fix your system. These two do not even require a rescue disk.
In the simplest case, the update can be performed by doing:
pacman -Syu --ignore glibc pacman -Su
There are two possible issues that might occur during this update.
Issue 1: glibc dependency errors
If running "pacman -Syu --ignore glibc" gives:
warning: ignoring package glibc-2.16.0-2 warning: cannot resolve "glibc>=2.16", a dependency of "gcc-libs" ... :: The following packages cannot be upgraded due to unresolvable dependencies: binutils gcc gcc-libs Do you want to skip the above packages for this upgrade [y/N]
Say "y" to skipping the packages, then install them using:
pacman -Sd binutils gcc gcc-libs
Note the use of a single "-d" only ignores the versioning of dependencies and not the actual dependency itself. Then finish the update using:
pacman -Su
Issue 2: The final "pacman -Su" still has conflicts in /lib
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 on a kernel update. For example:
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.*
If no other files are in /lib/modules, you can safely remove that directory.
If after this the "pacman -Su" still has conflicts with /lib, this is because a package on your system other than glibc thinks it owns the /lib folder. Such packages can be detected using:
grep -R --include files "^lib/" /var/lib/pacman/local/
These packages need rebuilding so as not to include the /lib directory. Then the final "pacman -Su" will successfully install glibc.
You can confirm the update is complete by looking in your root directory to see that lib is a symlink to usr/lib.
> ls -ld /lib lrwxrwxrwx 1 root root 7 Jul 11 21:10 lib -> usr/lib