stepping through the glibc wiki upgrade [SOLVED] (just formatted)

train_wreck · 2012-07-15 19:00:34

*sigh*

I'm trying not to curse in frustration....

So. Main page news article says:

"All Arch Linux packages have had their files in the /lib directory moved to /usr/lib and now /lib is a symlink to usr/lib. When performing this update, pacman will likely identify a conflict in the /lib directory"

When does this happen? Presumably during the pacman update commands that are listed below this:

pacman -Syu --ignore glibc
pacman -Su

In any case, it sure didn't happen when I tried to do this on my system. The first command went fine, upgrading all of the requisite packages at the time. The second, however, gave me the following which, as I understand, has been commonplace:

:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...

Targets (1): glibc-2.16.0-2

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

Proceed with installation? [Y/n]
(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: /lib/ld-2.16.so exists in filesystem
glibc: /lib/ld-linux-x86-64.so.2 exists in filesystem
glibc: /lib/libBrokenLocale-2.16.so exists in filesystem
glibc: /lib/libBrokenLocale.so.1 exists in filesystem
glibc: /lib/libSegFault.so exists in filesystem
glibc: /lib/libanl-2.16.so exists in filesystem
glibc: /lib/libanl.so.1 exists in filesystem
glibc: /lib/libc-2.16.so exists in filesystem
glibc: /lib/libc.so.6 exists in filesystem
glibc: /lib/libcidn-2.16.so exists in filesystem
glibc: /lib/libcidn.so.1 exists in filesystem
glibc: /lib/libcrypt-2.16.so exists in filesystem
glibc: /lib/libcrypt.so.1 exists in filesystem
glibc: /lib/libdl-2.16.so exists in filesystem
glibc: /lib/libdl.so.2 exists in filesystem
glibc: /lib/libm-2.16.so exists in filesystem
glibc: /lib/libm.so.6 exists in filesystem
glibc: /lib/libmemusage.so exists in filesystem
glibc: /lib/libnsl-2.16.so exists in filesystem
glibc: /lib/libnsl.so.1 exists in filesystem
glibc: /lib/libnss_compat-2.16.so exists in filesystem
glibc: /lib/libnss_compat.so.2 exists in filesystem
glibc: /lib/libnss_db-2.16.so exists in filesystem
glibc: /lib/libnss_db.so.2 exists in filesystem
glibc: /lib/libnss_dns-2.16.so exists in filesystem
glibc: /lib/libnss_dns.so.2 exists in filesystem
glibc: /lib/libnss_files-2.16.so exists in filesystem
glibc: /lib/libnss_files.so.2 exists in filesystem
glibc: /lib/libnss_hesiod-2.16.so exists in filesystem
glibc: /lib/libnss_hesiod.so.2 exists in filesystem
glibc: /lib/libnss_nis-2.16.so exists in filesystem
glibc: /lib/libnss_nis.so.2 exists in filesystem
glibc: /lib/libnss_nisplus-2.16.so exists in filesystem
glibc: /lib/libnss_nisplus.so.2 exists in filesystem
glibc: /lib/libpcprofile.so exists in filesystem
glibc: /lib/libpthread-2.16.so exists in filesystem
glibc: /lib/libpthread.so.0 exists in filesystem
glibc: /lib/libresolv-2.16.so exists in filesystem
glibc: /lib/libresolv.so.2 exists in filesystem
glibc: /lib/librt-2.16.so exists in filesystem
glibc: /lib/librt.so.1 exists in filesystem
glibc: /lib/libthread_db-1.0.so exists in filesystem
glibc: /lib/libthread_db.so.1 exists in filesystem
glibc: /lib/libutil-2.16.so exists in filesystem
glibc: /lib/libutil.so.1 exists in filesystem
Errors occurred, no packages were upgraded.

As per this main news article, I referenced the linked wiki page. The second issue seems to be the relevant one to my case. It states to perform the following command:

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

and check to see if any other package owns any of the files other than glibc. There are none. glibc is the only thing that owns any of the files in the /lib directory. The files in the modules direcroty are apparently not owned by anyone; not sure if that's related to this.

And then the wiki article just ends. I'm still not able to upgrade glibc. I've had a fleeting thought to move all of the files there to /usr/lib, delete the /lib folder and create a symlink manually, but have read horror stories from others who've tried to do that.

So what gives? What would be my next step? Forgive me for being an absolute idiot who is far inferior in knowledge and skills than anyone else, but I seem to have run out of ideas. Help? TIA

Last edited by train_wreck (2012-07-19 22:37:08)

Zamboniman · 2012-07-15 19:11:12

There's a number of posts with information about this already. The most helpful is the stickied topic above, https://bbs.archlinux.org/viewtopic.php?id=145006 which answers your questions. I left a post, #39, in this topic explaining some of this but there are a number of other helpful posts as well. Take a read through on this and other topics and you should be all set to go.

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

train_wreck · 2012-07-15 19:16:09

I have indeed read such thread, and your identified post (39) states that the output of this:

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

and this:

grep '^lib/' /var/lib/pacman/local/*/files

should only show glibc stuff. However, on my system this is the output of the first command:

error: cannot determine ownership of directory '/lib'
/lib/libpcprofile.so is owned by glibc 2.16.0-1
/lib/libnss_compat-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/libnss_nisplus.so.2 is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libc-2.16.so is owned by glibc 2.16.0-1
/lib/libc.so.6 is owned by glibc 2.16.0-1
/lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
/lib/libnss_hesiod.so.2 is owned by glibc 2.16.0-1
/lib/libnss_files.so.2 is owned by glibc 2.16.0-1
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libpthread.so.0 is owned by glibc 2.16.0-1
/lib/libnss_dns-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/libm.so.6 is owned by glibc 2.16.0-1
/lib/libnss_nis-2.16.so is owned by glibc 2.16.0-1
/lib/libcrypt.so.1 is owned by glibc 2.16.0-1
/lib/libdl.so.2 is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.16.0-1
/lib/libresolv-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/libnss_compat.so.2 is owned by glibc 2.16.0-1
/lib/libnss_db.so.2 is owned by glibc 2.16.0-1
/lib/librt.so.1 is owned by glibc 2.16.0-1
/lib/libdl-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/libnsl-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/libcidn-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/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_files-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/libthread_db.so.1 is owned by glibc 2.16.0-1
/lib/libSegFault.so is owned by glibc 2.16.0-1
/lib/libnss_db-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/libnsl.so.1 is owned by glibc 2.16.0-1
/lib/libresolv.so.2 is owned by glibc 2.16.0-1
/lib/libpthread-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-2.16.so is owned by glibc 2.16.0-1
/lib/libm-2.16.so is owned by glibc 2.16.0-1

and the second command doesn't show any output. Now that sure looks like glibc is the only owner there.

?

Last edited by train_wreck (2012-07-15 19:17:47)

Zamboniman · 2012-07-15 19:26:56

See where it says

error: cannot determine ownership of directory '/lib'

This is a problem. Something else is thinking it owns /lib

You may want to attempt one of the other solutions from a chrooted environment if you can't determine what the culprit is.

train_wreck · 2012-07-15 19:33:18

Doing ls -l /:

total 129K
4.0K drwxr-xr-x  2 root root 4.0K Jul 15 14:05 bin/
1.0K drwxr-xr-x  4 root root 1.0K Jul 14 19:14 boot/
 64K -rw-------  1 root root  59K Jul  8 19:02 dead.letter
   0 drwxr-xr-x 15 root root 3.0K Jul 14 19:25 dev/
4.0K drwxr-xr-x 44 root root 4.0K Jul 15 14:05 etc/
4.0K drwxr-xr-x  4 root root 4.0K May  4 00:27 home/
4.0K drwxr-xr-x  2 root root 4.0K Jul 14 19:14 lib/
   0 lrwxrwxrwx  1 root root    4 Jul  2 09:33 lib64 -> /lib/
 16K drwx------  2 root root  16K May  2 05:05 lost+found/
4.0K drwxr-xr-x  2 root root 4.0K Jun 20 04:31 media/
4.0K drwxr-xr-x  3 root root 4.0K May  2 05:45 mnt/
4.0K drwxr-xr-x  2 root root 4.0K Jun 20 04:31 opt/
   0 dr-xr-xr-x 75 root root    0 Jul 14 19:24 proc/
4.0K drwxr-x---  6 root root 4.0K Jun 29 09:01 root/
   0 drwxr-xr-x 15 root root  460 Jul 14 19:26 run/
4.0K drwxr-xr-x  2 root root 4.0K Jul 15 14:05 sbin/
4.0K drwxr-xr-x  4 root root 4.0K Jun 20 04:31 srv/
   0 dr-xr-xr-x 13 root root    0 Jul 14 19:24 sys/
   0 drwxrwxrwt  7 root root  140 Jul 15 14:05 tmp/
4.0K drwxr-xr-x  9 root root 4.0K May  5 17:28 usr/
4.0K drwxr-xr-x 14 root root 4.0K Jul 12 22:28 var/

it appears that root owns it. As per the wiki article:

If after this the "pacman -Su" still has conflicts with /lib, this is because a package on your system other than glibc thinks it owns the /lib folder.
These packages need rebuilding so as not to include the /lib directory. Then the final "pacman -Su" will successfully install glibc.

This statement makes no sense in my case. How would I remove the offending "root" package?

Zamboniman · 2012-07-15 19:41:28

Two different meanings here of "owned."

Your ls output shows which user on the system owns the files, in this case of course root owns /lib, but we're actually talking about which arch package "owns" /lib, or, put another way, which package wants to put files in /lib and therefore also would create /lib (owned by root) if it didn't already exist.

So, removing any package on your system trying to put files in /lib would fix it. Or, try installing an older version of glibc from your cache first before upgrading, or use pacman -r to get the files out of there to fix it, or use a chrooted environment to fix it.

tancrackers · 2012-07-15 19:48:58

Zamboniman wrote:

There's a number of posts with information about this already. The most helpful is the stickied topic above, https://bbs.archlinux.org/viewtopic.php?id=145006 which answers your questions. I left a post, #39, in this topic explaining some of this but there are a number of other helpful posts as well. Take a read through on this and other topics and you should be all set to go.

OMG thank you!! This just solved my problem. You are my hero. FYI, it was post #39 of the linked thread that helped me.
Once again, thank you!

train_wreck · 2012-07-15 19:50:04

*sigh* i see. I'm sorry for being retarded about this. Although i do hope you understand my confusion...

Apparently having a modules folder in there can cause problems (so i'm noticing from the main sticked thread about this)... some have had success removing the modules directory. I tried this but to no avail, still cannot upgrade.

How might I go about finding what owns /lib and where to change it?

Zamboniman · 2012-07-15 19:56:52

You're not being retarded. This is one of the most annoying upgrade issues I've dealt with, and I've seen a few. It's just that /lib is so very fundamental to a linux system that messing with it can really cause major headaches.

To answer your question, that's what the output of the two commands are supposed to show you. If they're not showing anything, the problem is elsewhere. It could be any number of things depending on what's happened on your system in the past. Your output from your first post seems to indicate that possibly all your /lib files were placed there by some other process than pacman installing glibc.

This is where possibly re-installing your current version of glibc could be helpful before upgrading. It should be in your cache, or you can d/l it.

train_wreck · 2012-07-15 20:06:47

Hmm. To date this is a ~2year old install, and every piece of software has been installed using pacman and the original listed repositories (x64). I tried reinstalling the current version of glibc using the cache (2.16.0-1) but again to no avail. To be honest i'm an inch away from just formatting/reinstalling...

I guess my frustration here stems from the fact that I don't precisely see why the whole change is necessary... as I understand the intention is to consolidate /usr/lib and /lib into the same directory... why? As you said, futzing about with system files (this applies to any OS) is asking for trouble. And even then, how come it isn't just a simple case of moving /lib/* to /usr/lib*, removing /lib and replacing it with a symlink to /usr/lib? Seems like it should be simple enough.

If it ain't broke....

progandy · 2012-07-15 20:35:03

The problem is that glibc is a fundamental part of the system. It also contains the linker which loads shared libraries for applications. If you move it carelessy, it will cause problems: Move all files from /lib to usr/lib. Now you call rmdir, but it needs the linker in /lib, which you just moved. Same for ln -s

Somehow the errors look a bit strange. Please try this:
First force-install the old glibc with pacman -U /var/cache/pacman/pkg/gllibibc-2.16.0-1...
Then remove any folders from /lib
Then perform the update normally without force

If it does not work (could break your system, though):
Before you continue, install busybox and start a busybox root shell (sudo busybox sh). This ensures you will be able to copy and move stuff even if glibc is broken. A reboot will not work, though.
Then create a backup-copy your /lib-folder, also make sure you have the old and the new glibc package (.16.0-1 and .16.0-2) (e.g. in the pacman cache)
force-install the new glibc
Switch to busybox:
make sure, /usr/bin/ld-linux... exists, if not stop the update, copy your /lib-backup back and reinstall glibc .16-1
remove /lib if it is no symlink
link /lib to usr/lib: "ln -s usr/lib /lib"
install glibc without force
in a normal shell test if everything works before you close busybox (run e.g. nano, top, ...)

Edit: Thanks. Just why did I write bin instead of lib?

Last edited by progandy (2012-07-15 23:46:02)

cfr · 2012-07-15 23:29:03

link /lib to usr/lib: "ln -s usr/bin /lib"

is wrong. I think progandy means:

link /lib to usr/lib: "ln -s usr/lib /lib"

I would suggest installing busybox and starting the busybox shell *before* doing the earlier steps, just to be safe. Note that you can also su or login on another console as root if you don't have sudo.

Before doing that, though. Just to clarify: when you gave the output of

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

it didn't show any directories. Later on, though, you said that you removed the modules directory. Did you filter the original output? If so, post the complete output.

Something is wrong.

grep '^lib/' /var/lib/pacman/local/*/files

should not return nothing - it should return at least glibc. Personally, I would want to find out what's going on with that before I did anything further. What do

ls /var/lib/pacman/local/glibc*

and

cat /var/lib/pacman/local/glibc*/files

give?

securitybreach · 2012-07-16 12:45:50

train_wreck wrote:

I guess my frustration here stems from the fact that I don't precisely see why the whole change is necessary... as I understand the intention is to consolidate /usr/lib and /lib into the same directory... why? As you said, futzing about with system files (this applies to any OS) is asking for trouble. And even then, how come it isn't just a simple case of moving /lib/* to /usr/lib*, removing /lib and replacing it with a symlink to /usr/lib? Seems like it should be simple enough.
If it ain't broke....

I understand the change is from the upstream version of glibc but I am also curious to the specifics of this change. If anyone has a link to why this change was needed, I would also appreciate it.

Thanks

sonoran · 2012-07-16 14:49:24

securitybreach wrote:

train_wreck wrote:
I guess my frustration here stems from the fact that I don't precisely see why the whole change is necessary... as I understand the intention is to consolidate /usr/lib and /lib into the same directory... why? As you said, futzing about with system files (this applies to any OS) is asking for trouble. And even then, how come it isn't just a simple case of moving /lib/* to /usr/lib*, removing /lib and replacing it with a symlink to /usr/lib? Seems like it should be simple enough.
If it ain't broke....
I understand the change is from the upstream version of glibc but I am also curious to the specifics of this change. If anyone has a link to why this change was needed, I would also appreciate it.
Thanks

One starting point:
http://mailman.archlinux.org/pipermail/ … 22625.html

You're welcome.

securitybreach · 2012-07-16 15:09:41

Thanks Sonoran!!

Arch Linux

#1 2012-07-15 19:00:34

stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#2 2012-07-15 19:11:12

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#3 2012-07-15 19:16:09

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#4 2012-07-15 19:26:56

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#5 2012-07-15 19:33:18

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#6 2012-07-15 19:41:28

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#7 2012-07-15 19:48:58

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#8 2012-07-15 19:50:04

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#9 2012-07-15 19:56:52

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#10 2012-07-15 20:06:47

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#11 2012-07-15 20:35:03

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#12 2012-07-15 23:29:03

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#13 2012-07-16 12:45:50

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#14 2012-07-16 14:49:24

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

#15 2012-07-16 15:09:41

Re: stepping through the glibc wiki upgrade [SOLVED] (just formatted)

Board footer