glibc update refusing to proceed. File ownership problem

fnord0 · 2012-07-15 15:47:03

just wanted to mention that I ran into the error "error: cannot determine ownership of directory '/lib'" and tried everything suggested here and in the DeveloperWiki:usrlib page with nothing actually resolving the issue (I just kept seeing the same error over and over). what saved my a$$ was this post from /r/ArchLinux ;;

If you're reading this and are now afraid to update consider installing busybox and opening yourself a busybox root shell with "sudo busybox sh"
Then you can happily break /lib and still have a working shell to fix things from.

once I installed busybox + dropped into a root busybox shell, I renamed the '/lib' folder to '/lib-bak', and manually created the '/lib' symlink myself

cd /
ln -s usr/lib /lib

then FORCED the install of glibc, and moved my old '/lib-bak/modules' directory over to '/usr/lib' dir. BOOM, problem solved. yes, I am fully aware it is highly frowned upon, and in several places suggested not to do it, but NOTHING else I did worked. sometimes ya gotta bend the rules

I highly suggest others not to follow my steps, yet all I can say is it worked for me. everyone's best bet would be to try what Zamboniman posted, and go from there...

/fnord0

Last edited by fnord0 (2012-07-15 17:19:00)

UnsolvedCypher · 2012-07-15 15:49:37

After trying to update, pacman ran into an error, so I read the news. I followed the instructions under the /lib symbolic link post, but after the final pacman -Su, I ended up with a

error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem

So I tried

$ find /lib -exec pacman -Qo -- {} +

which gave me

find /lib -exec pacman -Qo -- {} +
error: cannot determine ownership of directory '/lib'
/lib/libnss_dns-2.15.so is owned by glibc 2.15-12
/lib/libnss_dns.so.2 is owned by glibc 2.15-12
/lib/libnsl.so.1 is owned by glibc 2.15-12
/lib/libthread_db-1.0.so is owned by glibc 2.15-12
/lib/libutil-2.15.so is owned by glibc 2.15-12
/lib/libBrokenLocale.so.1 is owned by glibc 2.15-12
/lib/libcrypt.so.1 is owned by glibc 2.15-12
/lib/libnss_nis-2.15.so is owned by glibc 2.15-12
/lib/libpthread.so.0 is owned by glibc 2.15-12
/lib/libcidn-2.15.so is owned by glibc 2.15-12
/lib/libresolv-2.15.so is owned by glibc 2.15-12
/lib/libnss_compat-2.15.so is owned by glibc 2.15-12
/lib/libm-2.15.so is owned by glibc 2.15-12
/lib/libnss_nis.so.2 is owned by glibc 2.15-12
/lib/libc.so.6 is owned by glibc 2.15-12
/lib/libnss_hesiod.so.2 is owned by glibc 2.15-12
/lib/libmemusage.so is owned by glibc 2.15-12
/lib/librt.so.1 is owned by glibc 2.15-12
/lib/libnss_nisplus.so.2 is owned by glibc 2.15-12
/lib/librt-2.15.so is owned by glibc 2.15-12
/lib/libnss_compat.so.2 is owned by glibc 2.15-12
/lib/libBrokenLocale-2.15.so is owned by glibc 2.15-12
error: cannot determine ownership of directory '/lib/modules'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH/kernel'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH/kernel/drivers'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH/kernel/drivers/net'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH/kernel/drivers/net/wireless'
error: No package owns /lib/modules/3.3.7-1-ARCH/kernel/drivers/net/wireless/rt3572sta.ko.gz
/lib/libdl.so.2 is owned by glibc 2.15-12
/lib/libpthread-2.15.so is owned by glibc 2.15-12
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.15-12
/lib/libnss_db-2.15.so is owned by glibc 2.15-12
/lib/libcidn.so.1 is owned by glibc 2.15-12
/lib/libcrypt-2.15.so is owned by glibc 2.15-12
/lib/libSegFault.so is owned by glibc 2.15-12
/lib/libthread_db.so.1 is owned by glibc 2.15-12
/lib/libnss_nisplus-2.15.so is owned by glibc 2.15-12
/lib/libpcprofile.so is owned by glibc 2.15-12
/lib/libc-2.15.so is owned by glibc 2.15-12
/lib/libnss_db.so.2 is owned by glibc 2.15-12
/lib/ld-2.15.so is owned by glibc 2.15-12
/lib/libdl-2.15.so is owned by glibc 2.15-12
/lib/libnss_files.so.2 is owned by glibc 2.15-12
/lib/libanl.so.1 is owned by glibc 2.15-12
/lib/libutil.so.1 is owned by glibc 2.15-12
/lib/libnss_files-2.15.so is owned by glibc 2.15-12
/lib/libnsl-2.15.so is owned by glibc 2.15-12
/lib/libm.so.6 is owned by glibc 2.15-12
/lib/libnss_hesiod-2.15.so is owned by glibc 2.15-12
/lib/libresolv.so.2 is owned by glibc 2.15-12
/lib/libanl-2.15.so is owned by glibc 2.15-12

I'm not really sure what to do at this point, so if anyone could help it would be great. Thanks!

popso · 2012-07-15 15:55:46

according to this https://wiki.archlinux.org/index.php/De … iki:usrlib, you can do :

rm -r /lib/modules/
pacman -S glibc

triumphguy · 2012-07-15 15:56:19

Backup the modules directory to home or somewhere else, then delete the /lib/modules directory. Run pacman -Su again and it should work.

fsckd · 2012-07-15 15:58:56

merged UnsolvedCypher's thread, original title "/lib issue"

bennyh · 2012-07-15 15:59:41

pacman -Syu --ignore glibc 
rm -rf /lib/modules
pacman -Syu

worked like a charm for me. I also had to reinstall catalyst and my kernels.

Last edited by bennyh (2012-07-15 16:00:03)

twelveeighty · 2012-07-15 16:18:17

swanson wrote:

I had some garbage there too, udev-compat and some leftover files from an UFW installation.
<..>
This was by far the most complicated update I've come across in Arch and I think much patience is needed.

That last statement is certainly true for me as well - Would it make sense to add another section to that Wiki article https://wiki.archlinux.org/index.php/De … iki:usrlib for "common" remaining problems such as UFW? I had to spent some time and digging around to get that one resolved, only to find a casual remark on "remove and reinstall ufw". I wasn't allowed to add it there myself - the page is locked for editing.

Potomac · 2012-07-15 17:41:08

bennyh wrote:

pacman -Syu --ignore glibc 
rm -rf /lib/modules
pacman -Syu
worked like a charm for me. I also had to reinstall catalyst and my kernels.

the key for success here is to move ( or delete ) the /lib/modules folder,

I have lost too much time before understanding this fact,

but it's sad that the wiki article is not clear about this step, most of the problems that people have here come from the fact that they have files in /lib/modules ( old kernel versions ), that's why the glibc update fails

I suggest someone to upgrade the wiki article in order to be much usefull and understandable

if you see this after the "find" and "grep" commands :

error: cannot determine ownership of directory '/lib/modules'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH/kernel'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH/kernel/drivers'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH/kernel/drivers/net'
error: cannot determine ownership of directory '/lib/modules/3.3.7-1-ARCH/kernel/drivers/net/wireless'

that means you must move or delete the /lib/modules folder

Last edited by Potomac (2012-07-15 17:52:21)

tancrackers · 2012-07-15 19:49:53

Is there a way to sticky or specially mark post #39? IMO it appears to be the most helpful solution.

jasonwryan · 2012-07-15 19:54:39

tancrackers wrote:

Is there a way to sticky or specially mark post #39? IMO it appears to be the most helpful solution.

It is already on the wiki here: https://wiki.archlinux.org/index.php/De … iki:usrlib

nomorewindows · 2012-07-15 20:08:51

shaurz wrote:

If anyone else had the boot problem where it times out looking for the root fs, this is how I fixed it.
Boot a Live CD/USB image, chroot:
mount /dev/sda3 /mnt
mount -o bind /dev /mnt/dev
mount -t proc /proc /mnt/proc
mount -t sysfs /sys /mnt/sys
chroot /mnt bash
Then force a kernel update
pacman -Syy
pacman -S linux
For good measure I also re-installed glibc. Note: I did all this AFTER fixing /lib to be a symlink.

I never touched my kernel, I think it was being updated with glibc, it's production was fine. Once I got it down to glibc being the only thing left and it was what was going to be upgraded. removing the files in /lib and possibly the /lib directory itself, left an unusable system. Rebooting would leave it recovering files all over the filesystem during the forced shutdown, but I had a PXE client on the machines so it was an easy way to continue on just like I was using a LiveCD, so this was probably a worst case scenario. The old lib/modules I wasn't worried about. Since the new kernel put all of the modules where they belonged there was no fear of having to worry about the kernel. I checked /usr/lib/modules finding they were there, before doing anything like that. No need to backup any old kernels that weren't in use. I had to update glibc under the PXE client/LiveCD, it wouldn't work any other way that I could tell.

paulbarbee · 2012-07-15 23:00:04

I finally just did "pacman -Suf glibc" due to the fact that I had already symlinked /lib and glibc would not upgrade because of pre-existing files that IT OWNED. I realize this is advised against but as the only reason that glibc would not upgrade due to pre-existing files, the fact that I had tried everything else, and figured if I messed up anything worse I would just reinstall I tried the force option. I suppose I could have unpacked the files from the glibc package and copied them but the force option seemed as likely to work and it did. I hope this helps someone else.

marco_silva85 · 2012-07-16 03:20:17

paulbarbee wrote:

I finally just did "pacman -Suf glibc" due to the fact that I had already symlinked /lib and glibc would not upgrade because of pre-existing files that IT OWNED. I realize this is advised against but as the only reason that glibc would not upgrade due to pre-existing files, the fact that I had tried everything else, and figured if I messed up anything worse I would just reinstall I tried the force option. I suppose I could have unpacked the files from the glibc package and copied them but the force option seemed as likely to work and it did. I hope this helps someone else.

I did all the procedures and ended at the same path as you. I've read every post in this and another thread (as the official info), but no luck.

After glibc was the only one owning some file on /lib, i moved them to /usr/lib, made the symlink and was stuck because it still didn't wan't to be upgraded.

I solved it in the end by doing a --force.
Everything seems ok now.

girzel · 2012-07-16 04:29:08

I've got a weird variation on this problem. After issuing many strange and ignorant commands, I've got a system where /lib is a proper symlink and all the packages are up to date, but many of the symbolic links in /usr/lib are not there. My system boots (or close enough), but I can't use a lot of packages as they're missing the proper files in /usr/lib.

pacman -Su reports that everything is up to date and does nothing. If I explicitly run pacman -S <package with missing files>, however, it will download those files and work properly. Every time I install something successfully I get about nine screens of stuff like this:

ldconfig: /lib/libsamplerate.so.0 is not a symbolic link

I can guess from these errors which packages need to be reinstalled, and do it manually, but at this rate it will take me a whole day, and I can't be sure I've gotten everything. Is there any way I can locate which packages have missing files and just re-install those packages, all in one go?

Any help for a weird problem?

Thanks!

progandy · 2012-07-16 04:43:30

girzel wrote:

I can guess from these errors which packages need to be reinstalled, and do it manually, but at this rate it will take me a whole day, and I can't be sure I've gotten everything. Is there any way I can locate which packages have missing files and just re-install those packages, all in one go?

You can get a list with this command. Then filter it and pass it to pacman -S.

LC_ALL=C sudo pacman -Qk | grep -v ", 0 miss"

girzel · 2012-07-16 05:53:45

progandy wrote:

You can get a list with this command. Then filter it and pass it to pacman -S.
LC_ALL=C sudo pacman -Qk | grep -v ", 0 miss"

Perfect! Should have read the pacman manpage more carefully... It worked just as advertised: a little "cut" and "tr" and I had something to feed directly to yaourt. 468 packages, now downloading 594.14 MB. No clue how I got myself here, but thanks for getting me out.

E

jwatte · 2012-07-16 06:51:44

jasonwryan wrote:

No. YOU have fucked your system.

So... while that may be *technically* true, you have to admit that this upgrade could have been made a *lot* smoother if a modicum of forethought had been included.

"pacman -Syu" should always upgrade to the latest, and do the sane default.

I, too, ran into more grief than I had hoped for. I haven't installed packages outside of using pacman, and my upgrade still didn't work right. That's just shoddy packaging and not caring for a smooth user experience, no matter what you want to call it. Anyone who tries to defend this just doesn't understand users (even technically adept users.)

jasonwryan · 2012-07-16 07:09:53

jwatte wrote:

jasonwryan wrote:
No. YOU have fucked your system.
So... while that may be *technically* true, you have to admit that this upgrade could have been made a *lot* smoother if a modicum of forethought had been included.
"pacman -Syu" should always upgrade to the latest, and do the sane default.
I, too, ran into more grief than I had hoped for. I haven't installed packages outside of using pacman, and my upgrade still didn't work right. That's just shoddy packaging and not caring for a smooth user experience, no matter what you want to call it. Anyone who tries to defend this just doesn't understand users (even technically adept users.)

I disagree. My experience, and that of most people--given that it is only complaints that appear here or on IRC--was straightforward. Only one of my three boxes required actual intervention (the other two, admittredly, are newer installs).

Describing it as shoddy packaging, is IMO, both inaccurate and, considering that the packaging is done by volunteers in their spare time, ungracious. For users that have maintained their systems and paid attention to the amply communicated instructions, the upgrade was not a big deal considering the fundamental nature of the change involved.

I understand people who experienced difficulties get frustrated and upset; however, I have very little sympathy for those that adopt a churlish sense of indignant entitlement, particularly when they do not do anything to contribute to Arch themselves.

Patches, as they say, are always welcome. Whining is not.

Allan · 2012-07-16 07:21:50

jwatte wrote:

That's just shoddy packaging and not caring for a smooth user experience, no matter what you want to call it. Anyone who tries to defend this just doesn't understand users (even technically adept users.)

Doesn't understand is different to doesn't care....

ngoonee · 2012-07-16 07:22:46

jwatte wrote:

jasonwryan wrote:
No. YOU have fucked your system.
So... while that may be *technically* true, you have to admit that this upgrade could have been made a *lot* smoother if a modicum of forethought had been included.

Please refer to the wiki and the mailing list archives before making baseless accusations. This update has been through the [testing] repo, and better informed people than I have already explained why this was the best way to do it.

If it could have been made a lot smoother, then please explain how.

donniezazen · 2012-07-16 07:30:50

bennyh wrote:

pacman -Syu --ignore glibc 
rm -rf /lib/modules
pacman -Syu
worked like a charm for me. I also had to reinstall catalyst and my kernels.

Thanks worked fine. Had to remove linux-ck and bbswitch. No big deal.

jfu · 2012-07-16 08:16:36

I managed to screw up my installation too as many others did. I downloaded the latest official release because I thought I might as well do a fresh reinstall and boy, it sure leads to lots of troubles. Has anyone tried installing from scratch since this change was applied?

I think it is time for a new official Arch Release. The latest is half a year old and during that time there has been a lot of big interface changes.

Allan · 2012-07-16 08:55:09

How to upgrade from an old core iso: http://allanmcrae.com/2012/07/updating- … e-install/

New isos are going to be released soon, but net installs avoid the need to update at all.

Vilius · 2012-07-16 11:01:40

I did pacman -Syu --ignore glibc. Yet even after removing /lib/modules I still get the following when I try to pacman -Su.

error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
Errors occurred, no packages were upgraded.

What does it mean "cannot determine ownership"?

[desperateuser@hisbelovedmachine]$ find /lib -exec pacman -Qo -- {} + | grep -v "glibc"
error: cannot determine ownership of directory '/lib'

The following command gives me an empty output.

grep '^lib/' /var/lib/pacman/local/*/files | grep -v glibc

I've also noticed this:

[desperateuser@hisbelovedmachine]$ ls -l | grep lib
drwxr-xr-x   2 root   root   4096 Jul 16 10:51 lib
lrwxrwxrwx   1 root   root      4 Jul  2 19:33 lib64 -> /lib

May the link lib64 -> /lib have something to do with my problem?

Allan · 2012-07-16 11:42:51

Do not "grep -v glibc" in any output.... lib32-glibc has "glibc" in it.

Arch Linux

#76 2012-07-15 15:47:03

Re: glibc update refusing to proceed. File ownership problem

#77 2012-07-15 15:49:37

Re: glibc update refusing to proceed. File ownership problem

#78 2012-07-15 15:55:46

Re: glibc update refusing to proceed. File ownership problem

#79 2012-07-15 15:56:19

Re: glibc update refusing to proceed. File ownership problem

#80 2012-07-15 15:58:56

Re: glibc update refusing to proceed. File ownership problem

#81 2012-07-15 15:59:41

Re: glibc update refusing to proceed. File ownership problem

#82 2012-07-15 16:18:17

Re: glibc update refusing to proceed. File ownership problem

#83 2012-07-15 17:41:08

Re: glibc update refusing to proceed. File ownership problem

#84 2012-07-15 19:49:53

Re: glibc update refusing to proceed. File ownership problem

#85 2012-07-15 19:54:39

Re: glibc update refusing to proceed. File ownership problem

#86 2012-07-15 20:08:51

Re: glibc update refusing to proceed. File ownership problem

#87 2012-07-15 23:00:04

Re: glibc update refusing to proceed. File ownership problem

#88 2012-07-16 03:20:17

Re: glibc update refusing to proceed. File ownership problem

#89 2012-07-16 04:29:08

Re: glibc update refusing to proceed. File ownership problem

#90 2012-07-16 04:43:30

Re: glibc update refusing to proceed. File ownership problem

#91 2012-07-16 05:53:45

Re: glibc update refusing to proceed. File ownership problem

#92 2012-07-16 06:51:44

Re: glibc update refusing to proceed. File ownership problem

#93 2012-07-16 07:09:53

Re: glibc update refusing to proceed. File ownership problem

#94 2012-07-16 07:21:50

Re: glibc update refusing to proceed. File ownership problem

#95 2012-07-16 07:22:46

Re: glibc update refusing to proceed. File ownership problem

#96 2012-07-16 07:30:50

Re: glibc update refusing to proceed. File ownership problem

#97 2012-07-16 08:16:36

Re: glibc update refusing to proceed. File ownership problem

#98 2012-07-16 08:55:09

Re: glibc update refusing to proceed. File ownership problem

#99 2012-07-16 11:01:40

Re: glibc update refusing to proceed. File ownership problem

#100 2012-07-16 11:42:51

Re: glibc update refusing to proceed. File ownership problem

Board footer