/lib exists in filesystem when installing testing/glibc 2.16.0-2

Roken · 2012-07-11 11:32:39

OK, an update. With the 3.5.0-rc6+ kernel (no patches - but highly customised to my system - using an updated .config from a previous stable 3.3 kernel build on Debian) the load average is still showing high (currently 3.4 on my quad core, relatively idle system). However, temps are fine (and in fact are 1 - 2C lower than the 3.2 kernel).

I suspect that this is now simply a reporting issue, rather than a "real" issue. CPU utilisation is as I would expect.

graysky · 2012-07-11 23:01:40

I read Alan's draft news item and wanted to try.

1) Copied my entire system to a sandbox partition and booted into it.
2) Enabled testing and:

# pacman -Syy
# pacman -Syu --ignore glibc
<<no problems>>

# pacman -S glibc
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
Errors occurred, no packages were upgraded.

At this point, I figured that I have some extra files/folders in /lib but that is not the case:

# pacman -Qo /lib/*
/lib/ld-2.16.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/libanl-2.16.so is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so 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/libcidn-2.16.so is owned by glibc 2.16.0-1
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libcrypt-2.16.so 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/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/libm-2.16.so is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/libm.so.6 is owned by glibc 2.16.0-1
/lib/libnsl-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl.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_compat.so.2 is owned by glibc 2.16.0-1
/lib/libnss_db-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_dns-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/libnss_files-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/libnss_hesiod-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/libnss_nis-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/libnss_nisplus.so.2 is owned by glibc 2.16.0-1
/lib/libnss_nis.so.2 is owned by glibc 2.16.0-1
/lib/libpcprofile.so 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/libresolv-2.16.so is owned by glibc 2.16.0-1
/lib/libresolv.so.2 is owned by glibc 2.16.0-1
/lib/librt-2.16.so is owned by glibc 2.16.0-1
/lib/librt.so.1 is owned by glibc 2.16.0-1
/lib/libSegFault.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/libutil-2.16.so is owned by glibc 2.16.0-1
/lib/libutil.so.1 is owned by glibc 2.16.0-1

I'm sure I'm missing something critical here... but what

Allan · 2012-07-11 23:10:07

Some other package must still own the /lib directory. Try

find /var/lib/pacman/local -name files | xargs grep "^lib/$"

and see if that prints more than glibc.

graysky · 2012-07-11 23:53:44

@Allan - I unfortunately nuked the partition before I read your comment. I repeated the process and 2nd time and found nothing that stopped it - the steps in the draft news item are fine for my system:

1) Enable [testing]
2) pacman -Syy
3) pacman -Su --ignore glibc
4) pacman -Su

No errors, no problems.

# ls -l lib
lrwxrwxrwx 1 root root 7 Jul  7 06:09 lib -> usr/lib

Allan · 2012-07-12 00:43:44

My guess is that you manually moved /lib/modules (or firmware...) to /usr/lib and there was still a package that thought is owned those files in /lib. This may be something we need to add to the release announcement.

Mr Green · 2012-07-12 06:41:04

find /var/lib/pacman/local -name files | xargs grep "^lib/$"
/var/lib/pacman/local/virtualbox-archlinux-modules-4.1.18-1/files:lib/
/var/lib/pacman/local/broadcom-wl-5.100.82.112-4/files:lib/
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/
/var/lib/pacman/local/lib32-glibc-2.16.0-1/files:lib/

Testing enabled on a virtual 64bit machine

Followed draft guide

(15/19) upgrading util-linux                       [----------------------] 100%
rmdir: failed to remove ‘/var/lib/hwclock’: No such file or directory
error: command failed to execute correctly

and still get [note: pacman was updated first!]

glibc-2.16.0-2-x86_64      7.7 MiB   350K/s 00:22 [----------------------] 100%
(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
Errors occurred, no packages were upgraded.

Last edited by Mr Green (2012-07-12 06:59:31)

Allan · 2012-07-12 07:56:48

You will need to fix:

/var/lib/pacman/local/broadcom-wl-5.100.82.112-4/files:lib/

maevius · 2012-07-12 08:43:11

System is up to date, [testing] and [mutlilib-testing] enabled, pacman 4.0.3-3. I removed /lib and manually added a symlink to usr/lib but still cannot upgrade to glibc-2.16.0-2
Am I missing something??

find /var/lib/pacman/local -name files | xargs grep "^lib/$"

/var/lib/pacman/local/glibc-2.16.0-1/files:lib/

ls -l /lib

lrwxrwxrwx 1 root root 7 Jul 12 14:27 /lib -> usr/lib

pacman -Su
:: 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: /usr/lib/ld-2.16.so exists in filesystem
glibc: /usr/lib/ld-linux-x86-64.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.

I forgot to mention that before that I did a

tar xf glibc-2.16.0-2-x86_64.pkg.tar.xz

probably this is the culprit...

EDIT SOLVED:

Ok I solved it.
1) boot from live cd
2) Mount / and delete all the conflicting files
3) cd /mountpoint && tar xf glibc-2.16.0-1
4) chroot /mountpoint
5) Pacman -Su

Last edited by maevius (2012-07-15 06:06:26)

Mr Green · 2012-07-12 09:06:46

Allan wrote:

You will need to fix:

/var/lib/pacman/local/broadcom-wl-5.100.82.112-4/files:lib/

Figured as much I need to remove broadcom-wl [AUR] then try installing glibc again

We do love you really

progandy · 2012-07-12 10:08:13

Mr Green wrote:

Allan wrote:
You will need to fix:
/var/lib/pacman/local/broadcom-wl-5.100.82.112-4/files:lib/
Figured as much I need to remove broadcom-wl [AUR] then try installing glibc again
We do love you really

Reinstall it and modify the PKGBUILD, change /lib/ to /usr/lib. You should be able do that before installing new glibc.

.:B:. · 2012-07-12 11:11:25

With the new pacman in [testing], you should be able to upgrade just fine, pacman had some bugs it seems that prevented the /lib migration from going smoothly. I updated lib32-glibc manually before upgrading glibc.

c0dege3k · 2012-07-13 15:44:50

Before I begin, I want all of you to know that I do in fact know how idiotic I was this morning. There is no need to tell me, or present the common lecture of why not to do what I did.

Now, being an idiot, I threw in --force. This has resulted in breaking just about everything in the terminal (the only thing that worked that I could find was 'cd'). Upon reboot, I got kernel panic. Here's the exact message: http://goo.gl/Nn4In. Is there anything besides reinstalling I can do to fix this?

Roken · 2012-07-13 16:00:25

c0dege3k wrote:

Before I begin, I want all of you to know that I do in fact know how idiotic I was this morning. There is no need to tell me, or present the common lecture of why not to do what I did.
Now, being an idiot, I threw in --force. This has resulted in breaking just about everything in the terminal (the only thing that worked that I could find was 'cd'). Upon reboot, I got kernel panic. Here's the exact message: http://goo.gl/Nn4In. Is there anything besides reinstalling I can do to fix this?

Boot a live distribution, chroot into Arch and set about fixing things. (Go back and read through this thread for what you will need to do).

lexan · 2012-07-13 16:03:17

.:B:. wrote:

With the new pacman in [testing], you should be able to upgrade just fine, pacman had some bugs it seems that prevented the /lib migration from going smoothly. I updated lib32-glibc manually before upgrading glibc.

How are you updating lib32-glibc first before upgrading glibc? Sorry if this is a beginner question, but when I try to update lib32-glibc, pacman targets the following packages: glibc-2.16.0-2, linux-api-headers-3.4.4-1, and lib32-glibc-2.16.0-1

And it fails with

glibc: /lib exists in filesystem
glibc: /lib64 exists in filesystem

I have the latest version of pacman installed pacman-4.0.3-3-x86_64

c0dege3k · 2012-07-13 18:11:24

Roken wrote:

c0dege3k wrote:
Before I begin, I want all of you to know that I do in fact know how idiotic I was this morning. There is no need to tell me, or present the common lecture of why not to do what I did.
Now, being an idiot, I threw in --force. This has resulted in breaking just about everything in the terminal (the only thing that worked that I could find was 'cd'). Upon reboot, I got kernel panic. Here's the exact message: http://goo.gl/Nn4In. Is there anything besides reinstalling I can do to fix this?
Boot a live distribution, chroot into Arch and set about fixing things. (Go back and read through this thread for what you will need to do).

I've booted into a Ubuntu Live CD, and am trying the chroot. I've followed every command here and I get this error message when running "chroot . /bin/bash": chroot: failed to run command `bash': No such file or directory.

This is exactly what was happening to me when I was actually in my Arch system and, based on answers in this thread, I feel like it's something screwed up with the symbolic links. Am I right?

padster · 2012-07-13 22:50:49

loafer wrote:

padster wrote:
@felixonmars: It doesn't work for me, it says that /lib is not a directory. I 'ls'd both of them and it looked to me like they were the same, maybe it was linked already? Then I rebooted and it still does the same error
It simple to check if it's a symlink:
ls -l /lib
lrwxrwxrwx 1 root root 7 Jul  7 12:04 /lib -> usr/lib

Looks like it is a symlink. Also, when it booted, it said something about /usr/lib/ld-2.16.so does not exist, bailing out. But it did exist when I checked. And the filesystem looked kind of different, like a live filesystem, with new_root, and such.

Allan · 2012-07-13 23:11:47

lexan wrote:

How are you updating lib32-glibc first before upgrading glibc? Sorry if this is a beginner question, but when I try to update lib32-glibc, pacman targets the following packages: glibc-2.16.0-2, linux-api-headers-3.4.4-1, and lib32-glibc-2.16.0-1

Add [multilib-testing]

lexan · 2012-07-13 23:40:16

Allan wrote:

lexan wrote:
How are you updating lib32-glibc first before upgrading glibc? Sorry if this is a beginner question, but when I try to update lib32-glibc, pacman targets the following packages: glibc-2.16.0-2, linux-api-headers-3.4.4-1, and lib32-glibc-2.16.0-1
Add [multilib-testing]

Thank you!

But although that did allow me to upgrade lib32-glibc without needing those other packages that I mentioned, I get the same error about /lib and /lib64 existing when trying to upgrade glibc after.

progandy · 2012-07-13 23:46:22

lexan wrote:

Thank you!
But although that did allow me to upgrade lib32-glibc without needing those other packages that I mentioned, I get the same error about /lib and /lib64 existing when trying to upgrade glibc after.

This command should help you find any files which will cause problems when upgrading:

find {/lib,/lib64} | xargs pacman -Qo | grep -v glibc

lexan · 2012-07-14 00:11:50

progandy wrote:

This command should help you find any files which will cause problems when upgrading:
find {/lib,/lib64} | xargs pacman -Qo | grep -v glibc

I'm getting the feeling I'm going to have all kinds of problems trying to fix this. I put the output to a text file and I can't begin to count how many packages showed up. Output

progandy · 2012-07-14 00:16:57

lexan wrote:

progandy wrote:
This command should help you find any files which will cause problems when upgrading:
find {/lib,/lib64} | xargs pacman -Qo | grep -v glibc
I'm getting the feeling I'm going to have all kinds of problems trying to fix this. I put the output to a text file and I can't begin to count how many packages showed up. Output

First update your kernel package to 3.4.4-3, then update virtualbox-modules to 4.1.18-2. Reboot, run the find-command again. You should not find any modules now. Install glibc.

Allan · 2012-07-14 00:30:17

Do a full update ignoring glibc...

READ THIS: https://wiki.archlinux.org/index.php/De … iki:usrlib

lexan · 2012-07-14 00:40:28

progandy wrote:

First update your kernel package to 3.4.4-3, then update virtualbox-modules to 4.1.18-2. Reboot, run the find-command again. You should not find any modules now. Install glibc.

I couldn't update virtualbox-modules after I had updated the kernel to 3.4.4-3 because it gave me a fatal error that an arch linux 3.4.4-3 directory didn't exist.. so I rebooted, and now I'm in a recovery shell because /dev/sda1 couldn't be found.

Roken · 2012-07-14 00:54:22

c0dege3k wrote:

Roken wrote:
c0dege3k wrote:
Before I begin, I want all of you to know that I do in fact know how idiotic I was this morning. There is no need to tell me, or present the common lecture of why not to do what I did.
Now, being an idiot, I threw in --force. This has resulted in breaking just about everything in the terminal (the only thing that worked that I could find was 'cd'). Upon reboot, I got kernel panic. Here's the exact message: http://goo.gl/Nn4In. Is there anything besides reinstalling I can do to fix this?
Boot a live distribution, chroot into Arch and set about fixing things. (Go back and read through this thread for what you will need to do).
I've booted into a Ubuntu Live CD, and am trying the chroot. I've followed every command here and I get this error message when running "chroot . /bin/bash": chroot: failed to run command `bash': No such file or directory.
This is exactly what was happening to me when I was actually in my Arch system and, based on answers in this thread, I feel like it's something screwed up with the symbolic links. Am I right?

OK - see this post - https://bbs.archlinux.org/viewtopic.php … 9#p1126729 - (I did suggest that the two threads be merged). that post should help you, but maybe read through that thread as well. Hopefully, it will help get you back on track.

lexan · 2012-07-14 02:39:33

lexan wrote:

progandy wrote:
First update your kernel package to 3.4.4-3, then update virtualbox-modules to 4.1.18-2. Reboot, run the find-command again. You should not find any modules now. Install glibc.

I couldn't update virtualbox-modules after I had updated the kernel to 3.4.4-3 because it gave me a fatal error that an arch linux 3.4.4-3 directory didn't exist.. so I rebooted, and now I'm in a recovery shell because /dev/sda1 couldn't be found.

I booted into an arch live usb drive, mounted my partition, changed root to downgrade linux packages from my pacman cache folder...

I now have linux-3.4.4-2, linux-api-headers-3.3.8-1, and linux-headers-3.4.4-2 downgraded and my system was able to reboot. I think I saw a fail flag for the vboxdrv modules during the boot process.

My current virtualbox-modules is on 4.1.18-2

Can I do what Allan said previously w/o breaking my system? :-)

Allan wrote:

Do a full update ignoring glibc...
READ THIS: https://wiki.archlinux.org/index.php/De … iki:usrlib

EDIT: I downgraded virtualbox and virtualbox-modules to 4.1.18-2, which is what I'm pretty sure I had previously and went ahead following the instructions on the link Allan provided. Everything upgraded, and everything seems fine now! Thank you so much for all the help!

Last edited by lexan (2012-07-14 04:10:30)

Arch Linux

#26 2012-07-11 11:32:39

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#27 2012-07-11 23:01:40

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#28 2012-07-11 23:10:07

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#29 2012-07-11 23:53:44

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#30 2012-07-12 00:43:44

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#31 2012-07-12 06:41:04

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#32 2012-07-12 07:56:48

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#33 2012-07-12 08:43:11

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#34 2012-07-12 09:06:46

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#35 2012-07-12 10:08:13

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#36 2012-07-12 11:11:25

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#37 2012-07-13 15:44:50

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#38 2012-07-13 16:00:25

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#39 2012-07-13 16:03:17

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#40 2012-07-13 18:11:24

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#41 2012-07-13 22:50:49

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#42 2012-07-13 23:11:47

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#43 2012-07-13 23:40:16

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#44 2012-07-13 23:46:22

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#45 2012-07-14 00:11:50

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#46 2012-07-14 00:16:57

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#47 2012-07-14 00:30:17

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#48 2012-07-14 00:40:28

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#49 2012-07-14 00:54:22

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

#50 2012-07-14 02:39:33

Re: /lib exists in filesystem when installing testing/glibc 2.16.0-2

Board footer