glibc update refusing to proceed. File ownership problem

ewaller · 2012-07-28 22:04:48

nomorewindows wrote:

He's not OP!

That is true
He was at the top of the page and I missed that I was on Page 14.

Let me amend my comment. Definitively open an new thread for the X issue. If you feel it is relevant, please link back to this thread.

Sorry.

LB06 · 2012-07-29 11:57:29

Strike0 wrote:

LB06 wrote:
I don't get it. When doing pacman -Su I still get the conflicting files error. When I execute the greps from the wiki however, it shows that all files are owned by glibc: http://pastebin.com/mFJpiJZu
No, the empty directory /lib/modules is left over. You have to delete that manually.

Ah thanks. Missed that one. I was only paying attention to files.

Last edited by LB06 (2012-07-29 11:57:44)

perbh · 2012-07-31 17:30:45

Yup - I was one of the 'quick'-ones using the force (I know, should've known better), but I did figure it all out in the end (still the wrong way, but it worked - something like this:)

cp -r /lib/* /usr/lib
ln -s /lib /lib.new
## insert some shouting and cussing and jumping around ##
## some few pacmen ##
#- boot from some live cd -#
mv lib lib.old
mv lib.new lib

One thing I have _not_ seen yet though - why the change??
Every other distro I have come across still uses /lib ...

fsckd · 2012-07-31 18:10:34

perbh wrote:

Yup - I was one of the 'quick'-ones using the force (I know, should've known better), but I did figure it all out in the end (still the wrong way, but it worked - something like this:)
cp -r /lib/* /usr/lib
ln -s /lib /lib.new
## insert some shouting and cussing and jumping around ##
## some few pacmen ##
#- boot from some live cd -#
mv lib lib.old
mv lib.new lib

I do not think that does what you think it does. Quick check, where does /lib point to?

One thing I have _not_ seen yet though - why the change??
Every other distro I have come across still uses /lib ...

They'll follow. Arch is on the bleeding edge.

perbh · 2012-08-01 02:05:51

@fsckd
Yup - sorry - typo
Should be:
ln -s /usr/lib /lib.new

As for

They'll follow. Arch is on the bleeding edge

Yeah - they probably will, but ... I'd still like to know archlinux's reason ... which package/subsystem/whatever needs it?

I'm not trying to convict anybody - just wanting to know the reason.

perbh · 2012-08-01 03:59:27

Ok - seeing I have just done my 7th and last *sigh* computer, let me document it here and now (and yes, it was some time since I last updated)
I have truthfully tried all the ways described to the letter - and I do not have any exotic packages - but ... the recommended way doesn't work for me!

pacman -Syy pacman
pacman -Su --ignore glibc,vim-runtime
# this leads to 110 packages being installed and about 100 having to be ignored

pacman -Su   # nope, no luck, the usual complaint about /lib ...

ln -s /usr/lib /lib.new
mkdir /lib.old
cp -r /lib/* /lib.old
rm -r /lib/{udev,modules}
pacman -Su   # still no luck, glibc by now owns everything but /lib itself, dont know how to sort that one!!
reboot

# booting into another distro on the same disk (but _any_ live cd will do)
mount /dev/sda6 /mnt/hd   # sda6 is where my arch resides
cd /mnt/hd
mv lib/* usr/lib
rmdir lib   # it should now be empty
mv lib.new lib
cd && umount /mnt/hd
reboot

# booting back into archlinux  while holding my breath - it works!!
pacman -Su   # oh dear - a lot of 'exists in filesystem' - all glibc related
pacman -Sf glibc   # ok
pacman -Su  # ok, the remaining 100-or-so packages successfully updated

reboot   # yeehaw!!

Palace · 2012-08-01 06:24:23

Zamboniman wrote:

Well, reading this thread has been interesting. People seem to be randomly moving things, deleting things, forcing things, and generally messing up their systems.
I can understand why. This has been one of the more frustrating upgrades in my history with Arch. However, take a deep breath, calm down, and take it a step at a time.
Here's Zamboniman's quick guide to upgrading glibc:
pacman -Syy
pacman -Syu --ignore glibc
pacman -Su
If (when) the last one fails, it's because you have a mess of stuff in /lib, owned by other packages or random chaff. You need to take care of this, but not by randomly moving and deleting, by finding out what owns it and then taking care of it.
So:
find /lib -exec pacman -Qo -- {} +
will show you what packages own all the files in lib. Look for anything NOT owned by glibc. That's a problem. If you're getting a bunch of stuff (most likely in the modules directory, but elsewhere too) not owned by anything, look at it. It's probably leftover files from earlier packages. Most likely modules from earlier kernel versions. If you no longer run those kernels, or even have those kernels, then go ahead and delete the relevant subdirectory under the modules directory. Or, if you're worried, just temporarily move it somewhere. Then go ahead and do the same with all the other stuff. Your modules directory under /lib should now be empty. Delete it.
Now use
pacman -R relevant-package
to temporarily remove whatever relevant-package is still in the way. You can re-install it later. If you have dependency problems, look closely. You can probably (almost certainly) remove those dependencies too. Again, you can always reinstall afterwards. If you simply can't, you MAY want to consider forcing the removal HERE ONLY--NOT FOR GLIBC, but USE CAUTION. It's far, far better to uninstall and reinstall.

BUT WAIT! YOU'RE NOT DONE!!
Now you need to do this:
grep '^lib/' /var/lib/pacman/local/*/files
Look carefully at the output. You'll more than likely notice, once again, stuff not owned by glibc. If your /lib directory itself showed up as unknown in the earlier command, this is why. Some other package put files in /lib so thinks it has rights to it. Once again, look through and use pacman to remove all packages that are not glibc.
pacman -R relevant-package
Again, you may need to remove (and later re-install) dependencies too. So note what you're removing.
Okay, now the output of both
find /lib -exec pacman -Qo -- {} +
and
grep '^lib/' /var/lib/pacman/local/*/files
should ONLY show glibc relevant stuff.

If not, once again, remove the offending package using pacman, or if it's leftover garbage, move it or delete it.

If you're having issues with gcc-multilib and associated packages do:
pacman -S gcc
to temporarily use plain old gcc. Accept the question to remove multilib stuff in favor of gcc stuff. Once you're done, again, you can go back to gcc-multilib.
Now, once again, do
pacman -Su
And there you go. Glibc will update, probably along with other stuff.
Now, finally, go ahead and reinstall whatever you needed to uninstall earlier. If it's AUR stuff, installed through yaourt or packer or whatever (or manually), scream loudly at the maintainer to fix his broken mess. Only, no, don't do this. Instead, flag his package as out of date and leave a kind and helpful comment on what the problem is.
There you go. I hope this helps a few of you.

So I ran pacman -Syu today and ran into this issue after which I read the wiki and did pacman -Syu --ignore glibc and then pacman -Su...of course, I ran into the glibc ownership issue so I ran the find command and saw a ton of /lib/modules stuff. I moved both suddirectories I had in there to a backup in my home and removed the modules directory. After doing that I see the following as the output of the find command:

error: cannot determine ownership of directory '/lib'
/lib/libnss_compat.so.2 is owned by glibc 2.15-12
/lib/libthread_db-1.0.so is owned by glibc 2.15-12
/lib/libc-2.15.so is owned by glibc 2.15-12
/lib/libcrypt.so.1 is owned by glibc 2.15-12
/lib/libcrypt-2.15.so is owned by glibc 2.15-12
/lib/libnss_compat-2.15.so is owned by glibc 2.15-12
/lib/libthread_db.so.1 is owned by glibc 2.15-12
/lib/libpcprofile.so is owned by glibc 2.15-12
/lib/libnss_files.so.2 is owned by glibc 2.15-12
/lib/libpthread-2.15.so is owned by glibc 2.15-12
/lib/libBrokenLocale-2.15.so is owned by glibc 2.15-12
/lib/libnss_db.so.2 is owned by glibc 2.15-12
/lib/librt-2.15.so is owned by glibc 2.15-12
/lib/libnss_nisplus-2.15.so is owned by glibc 2.15-12
/lib/libc.so.6 is owned by glibc 2.15-12
/lib/libnss_db-2.15.so is owned by glibc 2.15-12
/lib/librt.so.1 is owned by glibc 2.15-12
/lib/libcidn.so.1 is owned by glibc 2.15-12
/lib/libdl.so.2 is owned by glibc 2.15-12
/lib/libutil.so.1 is owned by glibc 2.15-12
/lib/libanl.so.1 is owned by glibc 2.15-12
/lib/libnsl.so.1 is owned by glibc 2.15-12
/lib/ld-2.15.so is owned by glibc 2.15-12
/lib/libnss_nis-2.15.so is owned by glibc 2.15-12
/lib/libnss_dns-2.15.so is owned by glibc 2.15-12
/lib/libBrokenLocale.so.1 is owned by glibc 2.15-12
/lib/libnss_dns.so.2 is owned by glibc 2.15-12
/lib/libpthread.so.0 is owned by glibc 2.15-12
/lib/libutil-2.15.so is owned by glibc 2.15-12
/lib/libSegFault.so is owned by glibc 2.15-12
/lib/libanl-2.15.so is owned by glibc 2.15-12
/lib/libnss_hesiod-2.15.so is owned by glibc 2.15-12
/lib/libm.so.6 is owned by glibc 2.15-12
/lib/libresolv-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-2.15.so is owned by glibc 2.15-12
/lib/libcidn-2.15.so is owned by glibc 2.15-12
/lib/libm-2.15.so is owned by glibc 2.15-12
/lib/libresolv.so.2 is owned by glibc 2.15-12
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.15-12
/lib/libnss_nis.so.2 is owned by glibc 2.15-12
/lib/libnss_nisplus.so.2 is owned by glibc 2.15-12
/lib/libmemusage.so is owned by glibc 2.15-12
/lib/libnsl-2.15.so is owned by glibc 2.15-12
/lib/libnss_hesiod.so.2 is owned by glibc 2.15-12

which if i grep out the glibc part only leaves:

error: cannot determine ownership of directory '/lib'

I then run the grep command and I see a ton of stuff not glibc relevant but it alll refers to the modules stuff I already got rid of!

...
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/synth/emux/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/synth/emux/snd-emux-synth.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/synth/snd-util-mem.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/6fire/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/6fire/snd-usb-6fire.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/caiaq/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/caiaq/snd-usb-caiaq.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/misc/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/misc/snd-ua101.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/snd-usb-audio.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/snd-usbmidi-lib.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/usx2y/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/usx2y/snd-usb-us122l.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/usx2y/snd-usb-usx2y.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/modules.alias
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/modules.alias.bin
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/modules.builtin
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/modules.builtin.bin
...

What should I do in this case? I thought I had taken care of that, /lib/modules doesnt even exist anymore!

fsckd · 2012-08-01 14:19:44

perbh wrote:

@fsckd
Yup - sorry - typo
Should be:
ln -s /usr/lib /lib.new

That makes sense.

As for
They'll follow. Arch is on the bleeding edge
Yeah - they probably will, but ... I'd still like to know archlinux's reason ... which package/subsystem/whatever needs it?
I'm not trying to convict anybody - just wanting to know the reason.

The reason for merging /lib into /usr/lib is mentioned in a few places (including the mailing lists). Here is a forum post where a developer (teg) answers a question similar to yours.

Barrucadu · 2012-08-01 14:38:36

Palace wrote:

What should I do in this case? I thought I had taken care of that, /lib/modules doesnt even exist anymore!

Your version of glibc is too old and so the `pacman -Syu --ignore glibc` failed (did you even read the output?) due to versioned dependencies. Put those files back and upgrade to glibc 2.16.0-1, then continue (this is covered in the wiki).

I am Gianluca · 2012-08-01 20:48:29

Hello guys,

I still have some problems related with the upgrade of glibc package. Today I've ran:

$ pacman -Syu

Not as root because I'm still mounting the partitions and using the liveUSB. I have problem detecting the screen with X.org after the glibc upgrade.
Pacman advice me to upgrade pacman itself before and after upgrade the system. I've done it but I encounter these errors message:

glibc: /lib exists in filesystem
glibc: /usr/bin/tzselectexists in filesystem
glibc: /usr/sbin/zdump exists in filesystem
glibc: /usr/sbin/zic exists in filesystem
Errors occurred, no packages were upgraded.

MickeyKnox · 2012-08-01 21:34:26

I ran both

grep '^lib/' /var/lib/pacman/local/*/files

and

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

which spit out thousends of lines for a few seconds which i'm for sure not going to process all.
A lot of them seem to be related to the kernel i'm currently running.

Now i have a simple question: Is there an easy way to deal with this?

MickeyKnox · 2012-08-01 22:19:11

This is just great! After a reboot i have no network and no xorg.

What now?

cfr · 2012-08-01 22:57:10

@I am Gianluca

Are you sure you did upgrade glibc? What version do you have installed?

Palace · 2012-08-02 03:29:17

Barrucadu wrote:

Palace wrote:
What should I do in this case? I thought I had taken care of that, /lib/modules doesnt even exist anymore!
Your version of glibc is too old and so the `pacman -Syu --ignore glibc` failed (did you even read the output?) due to versioned dependencies. Put those files back and upgrade to glibc 2.16.0-1, then continue (this is covered in the wiki).

When I try to update glibc to 2.16 I get the /lib exists in filesystem error and it wont upgrade.

To make matters worse i am unable to boot properly, I first see an error "unknown interface eth0 in rc.conf" (which has never been an issue) and then usually slim runs but now i get INIT: ld "x" respawning too fast: disabled for 5 minutes

I took out the pipe to dev/null in inittab for slim to see an error message and I see Fatal server error: no screens found. I fear something iffy happened with my pacman -Syu --ignore glibc (which honestly i dont recall failing) and I'm at a loss for what to do now. All I can do is look at my history in a terminal and see that what I ran last night was:

pacman -Syu --ignore glibc
pacman -Sd binutils gcc gcc-libs
sudo pacman -Su

the last one failed so then I moved /lib/modules/* to a backup location, deleted that directory..still saw failures..and called it a night. Now I am unable to get my login manager..I end up in a terminal and I try moving the modules stuff back...

Palace · 2012-08-02 03:42:02

Palace wrote:

Barrucadu wrote:
Palace wrote:
What should I do in this case? I thought I had taken care of that, /lib/modules doesnt even exist anymore!
Your version of glibc is too old and so the `pacman -Syu --ignore glibc` failed (did you even read the output?) due to versioned dependencies. Put those files back and upgrade to glibc 2.16.0-1, then continue (this is covered in the wiki).
When I try to update glibc to 2.16 I get the /lib exists in filesystem error and it wont upgrade.
To make matters worse i am unable to boot properly, I first see an error "unknown interface eth0 in rc.conf" (which has never been an issue) and then usually slim runs but now i get INIT: ld "x" respawning too fast: disabled for 5 minutes
I took out the pipe to dev/null in inittab for slim to see an error message and I see Fatal server error: no screens found. I fear something iffy happened with my pacman -Syu --ignore glibc (which honestly i dont recall failing) and I'm at a loss for what to do now. All I can do is look at my history in a terminal and see that what I ran last night was:
pacman -Syu --ignore glibc
pacman -Sd binutils gcc gcc-libs
sudo pacman -Su
the last one failed so then I moved /lib/modules/* to a backup location, deleted that directory..still saw failures..and called it a night. Now I am unable to get my login manager..I end up in a terminal and I try moving the modules stuff back...

Shoot! Trying more thing with the wiki I moved modules back out and then I did sudo mv -n /lib/* /usr/lib/
Now I can't even type or boot at all! Now I'm extremely worried.

I am Gianluca · 2012-08-02 08:54:42

cfr wrote:

@I am Gianluca
Are you sure you did upgrade glibc? What version do you have installed?

The command 'pacman -Qi glibc -r /mnt/arch' tells me version 2.16.0-2.
I've tried to re-install another time glibc with 'pacman -S glibc -r /mnt/arch' and it went well. After have done it, I ran 'pacman -Syu -r /mnt/arch' and it worked. The only problem is that it didn't recognise my locale.
I still have problems with X.org (which doesn't recognise my screen) and usb storage mount.
I'm seriously worried about how to do, because I need my laptop working as soon as possible and at this time I haven't a backup, nor I know how to do being not able to mount an USB storage.

Last edited by I am Gianluca (2012-08-02 09:48:53)

Barrucadu · 2012-08-02 10:19:34

Palace wrote:

When I try to update glibc to 2.16 I get the /lib exists in filesystem error and it wont upgrade.

2.16.0-1, not 2.16.0-2. Get the package from http://pkgbuild.com/~allan/. This will resolve your versioned dependency problem.

Palace · 2012-08-02 13:53:22

Barrucadu wrote:

Palace wrote:
When I try to update glibc to 2.16 I get the /lib exists in filesystem error and it wont upgrade.
2.16.0-1, not 2.16.0-2. Get the package from http://pkgbuild.com/~allan/. This will resolve your versioned dependency problem.

Ahh wish I had seen this before the sudo mv -n /lib /usr/lib I am unable to boot now, all I see is kernel panic, no commands are all are found...this seriously broke my system how can I recover/undo this? Before I did the sudo mv -n (-n for no clobber) I saved the list of files that were in /lib so I could hopefully undo this.

cfr · 2012-08-03 00:39:32

@Palace,

Boot the system from a live media (CD/USB key/whatever) and repair the system from there.

@I am Gianluca,

So you are not getting the errors posted above any longer such as:

glibc: /lib exists in filesystem
...

In what sense is your locale not recognised?

What are the exact errors you're seeing when you try to boot? Post exact messages/log files.

MickeyKnox · 2012-08-03 10:39:11

I solved my problem. The key was to use the -d switch on the upgrade.
It is mentioned in the wike, but hidden in the blue Note.
I think therefore, the first command should be:

pacman -Syud --ignore glibc

After that, there was just one directory left in /lib, which was modules/3.2.6-2-ARCH,
which i think belongs to some old kernel. I moved that to root's home and
after that, the upgrade ran smoothely. X and network are working again.

dave00 · 2012-08-09 02:16:30

I'm still struggling here, hadn't updated in a long time (332 targets show up in the syu). Once I got past the filesystem and /var/run /var/lock stuff, thought it wouldn't be too bad but I was wrong!

# pacman -Syu
glibc: /lib exists in filesystem

Follow the wiki...

# pacman -U http://pkgbuild.com/~allan/glibc-2.16.0-1-x86_64.pkg.tar.xz
Targets (2): linux-api-headers-3.4.6-1  glibc-2.16.0-1
glibc: /usr/bin/tzselect exists in filesystem
glibc: /usr/sbin/zdump exists in filesystem
glibc: /usr/sbin/zic exists in filesystem

Edit: Solved!

Update tzdata preventing the manual upgrade
pacman -S tzdata
this then worked:
pacman -U http://pkgbuild.com/~allan/glibc-2.16.0 … pkg.tar.xz

Could then run full update ignoring items which will cause problems
pacman -Syu --ignore filesystem,glibc,curl

Had to then do filesystem as per the news page and
pacman -S glibc
Doing an Su kept failing as /lib had stuff owned by glibc 2.16.0-1

Last edited by dave00 (2012-08-09 05:04:28)

verduler · 2012-09-05 20:30:12

Palace wrote:

Zamboniman wrote:
Well, reading this thread has been interesting. People seem to be randomly moving things, deleting things, forcing things, and generally messing up their systems.
I can understand why. This has been one of the more frustrating upgrades in my history with Arch. However, take a deep breath, calm down, and take it a step at a time.
Here's Zamboniman's quick guide to upgrading glibc:
pacman -Syy
pacman -Syu --ignore glibc
pacman -Su
If (when) the last one fails, it's because you have a mess of stuff in /lib, owned by other packages or random chaff. You need to take care of this, but not by randomly moving and deleting, by finding out what owns it and then taking care of it.
So:
find /lib -exec pacman -Qo -- {} +
will show you what packages own all the files in lib. Look for anything NOT owned by glibc. That's a problem. If you're getting a bunch of stuff (most likely in the modules directory, but elsewhere too) not owned by anything, look at it. It's probably leftover files from earlier packages. Most likely modules from earlier kernel versions. If you no longer run those kernels, or even have those kernels, then go ahead and delete the relevant subdirectory under the modules directory. Or, if you're worried, just temporarily move it somewhere. Then go ahead and do the same with all the other stuff. Your modules directory under /lib should now be empty. Delete it.
Now use
pacman -R relevant-package
to temporarily remove whatever relevant-package is still in the way. You can re-install it later. If you have dependency problems, look closely. You can probably (almost certainly) remove those dependencies too. Again, you can always reinstall afterwards. If you simply can't, you MAY want to consider forcing the removal HERE ONLY--NOT FOR GLIBC, but USE CAUTION. It's far, far better to uninstall and reinstall.

BUT WAIT! YOU'RE NOT DONE!!
Now you need to do this:
grep '^lib/' /var/lib/pacman/local/*/files
Look carefully at the output. You'll more than likely notice, once again, stuff not owned by glibc. If your /lib directory itself showed up as unknown in the earlier command, this is why. Some other package put files in /lib so thinks it has rights to it. Once again, look through and use pacman to remove all packages that are not glibc.
pacman -R relevant-package
Again, you may need to remove (and later re-install) dependencies too. So note what you're removing.
Okay, now the output of both
find /lib -exec pacman -Qo -- {} +
and
grep '^lib/' /var/lib/pacman/local/*/files
should ONLY show glibc relevant stuff.

If not, once again, remove the offending package using pacman, or if it's leftover garbage, move it or delete it.

If you're having issues with gcc-multilib and associated packages do:
pacman -S gcc
to temporarily use plain old gcc. Accept the question to remove multilib stuff in favor of gcc stuff. Once you're done, again, you can go back to gcc-multilib.
Now, once again, do
pacman -Su
And there you go. Glibc will update, probably along with other stuff.
Now, finally, go ahead and reinstall whatever you needed to uninstall earlier. If it's AUR stuff, installed through yaourt or packer or whatever (or manually), scream loudly at the maintainer to fix his broken mess. Only, no, don't do this. Instead, flag his package as out of date and leave a kind and helpful comment on what the problem is.
There you go. I hope this helps a few of you.
So I ran pacman -Syu today and ran into this issue after which I read the wiki and did pacman -Syu --ignore glibc and then pacman -Su...of course, I ran into the glibc ownership issue so I ran the find command and saw a ton of /lib/modules stuff. I moved both suddirectories I had in there to a backup in my home and removed the modules directory. After doing that I see the following as the output of the find command:
error: cannot determine ownership of directory '/lib'
/lib/libnss_compat.so.2 is owned by glibc 2.15-12
/lib/libthread_db-1.0.so is owned by glibc 2.15-12
/lib/libc-2.15.so is owned by glibc 2.15-12
/lib/libcrypt.so.1 is owned by glibc 2.15-12
/lib/libcrypt-2.15.so is owned by glibc 2.15-12
/lib/libnss_compat-2.15.so is owned by glibc 2.15-12
/lib/libthread_db.so.1 is owned by glibc 2.15-12
/lib/libpcprofile.so is owned by glibc 2.15-12
/lib/libnss_files.so.2 is owned by glibc 2.15-12
/lib/libpthread-2.15.so is owned by glibc 2.15-12
/lib/libBrokenLocale-2.15.so is owned by glibc 2.15-12
/lib/libnss_db.so.2 is owned by glibc 2.15-12
/lib/librt-2.15.so is owned by glibc 2.15-12
/lib/libnss_nisplus-2.15.so is owned by glibc 2.15-12
/lib/libc.so.6 is owned by glibc 2.15-12
/lib/libnss_db-2.15.so is owned by glibc 2.15-12
/lib/librt.so.1 is owned by glibc 2.15-12
/lib/libcidn.so.1 is owned by glibc 2.15-12
/lib/libdl.so.2 is owned by glibc 2.15-12
/lib/libutil.so.1 is owned by glibc 2.15-12
/lib/libanl.so.1 is owned by glibc 2.15-12
/lib/libnsl.so.1 is owned by glibc 2.15-12
/lib/ld-2.15.so is owned by glibc 2.15-12
/lib/libnss_nis-2.15.so is owned by glibc 2.15-12
/lib/libnss_dns-2.15.so is owned by glibc 2.15-12
/lib/libBrokenLocale.so.1 is owned by glibc 2.15-12
/lib/libnss_dns.so.2 is owned by glibc 2.15-12
/lib/libpthread.so.0 is owned by glibc 2.15-12
/lib/libutil-2.15.so is owned by glibc 2.15-12
/lib/libSegFault.so is owned by glibc 2.15-12
/lib/libanl-2.15.so is owned by glibc 2.15-12
/lib/libnss_hesiod-2.15.so is owned by glibc 2.15-12
/lib/libm.so.6 is owned by glibc 2.15-12
/lib/libresolv-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-2.15.so is owned by glibc 2.15-12
/lib/libcidn-2.15.so is owned by glibc 2.15-12
/lib/libm-2.15.so is owned by glibc 2.15-12
/lib/libresolv.so.2 is owned by glibc 2.15-12
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.15-12
/lib/libnss_nis.so.2 is owned by glibc 2.15-12
/lib/libnss_nisplus.so.2 is owned by glibc 2.15-12
/lib/libmemusage.so is owned by glibc 2.15-12
/lib/libnsl-2.15.so is owned by glibc 2.15-12
/lib/libnss_hesiod.so.2 is owned by glibc 2.15-12
which if i grep out the glibc part only leaves:
error: cannot determine ownership of directory '/lib'
I then run the grep command and I see a ton of stuff not glibc relevant but it alll refers to the modules stuff I already got rid of!
...
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/synth/emux/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/synth/emux/snd-emux-synth.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/synth/snd-util-mem.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/6fire/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/6fire/snd-usb-6fire.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/caiaq/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/caiaq/snd-usb-caiaq.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/misc/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/misc/snd-ua101.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/snd-usb-audio.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/snd-usbmidi-lib.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/usx2y/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/usx2y/snd-usb-us122l.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/kernel/sound/usb/usx2y/snd-usb-usx2y.ko.gz
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/modules.alias
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/modules.alias.bin
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/modules.builtin
/var/lib/pacman/local/linux-3.4.4-2/files:lib/modules/3.4.4-2-ARCH/modules.builtin.bin
...
What should I do in this case? I thought I had taken care of that, /lib/modules doesnt even exist anymore!

I have exatly the same problem, with a difference, I have deleted all the contents on the /lib/modules and I don't have a backup. Whant should I do? I'm a bit lost!

cfr · 2012-09-05 22:29:06

Unless you haven't updated for a while, you may not need that directory or its contents at all. Check whether you have modules under /usr/lib/modules.

verduler · 2012-09-06 04:24:50

cfr wrote:

Unless you haven't updated for a while, you may not need that directory or its contents at all. Check whether you have modules under /usr/lib/modules.

I haven't update for a while, I have been on holidays. I don't have any files inside the modules folder because I have delete it.

Strike0 · 2012-09-06 09:22:06

verduler wrote:

cfr wrote:
Unless you haven't updated for a while, you may not need that directory or its contents at all. Check whether you have modules under /usr/lib/modules.
I haven't update for a while, I have been on holidays. I don't have any files inside the modules folder because I have delete it.

Reading your two posts here my guess would be you dont have any files inside the /usr/lib/modules directory, because you have not finished the update. If you only deleted /lib/modules/..(as you write earlier) : that's no problem at all if you use an Arch stock kernel. But it can only be a guess, because your post says very little as to what steps you have done to update glibc.

Arch Linux

#351 2012-07-28 22:04:48

Re: glibc update refusing to proceed. File ownership problem

#352 2012-07-29 11:57:29

Re: glibc update refusing to proceed. File ownership problem

#353 2012-07-31 17:30:45

Re: glibc update refusing to proceed. File ownership problem

#354 2012-07-31 18:10:34

Re: glibc update refusing to proceed. File ownership problem

#355 2012-08-01 02:05:51

Re: glibc update refusing to proceed. File ownership problem

#356 2012-08-01 03:59:27

Re: glibc update refusing to proceed. File ownership problem

#357 2012-08-01 06:24:23

Re: glibc update refusing to proceed. File ownership problem

#358 2012-08-01 14:19:44

Re: glibc update refusing to proceed. File ownership problem

#359 2012-08-01 14:38:36

Re: glibc update refusing to proceed. File ownership problem

#360 2012-08-01 20:48:29

Re: glibc update refusing to proceed. File ownership problem

#361 2012-08-01 21:34:26

Re: glibc update refusing to proceed. File ownership problem

#362 2012-08-01 22:19:11

Re: glibc update refusing to proceed. File ownership problem

#363 2012-08-01 22:57:10

Re: glibc update refusing to proceed. File ownership problem

#364 2012-08-02 03:29:17

Re: glibc update refusing to proceed. File ownership problem

#365 2012-08-02 03:42:02

Re: glibc update refusing to proceed. File ownership problem

#366 2012-08-02 08:54:42

Re: glibc update refusing to proceed. File ownership problem

#367 2012-08-02 10:19:34

Re: glibc update refusing to proceed. File ownership problem

#368 2012-08-02 13:53:22

Re: glibc update refusing to proceed. File ownership problem

#369 2012-08-03 00:39:32

Re: glibc update refusing to proceed. File ownership problem

#370 2012-08-03 10:39:11

Re: glibc update refusing to proceed. File ownership problem

#371 2012-08-09 02:16:30

Re: glibc update refusing to proceed. File ownership problem

#372 2012-09-05 20:30:12

Re: glibc update refusing to proceed. File ownership problem

#373 2012-09-05 22:29:06

Re: glibc update refusing to proceed. File ownership problem

#374 2012-09-06 04:24:50

Re: glibc update refusing to proceed. File ownership problem

#375 2012-09-06 09:22:06

Re: glibc update refusing to proceed. File ownership problem

Board footer