You are not logged in.

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

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,740

Re: glibc update refusing to proceed. File ownership problem

nomorewindows wrote:

He's not OP!

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

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.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

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

LB06
Member
From: The Netherlands
Registered: 2003-10-29
Posts: 435

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

perbh
Member
From: Republic of Texas
Registered: 2005-03-04
Posts: 765

Re: glibc update refusing to proceed. File ownership problem

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

Offline

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

fsckd
Forum Fellow
Registered: 2009-06-15
Posts: 4,173

Re: glibc update refusing to proceed. File ownership problem

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


aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies

Offline

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

perbh
Member
From: Republic of Texas
Registered: 2005-03-04
Posts: 765

Re: glibc update refusing to proceed. File ownership problem

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

Offline

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

perbh
Member
From: Republic of Texas
Registered: 2005-03-04
Posts: 765

Re: glibc update refusing to proceed. File ownership problem

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

Offline

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

Palace
Member
Registered: 2012-08-01
Posts: 5

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.


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!

Offline

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

fsckd
Forum Fellow
Registered: 2009-06-15
Posts: 4,173

Re: glibc update refusing to proceed. File ownership problem

perbh wrote:

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

That makes sense. smile

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.


aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies

Offline

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

Barrucadu
Member
From: York, England
Registered: 2008-03-30
Posts: 1,158
Website

Re: glibc update refusing to proceed. File ownership problem

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

Offline

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

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

Re: glibc update refusing to proceed. File ownership problem

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.

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

Offline

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

MickeyKnox
Member
Registered: 2010-02-27
Posts: 169

Re: glibc update refusing to proceed. File ownership problem

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?

Offline

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

MickeyKnox
Member
Registered: 2010-02-27
Posts: 169

Re: glibc update refusing to proceed. File ownership problem

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

What now?

Offline

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

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: glibc update refusing to proceed. File ownership problem

@I am Gianluca

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


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

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

Palace
Member
Registered: 2012-08-01
Posts: 5

Re: glibc update refusing to proceed. File ownership problem

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

Offline

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

Palace
Member
Registered: 2012-08-01
Posts: 5

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

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

Re: glibc update refusing to proceed. File ownership problem

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)


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

Offline

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

Barrucadu
Member
From: York, England
Registered: 2008-03-30
Posts: 1,158
Website

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

Palace
Member
Registered: 2012-08-01
Posts: 5

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: glibc update refusing to proceed. File ownership problem

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


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

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

MickeyKnox
Member
Registered: 2010-02-27
Posts: 169

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

dave00
Member
Registered: 2010-01-03
Posts: 24

Re: glibc update refusing to proceed. File ownership problem

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)

Offline

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

verduler
Member
Registered: 2011-09-27
Posts: 9

Re: glibc update refusing to proceed. File ownership problem

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!

Offline

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

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: glibc update refusing to proceed. File ownership problem

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.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

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

verduler
Member
Registered: 2011-09-27
Posts: 9

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

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

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

Re: glibc update refusing to proceed. File ownership problem

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.

Offline

Board footer

Powered by FluxBB