glibc update refusing to proceed. File ownership problem

fatboy · 2012-07-15 01:56:13

You already have the list of files in /lib/ from the first command. Maybe it'll be easier to move them all back somehow (livecd?), then reboot and try the update again.

Last edited by fatboy (2012-07-15 01:56:44)

paulbarbee · 2012-07-15 02:16:40

Hi, I tried following the DeveloperWiki instructions and simply uninstalled catalyst, mate keyring and a few AUR-based programs that still had files in /lib. Then I re-ran pacman -Syu --ignore glibc and
pacman -Su and still got a message to the effect that it could not upgrade glibc. All files still in /lib appeared to belong to glibc so I issued "mv * /usr/lib" because I thought that's what the DeveloperWiki meant by "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...)." However, after I issued the move command the system could not find /usr/bin/ls or /usr/bin/cp. I rebooted and got a kernel panic. I rebooted from a live CD. The only files that I could remember were in /lib were "l*.so." From the live CD I issued "cp /media/sda5/usr/lib/l* /media/sda5/lib." This got Arch to a usable state and I tried to issue the pacman commands again and got warnings that several files already existed in /usr/lib. I copied /lib to a backup, removed these files, rebooted and got a kernel panic again. I once again booted from the Live CD, copied "l*" to /lib and rebooted.

The system is in a somewhat usable state. I can get to the command line and even a GUI but cannot upgrade anything. As I previously stated if I delete the files from /lib the system will not recognize /usr/bin/ls much less pacman. I am posting from Windows. Please help me. Thank you.

Squiddles · 2012-07-15 02:26:01

fatboy wrote:

You already have the list of files in /lib/ from the first command. Maybe it'll be easier to move them all back somehow (livecd?), then reboot and try the update again.

Alrighty, I went into a live CD, mounted the root partition and moved the files back (I had a backup of the /lib folder) and rebooted. Booted up just fine. I still had the backup so I removed modules folder and did `pacman -Su` it updated just fine. The system persisted through another reboot after the glibc update and /lib is now a symlink to /usr/lib. So that fixed it. I guess that's what I get for not entirely understanding what the wiki was going for.

Potomac · 2012-07-15 02:27:08

Squiddles wrote:

error: No package owns /lib/modules/3.0-ARCH/modules.seriomap
error: No package owns /lib/modules/3.0-ARCH/modules.softdep
error: No package owns /lib/modules/3.0-ARCH/modules.alias.bin

you have some files in /lib/modules and these files belong to old kernel versions,

so the solution is to move the /lib/modules folder to a backup folder :

mv /lib/modules /home/Squiddles/backup

then you can type :

pacman -Su

and glibc will be updated

Last edited by Potomac (2012-07-15 02:27:45)

Squiddles · 2012-07-15 02:29:03

Potomac wrote:

Squiddles wrote:
error: No package owns /lib/modules/3.0-ARCH/modules.seriomap
error: No package owns /lib/modules/3.0-ARCH/modules.softdep
error: No package owns /lib/modules/3.0-ARCH/modules.alias.bin
you have some files in /lib/modules and these files belong to old kernel versions,
so the solution is to move the /lib/modules folder to a backup folder :
mv /lib/modules /home/Squiddles/backup
then you can type :
pacman -Su
and glibc will be updated

Thank you for the response, I just wish it was a bit sooner. I eneded up screwing my install and fixing it with essentially what you suggested.

EDIT:
I still have the entire contents of the modules folder. Should I do anything in particular with it now that I've updated glibc and the symlink is created? Or is it just garbage now?

Last edited by Squiddles (2012-07-15 02:30:20)

fatboy · 2012-07-15 02:42:13

Squiddles wrote:

EDIT:
I still have the entire contents of the modules folder. Should I do anything in particular with it now that I've updated glibc and the symlink is created? Or is it just garbage now?

Garbage, it was related to old kernels anyway. I guess the new kernel update would have brought in it's own modules in /usr/lib/modules.

shaurz · 2012-07-15 02:45:17

So I didn't read the latest post before upgrading, and I used force...

Now my /lib is empty and I get "No such file or directory" when I run a command.

I haven't restarted my system yet and I still have a running terminal. Is there anything I can do to rescue my system?

jasonwryan · 2012-07-15 02:47:17

No. YOU have fucked your system.

Also, rather than going into a blind panic, try searching the boards first...

Merging with the stickied glibc thread.

fatboy · 2012-07-15 02:54:22

shaurz wrote:

So I didn't read the latest post before upgrading, and I used force...
Now my /lib is empty and I get "No such file or directory" when I run a command.
I haven't restarted my system yet and I still have a running terminal. Is there anything I can do to rescue my system?

In case The Force is strong with you, the wiki points to this and this.

shaurz · 2012-07-15 03:25:52

I can boot my system to a root shell, but for some reason the keyboard does not work. I guess I will have to try booting a USB stick.

shaurz · 2012-07-15 04:19:39

So I managed to boot a live CD and followed the steps to fix my system. It seemed to work, but now when I boot it say "Waiting 10 seconds for /dev/sda3", then it times out and drops me to the root shell.

Cluster_one · 2012-07-15 05:18:33

I solved mine.

I never removed the old udev-compat to systemd-tools as indicated here, thus there was files owned by udev in /lib.

So a recap for those that have files owned by udev still in /lib

pacman -Syu --ignore glibc
pacman -Su     (if this fails proceed)

pacman -R udev-compat
pacman -S systemd-tools    or  pacman -S udev

pacman -Su

Forgot to read thread title.

Last edited by Cluster_one (2012-07-15 05:23:13)

paulbarbee · 2012-07-15 05:26:37

I managed to make the symlink from a Live CD, the system still had a kernel panic so I rebooted to the Live CD, copied "l* from the backup of /usr/lib I had earlier and was able to log in to Arch. I did the pacman -Su. It complained that several files already existed in /usr/lib. I deleted libnss* and tried "su" It complained that there was no root user. I rebooted. Now it starts, booting; then it gets a bunch of errors about there not being a username 'root', no password for username "???", unrecognized UUIDs and GUIDs, and then goes to the login screen but will not log any user in.

If I have /usr/lib/libnss* I can log in but cannot upgrade glibc. How do I proceed now?
Thank you!

Zamboniman · 2012-07-15 05:30:31

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.

Last edited by Zamboniman (2012-07-15 07:19:46)

swanson · 2012-07-15 05:36:44

I had some garbage there too, udev-compat and some leftover files from an UFW installation. Deleted those and some old kernel module dirs and uninstalled udev-compat. Then upgraded glibc, then rebooted and held my breath - success!

The tricky thing was that the package udev-compat wasn't in the repos anymore so I couldn't check what it was or reinstall it.

This was by far the most complicated update I've come across in Arch and I think much patience is needed.

Cluster_one · 2012-07-15 06:58:29

swanson wrote:

I had some garbage there too, udev-compat and some leftover files from an UFW installation. Deleted those and some old kernel module dirs and uninstalled udev-compat. Then upgraded glibc, then rebooted and held my breath - success!
The tricky thing was that the package udev-compat wasn't in the repos anymore so I couldn't check what it was or reinstall it.
This was by far the most complicated update I've come across in Arch and I think much patience is needed.

That's because http://www.archlinux.org/news/systemd-t … aces-udev/

kalpik · 2012-07-15 07:42:44

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.

THIS!

This solves everything!

Thank you!

TheImmortalPhoenix · 2012-07-15 08:24:34

Hi friends, i have a problem that i don't know to solve: yesterday i run yaourt -Syyua to upgrade my system, but upgrading was not successful because glibc could not upgrade, error was something like this:

can't upgrade because /lib already exists

So i dediced to upgrade separately glibc with the command "sudo pacman -S -f glibc" but after that i completely lost control of my system, it was as if no program is installed, i always got error "/usr/bin/* doesn't exists"....after rebooting i got the kernel panic, and now i don't know what to do...i tried to do a chroot by my chakra installation but it didn't work, i got error "/bin/bash doesn't exists"

I think i will be forced to format, but i would appreciate if someone of you could help me to understand what have happened....thanks for attention

Last edited by TheImmortalPhoenix (2012-07-15 08:24:59)

jasonwryan · 2012-07-15 08:31:10

The wiki page specifically mentions not using the -force option...

Merging with the glibc stickied thread...

Miles28 · 2012-07-15 08:58:39

Ok, I have made "pacman -Syu --ignore glibc", but after that, when I try to make "pacman -Su", I get the message:

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

I have both /lib and /usr/lib on my system and rebooting gives no error message. After rebooting my pc I have tried to "pacman Su" and get the same error when previously trying to update glibc.

jasonwryan · 2012-07-15 09:01:40

Read the rest of the wiki entry...

Merging with the stickied thread...

progandy · 2012-07-15 09:55:41

TheImmortalPhoenix wrote:

I think i will be forced to format, but i would appreciate if someone of you could help me to understand what have happened....thanks for attention

That is not necessarily true. Since you forced the install, all necessary libraries should already be in usr/lib. So try to boot from cd, mount arch, backup /lib and replace it with a symlink with target usr/lib (without slash at the beginngin).

For someone who can edit the wiki: wouldn't it be better to filter the output of "find /lib -exec pacman -Qo" so that only problematic files will shown?

LC_ALL=C find /lib -exec pacman -Qo -- {} + | grep -v "is owned by glibc "

Last edited by progandy (2012-07-15 09:56:04)

mjb · 2012-07-15 10:10:13

Hi,

when doing

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

i get the following errors:

error: cannot determine ownership of directory '/lib/ufw'
error: cannot determine ownership of directory '/lib'
/lib/libthread_db-1.0.so is owned by glibc 2.16.0-1
/lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
error: cannot determine ownership of directory '/lib/modules'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.3-ARCH'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.3-ARCH/kernel'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.3-ARCH/kernel/oss'
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_imux.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_audigyls.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_solo.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_via823x.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_ich.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_emu10k1x.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_envy24ht.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_audiopci.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_fmedia.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_sbxfi.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_via97.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_ymf7xx.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_geode.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_midiloop.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_envy24.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_cs4281.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_ali5455.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_usb.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_sblive.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_cmpci.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_digi96.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_midimix.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_trident.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_hdaudio.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_userdev.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_sbpci.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_cs461x.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/osscore.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_cmi878x.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_atiaudio.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_audioloop.ko
error: No package owns /lib/modules/extramodules-3.3-ARCH/kernel/oss/oss_madi.ko

and a lot of other lines of the form

[...] is owned by glibc 2.16.0-1

The latter should be ok, right? But what about the lines with the errors?

What can I do here? Can someone give me a hint?

Thanks a lot!

Last edited by mjb (2012-07-15 10:26:49)

guest53290 · 2012-07-15 10:16:59

Hello,
yesterday I tried to update my system. I ran

pacman -Syu --ignore glibc
pacman -Su

but the error

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

remained. So after a quick peek at the wiki ( https://wiki.archlinux.org/index.php/De … iki:usrlib ) I ran

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

noticed that the only problem was with glib, and the modules folder, so I did a rm -rf /lib/* without doing a backup first. Is there a way to rebuild the contents of the /lib directory or do i have to reinstall? If there isn't my second question is: how to get a list of all the packages I have installed?

Strike0 · 2012-07-15 10:19:41

@mjb: you better put [ code ] tags around your output up there right away ... Please read issue 2 of the wiki again for your "No package owns .." errors. it is explicitly mentioned there. And you must uninstall ufw for upgrading.

Arch Linux

#26 2012-07-15 01:56:13

Re: glibc update refusing to proceed. File ownership problem

#27 2012-07-15 02:16:40

Re: glibc update refusing to proceed. File ownership problem

#28 2012-07-15 02:26:01

Re: glibc update refusing to proceed. File ownership problem

#29 2012-07-15 02:27:08

Re: glibc update refusing to proceed. File ownership problem

#30 2012-07-15 02:29:03

Re: glibc update refusing to proceed. File ownership problem

#31 2012-07-15 02:42:13

Re: glibc update refusing to proceed. File ownership problem

#32 2012-07-15 02:45:17

Re: glibc update refusing to proceed. File ownership problem

#33 2012-07-15 02:47:17

Re: glibc update refusing to proceed. File ownership problem

#34 2012-07-15 02:54:22

Re: glibc update refusing to proceed. File ownership problem

#35 2012-07-15 03:25:52

Re: glibc update refusing to proceed. File ownership problem

#36 2012-07-15 04:19:39

Re: glibc update refusing to proceed. File ownership problem

#37 2012-07-15 05:18:33

Re: glibc update refusing to proceed. File ownership problem

#38 2012-07-15 05:26:37

Re: glibc update refusing to proceed. File ownership problem

#39 2012-07-15 05:30:31

Re: glibc update refusing to proceed. File ownership problem

#40 2012-07-15 05:36:44

Re: glibc update refusing to proceed. File ownership problem

#41 2012-07-15 06:58:29

Re: glibc update refusing to proceed. File ownership problem

#42 2012-07-15 07:42:44

Re: glibc update refusing to proceed. File ownership problem

#43 2012-07-15 08:24:34

Re: glibc update refusing to proceed. File ownership problem

#44 2012-07-15 08:31:10

Re: glibc update refusing to proceed. File ownership problem

#45 2012-07-15 08:58:39

Re: glibc update refusing to proceed. File ownership problem

#46 2012-07-15 09:01:40

Re: glibc update refusing to proceed. File ownership problem

#47 2012-07-15 09:55:41

Re: glibc update refusing to proceed. File ownership problem

#48 2012-07-15 10:10:13

Re: glibc update refusing to proceed. File ownership problem

#49 2012-07-15 10:16:59

Re: glibc update refusing to proceed. File ownership problem

#50 2012-07-15 10:19:41

Re: glibc update refusing to proceed. File ownership problem

Board footer