You are not logged in.

#101 2012-07-16 11:57:19

Vilius
Member
From: Dushanbe, Tajikistan
Registered: 2012-01-05
Posts: 26
Website

Re: glibc update refusing to proceed. File ownership problem

Allan wrote:

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

Ok. Here are the complete outputs:

$ find /lib -exec pacman -Qo -- {} +
error: cannot determine ownership of directory '/lib'
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libm.so.6 is owned by glibc 2.16.0-1
/lib/libdl-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_hesiod-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl.so.1 is owned by glibc 2.16.0-1
/lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
/lib/libc-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_compat-2.16.so is owned by glibc 2.16.0-1
/lib/libc.so.6 is owned by glibc 2.16.0-1
/lib/libnss_nisplus-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nis.so.2 is owned by glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_db-2.16.so is owned by glibc 2.16.0-1
/lib/libm-2.16.so is owned by glibc 2.16.0-1
/lib/libdl.so.2 is owned by glibc 2.16.0-1
/lib/librt-2.16.so is owned by glibc 2.16.0-1
/lib/libthread_db-1.0.so is owned by glibc 2.16.0-1
/lib/libresolv.so.2 is owned by glibc 2.16.0-1
/lib/ld-linux.so.2 is owned by lib32-glibc 2.15-10
/lib/ld-2.16.so is owned by glibc 2.16.0-1
/lib/libthread_db.so.1 is owned by glibc 2.16.0-1
/lib/libnss_files-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
/lib/libcidn-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_dns.so.2 is owned by glibc 2.16.0-1
/lib/libpthread-2.16.so is owned by glibc 2.16.0-1
/lib/librt.so.1 is owned by glibc 2.16.0-1
/lib/libnss_files.so.2 is owned by glibc 2.16.0-1
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.16.0-1
/lib/libnss_db.so.2 is owned by glibc 2.16.0-1
/lib/libnss_nisplus.so.2 is owned by glibc 2.16.0-1
/lib/libnss_compat.so.2 is owned by glibc 2.16.0-1
/lib/libpcprofile.so is owned by glibc 2.16.0-1
/lib/libutil.so.1 is owned by glibc 2.16.0-1
/lib/libutil-2.16.so is owned by glibc 2.16.0-1
/lib/libresolv-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl-2.16.so is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/libcrypt-2.16.so is owned by glibc 2.16.0-1
/lib/libpthread.so.0 is owned by glibc 2.16.0-1
/lib/libnss_nis-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_hesiod.so.2 is owned by glibc 2.16.0-1
/lib/libanl-2.16.so is owned by glibc 2.16.0-1
/lib/libcrypt.so.1 is owned by glibc 2.16.0-1
/lib/libSegFault.so is owned by glibc 2.16.0-1
$ grep '^lib/' /var/lib/pacman/local/*/files
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/ld-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/ld-linux-x86-64.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libBrokenLocale-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libBrokenLocale.so.1
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libSegFault.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libanl-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libanl.so.1
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libc-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libc.so.6
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libcidn-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libcidn.so.1
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libcrypt-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libcrypt.so.1
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libdl-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libdl.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libm-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libm.so.6
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libmemusage.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnsl-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnsl.so.1
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_compat-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_compat.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_db-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_db.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_dns-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_dns.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_files-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_files.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_hesiod-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_hesiod.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_nis-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_nis.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_nisplus-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libnss_nisplus.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libpcprofile.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libpthread-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libpthread.so.0
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libresolv-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libresolv.so.2
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/librt-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/librt.so.1
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libthread_db-1.0.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libthread_db.so.1
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libutil-2.16.so
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/libutil.so.1
/var/lib/pacman/local/lib32-glibc-2.15-10/files:lib/
/var/lib/pacman/local/lib32-glibc-2.15-10/files:lib/ld-linux.so.2

Offline

#102 2012-07-16 11:57:57

czubek
Banned
Registered: 2012-03-08
Posts: 141

Re: glibc update refusing to proceed. File ownership problem

I was using an Arch Linux version, (the name of which shall not be mentioned), and being less than a noob I destroyed my system. I couldn't re-install my old version because of its massive update so I switched back to Arch Linux.

A fresh install solved all the problems and I didn't have to contend with the glibc /lib update.

Offline

#103 2012-07-16 12:40:36

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: glibc update refusing to proceed. File ownership problem

Vilius wrote:
Allan wrote:

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

Ok. Here are the complete outputs:
<snip>


Re-enable [multilib] in pacman.conf.  Then do the ugrade (pacman -Syu --ignore glibc; pacman -Su).   Or if you really intended to get rid of the [multilib] repo, remove all packages from it...

Offline

#104 2012-07-16 12:43:17

enigmatichus
Member
Registered: 2011-12-23
Posts: 61

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.

Thank you, your detailed how-to saved me!!!


Luca

Arch Linux x86_64 | Dell XPS L702X | Intel core i7 2720QM | 8192MB RAM 1333 Mhz | Nvidia GeForce GT555M | 3D 1920x1080 LED

Offline

#105 2012-07-16 12:51:14

flako
Member
Registered: 2008-10-24
Posts: 56

Re: glibc update refusing to proceed. File ownership problem

I had some conflicts with /lib/modules and /lib/cpp after running pacman -Su

Following the instructions in the wiki I deleted the files in /lib/modules/ as they were all just old disowned archmodules.
Then I was left with the /lib/cpp dir, again running:

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

showed that it was owned by gcc, this was solved by simply removing gcc and all its dependencies, in my case

pacman -R gcc mcpp libtool xorg-xrdb xorg-server-utils

I could then perform the pacman -Su upgrade flawlessly and then install the packages I just had removed. I then proceeded to reboot without any issues. Just follow the entry in the wiki and you'll be set smile

Offline

#106 2012-07-16 12:56:06

Vilius
Member
From: Dushanbe, Tajikistan
Registered: 2012-01-05
Posts: 26
Website

Re: glibc update refusing to proceed. File ownership problem

Allan wrote:

Re-enable [multilib] in pacman.conf.  Then do the ugrade (pacman -Syu --ignore glibc; pacman -Su).

That did the trick, thanks.

Offline

#107 2012-07-16 14:05:42

eufex
Member
From: Finland
Registered: 2010-05-31
Posts: 3

Re: glibc update refusing to proceed. File ownership problem

Vilius wrote:
Allan wrote:

Re-enable [multilib] in pacman.conf.  Then do the ugrade (pacman -Syu --ignore glibc; pacman -Su).

That did the trick, thanks.

+1

Thank you, Allan! That was the missing information.

Offline

#108 2012-07-16 16:01:26

jwhipp
Member
Registered: 2012-01-20
Posts: 7

Re: glibc update refusing to proceed. File ownership problem

I was able to get passed this using the rm -rf /lib/modules method.

One thing though, I had to re-install my kernels *before* glibc would update.  Just removing /lib/modules still had pacman refusing to update glibc.  Once I re-installed my kernel, glibc updated with no problem.

Offline

#109 2012-07-16 17:07:25

I am Gianluca
Member
From: London, UK
Registered: 2011-05-22
Posts: 195

Re: glibc update refusing to proceed. File ownership problem

progandy wrote:
I am Gianluca wrote:
progandy wrote:

You have posted your find-output for /lib. So move everything back that is owned by glibc.
To get a working system again, a symlink from /lib/ld-linux.so.2 to /usr/lib/ld-2.16.so is probably enough, but then you will have errors when upgrading glibc. If you force the update then, it could work, but I don't know if that is a good idea.

Ok. Now the problem is how move everything back to /lib?

Use the first four steps from here to get a shell with read-write access https://bbs.archlinux.org/viewtopic.php … 1#p1127251

Thank you Progandy for your help.
I`m quite a noob here so probably my future questions will sound to you weird.

I`ve added the on the kernel line the `break=postmount` command, and remounted the root partion with writing permission with the command:

# mount -w /new_root/
mount: /dev/sda3 is already mounted or /new_root/ busy
/dev/sda3 is already mounted on /new_root
# cd new_root
# ls /usr/lib/

How can I check if I mounted correctly the root partition?
Anyway, if I check into the /usr/lib/ directory I couldn`t find files like libnss_dns-2.16.so that I`ve wrongly moved from /lib/ to /usr/lib/. I`m pretty sure to have moved them into the /usr/lib/ directory with a `Ctrl+X` and `Ctrl+V` combination.
Perhaps, have I mounted the partition wrongly?

Thank you for your time,

Gianluca

Last edited by I am Gianluca (2012-07-16 17:07:49)


Laptop: Acer Aspire S3 | Linux Mint Cinnamon 64-bit

Offline

#110 2012-07-16 17:28:11

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: glibc update refusing to proceed. File ownership problem

Remount is something like "mount -o remount,rw /new_root"
Then after you switched to new_root, do not add the root-slash to your paths. You want your paths relative to /new_root:
ls usr/lib
ln -s usr/lib lib


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#111 2012-07-16 18:40:25

I am Gianluca
Member
From: London, UK
Registered: 2011-05-22
Posts: 195

Re: glibc update refusing to proceed. File ownership problem

progandy wrote:

Remount is something like "mount -o remount,rw /new_root"
Then after you switched to new_root, do not add the root-slash to your paths. You want your paths relative to /new_root:
ls usr/lib
ln -s usr/lib lib

Ok, I'm following you. With your commands I've created the link between usr/lib and lib/.
At this point what I have to do? I'm still on the shell environment and cannot use 'sudo pacman -Su'.


Laptop: Acer Aspire S3 | Linux Mint Cinnamon 64-bit

Offline

#112 2012-07-16 18:58:24

gaougalos
Member
Registered: 2009-06-10
Posts: 7

Re: glibc update refusing to proceed. File ownership problem

i made a force update.
After that

1. Boot into GRUB and add "init=fakeinit" "break=postmount" to the line that starts with "kernel"
2. Wait until you get dropped into a root shell
3. Your root partition should be mounted read-only to '/new_root', remount with write permissions
4. Change to '/new_root' 
cd new_root

5. Remove 'lib' 
rm -Rf lib

6. Create a softlink from 'usr/lib' to 'lib' 
ln -s usr/lib lib

7. Reboot

and when i boot i take  /lib//libmount.so.1: version `MOUNT_2.20` not found

Offline

#113 2012-07-16 19:07:29

fpilee
Member
From: Windows 7
Registered: 2011-10-06
Posts: 104
Website

Re: glibc update refusing to proceed. File ownership problem

First that.

http://www.archlinux.org/news/the-lib-d … a-symlink/

And then issue two from there...
https://wiki.archlinux.org/index.php/De … iki:usrlib

so i deleted /lib  and the system is break XD.

te repair.
In my case. I just have in /lib glibc files and kernels olds, so to repair the problem i just boot in a livecd and  extracted /var/cache/pacman/pkg/glibc*1.tar.xz on /. And the system is working rigth now. Then i aplied pacman -Su and every goes fine.

Last edited by fpilee (2012-07-16 22:53:09)

Offline

#114 2012-07-16 19:08:26

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: glibc update refusing to proceed. File ownership problem

Merging with the glibc stickied thread...


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#115 2012-07-16 19:16:00

ephan
Member
Registered: 2011-11-02
Posts: 171

Re: glibc update refusing to proceed. File ownership problem

First of all, yes, I did read the guide.

However, I don't really understand what to do to all the files that I have on /lib. The guide says I can remove some files and move others to /usr/lib.

"Any files unowned by a package should either be deleted or moved to /usr/lib and any directories within /lib need deleted (after they are empty...)."

It doesn't clearly say if I should delete the files or move them.

So, what should I do, since I can't pacman -Su.

Useful? Maybe:

~> find /lib -exec pacman -Qo -- {} +
error: cannot determine ownership of directory '/lib'
/lib/libpcprofile.so is owned by glibc 2.16.0-1
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libnss_db.so.2 is owned by glibc 2.16.0-1
/lib/libnsl-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_files-2.16.so is owned by glibc 2.16.0-1
/lib/libm.so.6 is owned by glibc 2.16.0-1
/lib/libanl-2.16.so is owned by glibc 2.16.0-1
/lib/libutil-2.16.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
/lib/libresolv-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nisplus-2.16.so is owned by glibc 2.16.0-1
/lib/libutil.so.1 is owned by glibc 2.16.0-1
/lib/libnss_dns.so.2 is owned by glibc 2.16.0-1
/lib/libnss_nis.so.2 is owned by glibc 2.16.0-1
/lib/libnss_files.so.2 is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libnss_compat-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nis-2.16.so is owned by glibc 2.16.0-1
/lib/librt-2.16.so is owned by glibc 2.16.0-1
/lib/libcrypt-2.16.so is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/libnss_compat.so.2 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.2-ARCH'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.2-ARCH/kernel'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.2-ARCH/kernel/oss'
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_sblive.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_imux.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_madi.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_ymf7xx.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_via823x.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_cs4281.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_via97.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_trident.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_cs461x.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_fmedia.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_usb.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_audioloop.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_solo.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_hdaudio.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/osscore.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_geode.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_audigyls.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_envy24.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_midiloop.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_sbxfi.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_midimix.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_ich.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_emu10k1x.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_digi96.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_atiaudio.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_sbpci.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_audiopci.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_cmpci.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_ali5455.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_cmi878x.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_userdev.ko
error: No package owns /lib/modules/extramodules-3.2-ARCH/kernel/oss/oss_envy24ht.ko
error: cannot determine ownership of directory '/lib/modules/3.0-ARCH'
error: cannot determine ownership of directory '/lib/modules/3.2.6-2-ARCH'
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.builtin.bin
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.alias
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.alias.bin
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.devname
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.dep.bin
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.dep
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.symbols.bin
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.softdep
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.symbols
error: cannot determine ownership of directory '/lib/modules/extramodules-3.4-ARCH'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.4-ARCH/kernel'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.4-ARCH/kernel/oss'
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_sblive.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_imux.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_madi.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_ymf7xx.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_via823x.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_cs4281.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_via97.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_trident.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_cs461x.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_fmedia.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_usb.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_audioloop.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_solo.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_hdaudio.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/osscore.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_geode.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_audigyls.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_envy24.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_midiloop.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_sbxfi.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_midimix.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_ich.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_emu10k1x.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_digi96.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_atiaudio.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_sbpci.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_audiopci.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_cmpci.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_ali5455.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_cmi878x.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_userdev.ko
error: No package owns /lib/modules/extramodules-3.4-ARCH/kernel/oss/oss_envy24ht.ko
/lib/libnss_hesiod-2.16.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
/lib/libnsl.so.1 is owned by glibc 2.16.0-1
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.16.0-1
/lib/libSegFault.so is owned by glibc 2.16.0-1
/lib/libcidn-2.16.so is owned by glibc 2.16.0-1
/lib/ld-2.16.so is owned by glibc 2.16.0-1
/lib/librt.so.1 is owned by glibc 2.16.0-1
/lib/libpthread-2.16.so is owned by glibc 2.16.0-1
/lib/libpthread.so.0 is owned by glibc 2.16.0-1
/lib/libnss_hesiod.so.2 is owned by glibc 2.16.0-1
/lib/libcrypt.so.1 is owned by glibc 2.16.0-1
/lib/libc.so.6 is owned by glibc 2.16.0-1
/lib/libnss_db-2.16.so is owned by glibc 2.16.0-1
/lib/libthread_db.so.1 is owned by glibc 2.16.0-1
/lib/libm-2.16.so is owned by glibc 2.16.0-1
/lib/libthread_db-1.0.so is owned by glibc 2.16.0-1
/lib/libresolv.so.2 is owned by glibc 2.16.0-1
/lib/libc-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nisplus.so.2 is owned by glibc 2.16.0-1
/lib/libdl-2.16.so is owned by glibc 2.16.0-1
/lib/libdl.so.2 is owned by glibc 2.16.0-1
/lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
exit 1
~> 

Offline

#116 2012-07-16 19:33:51

Terminator
Member
From: Belgium
Registered: 2012-05-07
Posts: 265

Re: glibc update refusing to proceed. File ownership problem

The unowned files are modules for kernel 3.2. Since we currently have kernel 3.4.4-3, you can safely remove them.

EDIT: I see there are also modules for this kernel in the list. Since they are in a map called oss, I expect they have something to do with sound. I would probably move them to e.g. my home directory. If the system fails on a reboot, I would move them back from a live disc (or in my case from ubuntu).

Last edited by Terminator (2012-07-16 19:42:11)

Offline

#117 2012-07-16 19:39:28

amsri
Member
Registered: 2011-06-17
Posts: 48

Re: glibc update refusing to proceed. File ownership problem

NOTE: I AM NOT SUPPORTING THE GENERAL USE OF --force OPTION. I HAVE USED --force FOR THE FIRST TIME SINCE I STARTED USING ARCH SINCE EVERYTHING ELSE WAS NOT WORKING. THE METHOD BELOW WORKED FOR ME IN MY CIRCUMSTANCES.

After reading all the posts about borking the system I tried to be too optimistic and followed the guidelines given in wiki. Whatever way I tried the glibc was not getting updated. Then I carefully looked at the contents of /lib and /usr/lib to confirm all the modules etc needed are in /usr/lib. When I ran the command:

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

it only complained by ownership by glibc and all the culprits were in in root /lib directory and not in modules etc. After giving a lot of thought and trying methods suggested in the forums I did the following (Note: there were only two things left in my /lib - the modules directory and glibc related stuff, including symlinks, in the root /lib directory):

1) I renamed the the modules directory in /lib to modules .bak

2) After renaming as in 1 moved all the stuff from /lib to /usr/lib

mv /lib/* /usr/lib/

3) then

mv /lib /lib-old

4.

/usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib 

5) lastly with the understanding that everything now is in /usr/lib and there is already a symlink from /usr/lib to /lib I executed:

pacman -S glibc lib32-glibc --force

Note: I am using multilib version of gcc as I need it for 32 bit programs.
the command in 5 went through smoothly. I then rebooted and Wooo!!! Hooo!!! I have a working system. I did several reboots and shutdowns and no problems detected so far. Hope everything is OK.

I just shared my steps in hope that it may help someone.

Offline

#118 2012-07-16 19:45:27

DSpider
Member
From: Romania
Registered: 2009-08-23
Posts: 2,273

Re: glibc update refusing to proceed. File ownership problem

Nope. Lowecase thread.

Last edited by DSpider (2012-07-16 21:37:53)


"How to Succeed with Linux"

I have made a personal commitment not to reply in topics that start with a lowercase letter. Proper grammar and punctuation is a sign of respect, and if you do not show any, you will NOT receive any help (at least not from me).

Offline

#119 2012-07-16 19:49:43

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: glibc update refusing to proceed. File ownership problem

Merging with glibc stickied thread...


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#120 2012-07-16 21:10:39

sinojos
Member
Registered: 2011-06-03
Posts: 8

Re: glibc update refusing to proceed. File ownership problem

I was following the instructions in this document.
https://wiki.archlinux.org/index.php/De … iki:usrlib

Since there were files left in /lib - I copy/backed-up the complete /lib folder - just in case- Since I had the complete folder backed up - I used rm -rf * FROM WITHIN /lib - ALL Files on the hardrive were removed. Some sort of loop happened that removed all files on the hardrive.  That removal command should have only removed the files within the folder /lib.

This sort of a thing happening during an update process is very disconcerting. As this is my monitoring server in my office for all my webservers and mail servers. This will cost my me a lot of work to rebuild this server, worst of all being the timing.

The Arch Linux team needs to take precautions that such an event does not happen in the future. Why removing files inside the /lib folder removes files and folders elsewhere on the hardrive is unknown to me. Perhaps something to do with the first update failing and the attempt to make the /lib folder a link.

With nearly 20 years of Linux use, I have never experienced anything like this. It is very disappointing to say the least, as I also had raided drives with business backups also attached to this machine, all of which have been lost. Fortunately I keep the most important stuff also on a third machine and a remote location, nevertheless it is a great loss as some of the less important stuff will still take time to reproduce or is simply lost for good.

This is the only Arch Linux machine I have used in a business situation, only one as I have not trusted Arch Linux, it appears as though my fears have been sound, and will seriously reconsider using Arch Linux in a business environment in the future.

Offline

#121 2012-07-16 21:13:36

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: glibc update refusing to proceed. File ownership problem

Merging with the stickied glibc thread...

Also, I don't recall seeing any advice to rm -rf lib/


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#122 2012-07-16 21:52:42

ephan
Member
Registered: 2011-11-02
Posts: 171

Re: glibc update refusing to proceed. File ownership problem

I still don't get something... What to do with the files in /lib? Delete them? Move them to /usr/lib?

How can we know?

I really appreciate the Wiki guide, but it's not clear about that. Thank you.

Offline

#123 2012-07-16 21:59:04

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: glibc update refusing to proceed. File ownership problem

Arch Wiki wrote:

If any package apart from glibc is listed as owning a file, that package needs to be updated to install its files in /usr/lib. Any files unowned by a package should either be deleted or moved to /usr/lib and any directories within /lib need deleted (after they are empty...).

Where "Any files unowned by a package" means "any files unowned by a package other than glibc..."

Once you have worked through that, the only files left should be owned by glibc -- that's when you pacman -Su.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#124 2012-07-16 23:41:07

Jindur
Member
Registered: 2011-09-29
Posts: 184

Re: glibc update refusing to proceed. File ownership problem

I just tried to upgrade my system once again and got an error:

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

So i just did

sudo pacman -Syu --ignore glibc

and afterwards

pacman -Syu

. But that gave me the same error. So instead I thought ok, of course /lib exists, as it should. So I did a

sudo pacman -S glibc --force

to update glibc anyway. The problem is that pacman now gave a new error

(1/1) upgrading glibc                                                                                        [################################################################] 100%
error: extract: not overwriting dir with file lib
error: problem occurred while upgrading glibc
call to execv failed (No such file or directory)
error: command failed to execute correctly
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

and the result is that suddenly I cannot type any commands or start any applications anymore.
For example

$ ls
bash: /bin/ls: No such file or directory

Basically it seems whatever I try to type apart from 'cd' command gives a "bash: /bin/<thecommand>: No such file or directory" error now.
Help please. Also I must say that out of the last 5 times I did a pacman -Syu there were some sort of bad problems like this (although this seems the worst so far) 3 times ouf of those 5. Maybe pacman could somehow be replaced by something that works better (think aptitude - worked 100% of the time)?

Last edited by Jindur (2012-07-16 23:43:54)

Offline

#125 2012-07-16 23:45:28

skunktrader
Member
From: Brisbane, Australia
Registered: 2010-02-14
Posts: 1,538

Re: glibc update refusing to proceed. File ownership problem

Which part of "Never use --force during this update." did you not understand?
http://www.archlinux.org/news/the-lib-d … a-symlink/

Offline

Board footer

Powered by FluxBB