You are not logged in.

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

fatboy
Member
From: India
Registered: 2012-03-17
Posts: 73

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

paulbarbee
Member
Registered: 2010-08-20
Posts: 24

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

Squiddles
Member
Registered: 2011-05-31
Posts: 73

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

Potomac
Member
Registered: 2011-12-25
Posts: 322

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

Squiddles
Member
Registered: 2011-05-31
Posts: 73

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

fatboy
Member
From: India
Registered: 2012-03-17
Posts: 73

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

shaurz
Member
From: Leeds, UK
Registered: 2004-02-02
Posts: 337
Website

Re: glibc update refusing to proceed. File ownership problem

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?

Offline

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

jasonwryan
Forum & Wiki Admin
From: .nz
Registered: 2009-05-09
Posts: 18,346
Website

Re: glibc update refusing to proceed. File ownership problem

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.


Arch + dwm   •   Mercurial repos  •   Github

Registered Linux User #482438

Offline

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

fatboy
Member
From: India
Registered: 2012-03-17
Posts: 73

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

shaurz
Member
From: Leeds, UK
Registered: 2004-02-02
Posts: 337
Website

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

shaurz
Member
From: Leeds, UK
Registered: 2004-02-02
Posts: 337
Website

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

Cluster_one
Member
Registered: 2012-06-23
Posts: 14

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

paulbarbee
Member
Registered: 2010-08-20
Posts: 24

Re: glibc update refusing to proceed. File ownership problem

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!

Offline

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

Zamboniman
Member
Registered: 2010-06-20
Posts: 15

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

swanson
Member
From: Sweden
Registered: 2011-02-05
Posts: 759

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

Cluster_one
Member
Registered: 2012-06-23
Posts: 14

Re: glibc update refusing to proceed. File ownership problem

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/

Offline

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

kalpik
Member
From: India
Registered: 2007-05-08
Posts: 163
Website

Re: glibc update refusing to proceed. File ownership problem

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! big_smile

Offline

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

TheImmortalPhoenix
Member
From: 127.0.0.1
Registered: 2011-08-13
Posts: 435

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

jasonwryan
Forum & Wiki Admin
From: .nz
Registered: 2009-05-09
Posts: 18,346
Website

Re: glibc update refusing to proceed. File ownership problem

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

Merging with the glibc stickied thread...


Arch + dwm   •   Mercurial repos  •   Github

Registered Linux User #482438

Offline

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

Miles28
Member
From: Spain
Registered: 2008-08-31
Posts: 77

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

jasonwryan
Forum & Wiki Admin
From: .nz
Registered: 2009-05-09
Posts: 18,346
Website

Re: glibc update refusing to proceed. File ownership problem

Read the rest of the wiki entry...

Merging with the stickied thread...


Arch + dwm   •   Mercurial repos  •   Github

Registered Linux User #482438

Offline

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

progandy
Member
Registered: 2012-05-17
Posts: 2,146

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

mjb
Member
From: Germany
Registered: 2012-01-28
Posts: 66

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

guest53290
Member
Registered: 2012-07-15
Posts: 1

Re: glibc update refusing to proceed. File ownership problem

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?

Offline

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

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: glibc update refusing to proceed. File ownership problem

@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.

Offline

Board footer

Powered by FluxBB