glibc update refusing to proceed. File ownership problem

nomorewindows · 2012-07-19 23:05:33

I am Gianluca wrote:

nomorewindows wrote:

How did you do that?

This is the story of my glibc update: link
After this I fix my system following the advice of progandy: link

and

# rm -Rf lib
# ln -s usr/lib lib

So, I rebooted and open a terminal session:

# sudo -Syu --ignore glibc
# sudo -Su
Password: 
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...

Targets (1): glibc-2.16.0-2

Total Installed Size:   33.94 MiB
Net Upgrade Size:       0.00 MiB

Proceed with installation? [Y/n] y
(1/1) checking package integrity                   [######################] 100%
(1/1) loading package files                        [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
glibc: /usr/lib/ld-2.16.so exists in filesystem
glibc: /usr/lib/ld-linux.so.2 exists in filesystem
glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem
glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
glibc: /usr/lib/libSegFault.so exists in filesystem
glibc: /usr/lib/libanl-2.16.so exists in filesystem
glibc: /usr/lib/libanl.so.1 exists in filesystem
glibc: /usr/lib/libc-2.16.so exists in filesystem
glibc: /usr/lib/libc.so.6 exists in filesystem
glibc: /usr/lib/libcidn-2.16.so exists in filesystem
glibc: /usr/lib/libcidn.so.1 exists in filesystem
glibc: /usr/lib/libcrypt-2.16.so exists in filesystem
glibc: /usr/lib/libcrypt.so.1 exists in filesystem
glibc: /usr/lib/libdl-2.16.so exists in filesystem
glibc: /usr/lib/libdl.so.2 exists in filesystem
glibc: /usr/lib/libm-2.16.so exists in filesystem
glibc: /usr/lib/libm.so.6 exists in filesystem
glibc: /usr/lib/libmemusage.so exists in filesystem
glibc: /usr/lib/libnsl-2.16.so exists in filesystem
glibc: /usr/lib/libnsl.so.1 exists in filesystem
glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem
glibc: /usr/lib/libnss_compat.so.2 exists in filesystem
glibc: /usr/lib/libnss_db-2.16.so exists in filesystem
glibc: /usr/lib/libnss_db.so.2 exists in filesystem
glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem
glibc: /usr/lib/libnss_dns.so.2 exists in filesystem
glibc: /usr/lib/libnss_files-2.16.so exists in filesystem
glibc: /usr/lib/libnss_files.so.2 exists in filesystem
glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem
glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem
glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem
glibc: /usr/lib/libnss_nis.so.2 exists in filesystem
glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem
glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem
glibc: /usr/lib/libpcprofile.so exists in filesystem
glibc: /usr/lib/libpthread-2.16.so exists in filesystem
glibc: /usr/lib/libpthread.so.0 exists in filesystem
glibc: /usr/lib/libresolv-2.16.so exists in filesystem
glibc: /usr/lib/libresolv.so.2 exists in filesystem
glibc: /usr/lib/librt-2.16.so exists in filesystem
glibc: /usr/lib/librt.so.1 exists in filesystem
glibc: /usr/lib/libthread_db-1.0.so exists in filesystem
glibc: /usr/lib/libthread_db.so.1 exists in filesystem
glibc: /usr/lib/libutil-2.16.so exists in filesystem
glibc: /usr/lib/libutil.so.1 exists in filesystem
Errors occurred, no packages were upgraded.

You put the symlink in before upgrading and then deleted everything.

cfr · 2012-07-19 23:24:54

@Gianluca,
Did you install the updated glibc or the older one by untarring the package rather than using pacman as part of the recovery process? If so, pacman won't know those files belong to glibc. What does

pacman -Qo /usr/lib/ld-2.16.so

give?

If pacman believes those files are unowned, you may need to reinstall the current version of glibc with pacman. You may need to force this. (NOT the upgrade itself.) For example, IF you untarred /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz in order to recover, you'd do something like pacman -U --force /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz. Then you'd do pacman -Su. But ONLY force the REinstallation of the version you ALREADY installed.

Or wait and somebody more authoritative will say what to do...

Last edited by cfr (2012-07-19 23:26:25)

I am Gianluca · 2012-07-19 23:35:54

cfr wrote:

@Gianluca,
Did you install the updated glibc or the older one by untarring the package rather than using pacman as part of the recovery process? If so, pacman won't know those files belong to glibc. What does
pacman -Qo /usr/lib/ld-2.16.so
give?
If pacman believes those files are unowned, you may need to reinstall the current version of glibc with pacman. You may need to force this. (NOT the upgrade itself.) For example, IF you untarred /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz in order to recover, you'd do something like pacman -U --force /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz. Then you'd do pacman -Su. But ONLY force the REinstallation of the version you ALREADY installed.
Or wait and somebody more authoritative will say what to do...

Hi cfr,

first of all thank you for your reply.
The answer of the command you've asked me is:

$ pacman -Qo /usr/lib/ld-2.16.so
/usr/lib/ld-2.16.so is owned by glibc 2.16.0-1

cfr · 2012-07-19 23:51:00

Oh, I see. So you basically created the symlink too soon? That is, you created lib as a link to usr/lib and then reinstalled glibc version 2.16.0-1? I can't see how else those files would have ended up under usr/lib rather than lib. So basically, files which should be under lib are under usr/lib. But I still don't quite see why pacman can't update glibc in that case - if all the files are owned by glibc... presumably they're in the wrong place and that's enough to block things.

One thing you could do would be:
- boot from the live install media as before
- uninstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz
- remove the symlink lib
- reinstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz
- reboot
- upgrade

I am Gianluca · 2012-07-20 09:40:09

cfr wrote:

Oh, I see. So you basically created the symlink too soon? That is, you created lib as a link to usr/lib and then reinstalled glibc version 2.16.0-1? I can't see how else those files would have ended up under usr/lib rather than lib. So basically, files which should be under lib are under usr/lib. But I still don't quite see why pacman can't update glibc in that case - if all the files are owned by glibc... presumably they're in the wrong place and that's enough to block things.
One thing you could do would be:
- boot from the live install media as before
- uninstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz
- remove the symlink lib
- reinstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz
- reboot
- upgrade

I have another time problems during the boot process. After having logged in, and selected to start an XFCE4 session through CDM, it returns me this error:

Waiting for ConsoleKit to register X session (timeout 30s)... Timed out, giving up.
Check to see if you are wrapping your session with ck-launch-session or increase timeout.

I'm pretty sure that is not a CDM error, because I booted with it numerous times without any problem at all. So I suppose that's something related with /lib/, /usr/lib/ and glibc.

By the way, when you say 'uninstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz', do you mean to use the following command?

rm uninstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz

Remember that I'm in an environment in which I cannot use sudo, nor pacman, etc if I'll repeat the procedure that progandy taught me (first link on my previous post).
So, I can remove the symlink lib through the command

unlink lib

But I don't know how to reinstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz, because in this environment I don't have pacman.

Apologise for the probably stupid questions that I ask you but I'm still a noob, even after one year of ArchLinux use. I'm trying to learn as much as I can, but isn't so fast.

Yagi858 · 2012-07-20 10:15:22

Do someone fix this orrible glibc upgrade ? Or simply write the official solution on wiki ? I followed the note the wiki and I fucked the system. Fortunately I had backup the old /lib so replaced and the system resume to live. Please put in evidence this is a critical update.

Last edited by Yagi858 (2012-07-20 10:15:33)

progandy · 2012-07-20 10:36:38

But I don't know how to reinstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz, because in this environment I don't have pacman.

You have "tar -xvJf package.tar.xz lib" to extract the lib-folder

Barrucadu · 2012-07-20 11:03:54

Yagi858 wrote:

Do someone fix this orrible glibc upgrade ? Or simply write the official solution on wiki ? I followed the note the wiki and I fucked the system. Fortunately I had backup the old /lib so replaced and the system resume to live. Please put in evidence this is a critical update.

The wiki has the official solution, and it works if you follow it to the letter.

czubek · 2012-07-20 11:32:50

I trashed one computer but managed to succeed on another. If anything this at least proves an idiot can do the upgrade.

Well, maybe it just pure dumb luck.

I am Gianluca · 2012-07-20 12:31:12

progandy wrote:

But I don't know how to reinstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz, because in this environment I don't have pacman.
You have "tar -xvJf package.tar.xz lib" to extract the lib-folder

I've done:

# mount -o remount,rw /new_root
# cd new_root
# rm var/cache/pacman/pkg/glibc-2.16.0-1-i686.pkg.tar.xz
# rm lib 
# tar -xvJf var/cache/pacman/pkg/glibc-2.16.0-2-i686.pkg.tar.xz lib
sh: tar: not found

I don't understand one thing, cfr told me to uninstall var/cache/pacman/pkg/glibc-2.16.0-1-i686.pkg.tar.xz. If I do it I wouldn't be able to find it 2 steps later for install the package another time. Instead, I have in the same directory var/cache/pacman/pkg/glibc-2.16.0-2-i686.pkg.tar.xz. I should install it. Am I wrong?

What a confusion.
I genuinely hope to not have compromised my system forever.

Anyway, thank you for your time another time.
Gianluca

nomorewindows · 2012-07-20 12:48:14

I am Gianluca wrote:

progandy wrote:
But I don't know how to reinstall /var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz, because in this environment I don't have pacman.
You have "tar -xvJf package.tar.xz lib" to extract the lib-folder
I've done:
# mount -o remount,rw /new_root
# cd new_root
# rm var/cache/pacman/pkg/glibc-2.16.0-1-i686.pkg.tar.xz
# rm lib 
# tar -xvJf var/cache/pacman/pkg/glibc-2.16.0-2-i686.pkg.tar.xz lib
sh: tar: not found
I don't understand one thing, cfr told me to uninstall var/cache/pacman/pkg/glibc-2.16.0-1-i686.pkg.tar.xz. If I do it I wouldn't be able to find it 2 steps later for install the package another time. Instead, I have in the same directory var/cache/pacman/pkg/glibc-2.16.0-2-i686.pkg.tar.xz. I should install it. Am I wrong?
What a confusion.
I genuinely hope to not have compromised my system forever.
Anyway, thank you for your time another time.
Gianluca

Tar for the fact "of it being a nightmare" isn't included with your kernel and/or initramfs.
If you can mount your /usr or / as it were, you might be able to get tar and probably be in good shape.
You may be able to use unxz on the package, I think it is possibly in the initramfs.

You didn't really have any need to delete the glibc-2.16-0.1 package, and by installing glibc-2.16.0-2, you are in effect uninstalling glibc-2.16.0-1.
Uninstalling the glibc-2.16.0-1 may or may not be necessary, if the files are going to be written over by the tar/unxz function.
The package database will think that glibc-2.16.0-1 is still installed, and the next time you run pacman it will install glibc-2.16.0-2 over it, and then things will be okay.

As far as untar/unxz on the initramfs lib will send it to the initramfs lib, and possibly not the one on new_root where you are expecting, so it would be new_root/lib that it needs to go. I also don't see what partition was actually mounted that goes with the intended partition.

Last edited by nomorewindows (2012-07-20 12:53:22)

I am Gianluca · 2012-07-20 13:02:37

nomorewindows wrote:

I am Gianluca wrote:
progandy wrote:
You have "tar -xvJf package.tar.xz lib" to extract the lib-folder
I've done:
# mount -o remount,rw /new_root
# cd new_root
# rm var/cache/pacman/pkg/glibc-2.16.0-1-i686.pkg.tar.xz
# rm lib 
# tar -xvJf var/cache/pacman/pkg/glibc-2.16.0-2-i686.pkg.tar.xz lib
sh: tar: not found
I don't understand one thing, cfr told me to uninstall var/cache/pacman/pkg/glibc-2.16.0-1-i686.pkg.tar.xz. If I do it I wouldn't be able to find it 2 steps later for install the package another time. Instead, I have in the same directory var/cache/pacman/pkg/glibc-2.16.0-2-i686.pkg.tar.xz. I should install it. Am I wrong?
What a confusion.
I genuinely hope to not have compromised my system forever.
Anyway, thank you for your time another time.
Gianluca
Tar for the fact "of it being a nightmare" isn't included with your kernel and/or initramfs.
If you can mount your /usr or / as it were, you might be able to get tar and probably be in good shape.
You may be able to use unxz on the package, I think it is possibly in the initramfs.
You didn't really have any need to delete the glibc-2.16-0.1 package, and by installing glibc-2.16.0-2, you are in effect uninstalling glibc-2.16.0-1.
Uninstalling the glibc-2.16.0-1 may or may not be necessary, if the files are going to be written over by the tar/unxz function.
The package database will think that glibc-2.16.0-1 is still installed, and the next time you run pacman it will install glibc-2.16.0-2 over it, and then things will be okay.
As far as untar/unxz on the initramfs lib will send it to the initramfs lib, and possibly not the one on new_root where you are expecting, so it would be new_root/lib that it needs to go.

Should I run the following command?

# unxz var/cache/pacman/pkg/glibc-2.16.0-2-i686.pkg.tar.xz new_root/lib

After it reboot and run:

# sudo pacman -Syu

Have I understand correctly?

nomorewindows · 2012-07-20 16:55:14

First, are you running this from busybox or actually booting your system?

Hmm...unxz isn't in the initramfs, so unless there is xz compression support in the kernel itself, it would still be safe to try. I know for sure tar isn't available. Is your kernel/initramfs even have anything in the /lib directory? The newly built kernel with all of the glibc has been moved into /usr/lib.

The busybox method may not work too good, the LiveCD/USB/PXE may unfortunately be the only solution out of this. Even an old one with xz support either through tar or unxz/xz will get you something. You don't have to have the latest archiso to recover your system.

How are you getting the package file without mounting your /boot and root filesystem(s)?
Obviously you are using something to post on the bbs. Whatever you're using, could aid you in producing a LiveCD/USB,etc. if needed.

Last edited by nomorewindows (2012-07-20 17:31:07)

thatnewyorker · 2012-07-20 17:36:49

So whats with this retarded issue? Are the devs smoking crack?

Psykorgasm · 2012-07-20 17:43:41

thatnewyorker wrote:

So whats with this retarded issue? Are the devs smoking crack?

I think the better question would be, are some of the users smoking crack? The user creates the problem for themselves (maybe not in some very rare cases?).
Also, show a little respect.

thatnewyorker · 2012-07-20 18:54:17

Psykorgasm wrote:

thatnewyorker wrote:
So whats with this retarded issue? Are the devs smoking crack?
I think the better question would be, are some of the users smoking crack? The user creates the problem for themselves (maybe not in some very rare cases?).
Also, show a little respect.

Ummm no, not in this case. When your system is refusing to update and all you did was use the standard updating procedure and nothing fancy then the fault lies with the those maintaining the software, not the user.

cabutan · 2012-07-20 19:36:53

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.

Gotta thank you for this post. Couldnt be written better..THANKS!! I struggle for days. Perhaps, this is what the wiki should have honestly... THANKS!

webmasteryoda · 2012-07-20 21:46:15

Any help plz?

$ find /lib -exec pacman -Qo -- {} +
error: cannot determine ownership of directory '/lib'
/lib/libnss_db-2.16.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
/lib/ld-lsb.so.3 is owned by ld-lsb 3-3
/lib/libnss_dns.so.2 is owned by glibc 2.16.0-1
/lib/libcrypt.so.1 is owned by glibc 2.16.0-1
/lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
/lib/libpthread-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/ld-2.16.so is owned by glibc 2.16.0-1
/lib/libutil.so.1 is owned by glibc 2.16.0-1
/lib/libc.so.6 is owned by glibc 2.16.0-1
/lib/libresolv.so.2 is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libSegFault.so is owned by glibc 2.16.0-1
/lib/libnss_nis.so.2 is owned by glibc 2.16.0-1
/lib/libnss_hesiod.so.2 is owned by glibc 2.16.0-1
/lib/libnsl-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/libcrypt-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl.so.1 is owned by glibc 2.16.0-1
/lib/libthread_db.so.1 is owned by glibc 2.16.0-1
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libdl-2.16.so is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/libpthread.so.0 is owned by glibc 2.16.0-1
/lib/ld-linux.so.2 is owned by glibc 2.16.0-1
/lib/libm-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/libanl-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_nisplus-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/libnss_files-2.16.so is owned by glibc 2.16.0-1
/lib/libpcprofile.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
/lib/libdl.so.2 is owned by glibc 2.16.0-1
/lib/libm.so.6 is owned by glibc 2.16.0-1
/lib/libthread_db-1.0.so 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/libnss_files.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_nis-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/libnss_db.so.2 is owned by glibc 2.16.0-1
/lib/libnss_compat.so.2 is owned by glibc 2.16.0-1

What do I have to do?

nomorewindows · 2012-07-20 22:14:46

webmasteryoda wrote:

Any help plz?

$ find /lib -exec pacman -Qo -- {} +
error: cannot determine ownership of directory '/lib'
/lib/libnss_db-2.16.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
/lib/ld-lsb.so.3 is owned by ld-lsb 3-3
/lib/libnss_dns.so.2 is owned by glibc 2.16.0-1
/lib/libcrypt.so.1 is owned by glibc 2.16.0-1
/lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
/lib/libpthread-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/ld-2.16.so is owned by glibc 2.16.0-1
/lib/libutil.so.1 is owned by glibc 2.16.0-1
/lib/libc.so.6 is owned by glibc 2.16.0-1
/lib/libresolv.so.2 is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libSegFault.so is owned by glibc 2.16.0-1
/lib/libnss_nis.so.2 is owned by glibc 2.16.0-1
/lib/libnss_hesiod.so.2 is owned by glibc 2.16.0-1
/lib/libnsl-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/libcrypt-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl.so.1 is owned by glibc 2.16.0-1
/lib/libthread_db.so.1 is owned by glibc 2.16.0-1
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libdl-2.16.so is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/libpthread.so.0 is owned by glibc 2.16.0-1
/lib/ld-linux.so.2 is owned by glibc 2.16.0-1
/lib/libm-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/libanl-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_nisplus-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/libnss_files-2.16.so is owned by glibc 2.16.0-1
/lib/libpcprofile.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
/lib/libdl.so.2 is owned by glibc 2.16.0-1
/lib/libm.so.6 is owned by glibc 2.16.0-1
/lib/libthread_db-1.0.so 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/libnss_files.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_nis-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/libnss_db.so.2 is owned by glibc 2.16.0-1
/lib/libnss_compat.so.2 is owned by glibc 2.16.0-1

What do I have to do?

All of these files are owned by glibc, the same package that is getting ready to replace these files.
Have you tried pacman -Su is that where you're at?

webmasteryoda · 2012-07-20 22:17:33

Nope. This one isnt. Look again.

/lib/ld-lsb.so.3 is owned by ld-lsb 3-3

So, what do I have to do with this file? I tried to move it to another directory, but that didnt solved my problem.

pacman -Su gives me:

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

Nasenbaer · 2012-07-20 22:24:34

Hi,
I have a huge problem with my arch linux system (amd64). I upgraded my packages and glibc had a conflict, therefore I tried to upgrade it alone. So I did

$ pacman -Su glibc

and got the message that it can't be updated, because /lib already exists. So i thought "yeah I know that /lib exists, whatever .." and did

$ pacman -Suf glibc

and the update went fine I thought. But since that time I can not run any command. All daemons, which where already up, were still working but I can not run a command and can't connect via ssh etc.
So I hard-resetted the system and tried to boot arch linux again. Now I get a kernel panic because /sbin/init wasn't found. The problem is, that init is still there (checked it using a rescue-CD).

Any hints how I can proceed without having to backup the system and every config file by hand and reinstalling arch?

jasonwryan · 2012-07-20 22:26:40

webmasteryoda wrote:

Nope. This one isnt. Look again.
/lib/ld-lsb.so.3 is owned by ld-lsb 3-3
So, what do I have to do with this file? I tried to move it to another directory, but that didnt solved my problem.

It's an AUR package. Unistall it, finish the upgrade and then rebuild it.

Nasenbaer · 2012-07-20 22:27:53

Oops just saw that the glibc upgrade conflict is currently a common problem. But as I already did/forced it - what can I do now? Simply a user rights problem of /lib?

Isola · 2012-07-20 22:29:16

First of all: Don't use --force!

Second: Read this for possible solutions
https://wiki.archlinux.org/index.php/De … iki:usrlib

And third: Setup a RSS reader so you don't miss those important announcements in the future!
http://www.archlinux.org/news/the-lib-d … a-symlink/

jasonwryan · 2012-07-20 22:32:40

Merging with the glibc stickied thread...

Arch Linux

#226 2012-07-19 23:05:33

Re: glibc update refusing to proceed. File ownership problem

#227 2012-07-19 23:24:54

Re: glibc update refusing to proceed. File ownership problem

#228 2012-07-19 23:35:54

Re: glibc update refusing to proceed. File ownership problem

#229 2012-07-19 23:51:00

Re: glibc update refusing to proceed. File ownership problem

#230 2012-07-20 09:40:09

Re: glibc update refusing to proceed. File ownership problem

#231 2012-07-20 10:15:22

Re: glibc update refusing to proceed. File ownership problem

#232 2012-07-20 10:36:38

Re: glibc update refusing to proceed. File ownership problem

#233 2012-07-20 11:03:54

Re: glibc update refusing to proceed. File ownership problem

#234 2012-07-20 11:32:50

Re: glibc update refusing to proceed. File ownership problem

#235 2012-07-20 12:31:12

Re: glibc update refusing to proceed. File ownership problem

#236 2012-07-20 12:48:14

Re: glibc update refusing to proceed. File ownership problem

#237 2012-07-20 13:02:37

Re: glibc update refusing to proceed. File ownership problem

#238 2012-07-20 16:55:14

Re: glibc update refusing to proceed. File ownership problem

#239 2012-07-20 17:36:49

Re: glibc update refusing to proceed. File ownership problem

#240 2012-07-20 17:43:41

Re: glibc update refusing to proceed. File ownership problem

#241 2012-07-20 18:54:17

Re: glibc update refusing to proceed. File ownership problem

#242 2012-07-20 19:36:53

Re: glibc update refusing to proceed. File ownership problem

#243 2012-07-20 21:46:15

Re: glibc update refusing to proceed. File ownership problem

#244 2012-07-20 22:14:46

Re: glibc update refusing to proceed. File ownership problem

#245 2012-07-20 22:17:33

Re: glibc update refusing to proceed. File ownership problem

#246 2012-07-20 22:24:34

Re: glibc update refusing to proceed. File ownership problem

#247 2012-07-20 22:26:40

Re: glibc update refusing to proceed. File ownership problem

#248 2012-07-20 22:27:53

Re: glibc update refusing to proceed. File ownership problem

#249 2012-07-20 22:29:16

Re: glibc update refusing to proceed. File ownership problem

#250 2012-07-20 22:32:40

Re: glibc update refusing to proceed. File ownership problem

Board footer