Can not upgrade glibc

phlux · 2012-07-07 15:27:46

Greetings, folks. I've run into the following problem:

Proceed with installation? [Y/n] y
(4/4) checking package integrity                                                 [##############################################] 100%
(4/4) loading package files                                                      [##############################################] 100%
(4/4) checking for file conflicts                                                [##############################################] 100%
error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
Errors occurred, no packages were upgraded.
[phlux@localhost ~]$ 

Using --force will not work, and this situation is different from the one described earlier with /lib64 existing in filesystem, because every file in /lib belongs to glibc as shown here:

[phlux@localhost ~]$ sudo 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/ld-linux.so.2 is owned by lib32-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/libSegFault.so 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/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/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/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/libm.so.6 is owned by glibc 2.16.0-1
/lib/libmemusage.so 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_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/libnss_nisplus.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/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

Anyone know where else we can go with this?

phlux · 2012-07-07 15:39:21

I was able to resolve this issue by installing glibc last, and upgrading everything else one-by-one.lib32-gcc-libs-4.7.1-4.1

ewaller · 2012-07-07 16:07:10

Please use BBCode code tags. Your readers will appreciate it.
Thanks

ilpianista · 2012-07-07 16:17:22

phlux wrote:

I was able to resolve this issue by installing glibc last, and upgrading everything else one-by-one.lib32-gcc-libs-4.7.1-4.1

Because there was ld-linux.so.2 installed by lib32-glibc in /lib. You updated lib32-glibc before glibc, so that file has been moved to /usr/lib32/.

ewaller · 2012-07-07 16:27:19

It has been suggested this belongs in the testing forum. Done.

ttll · 2012-07-07 16:48:55

same issue here on i686, can't get it to install

do *not* use --force because it will bork your system

Last edited by ttll (2012-07-07 16:49:23)

ewaller · 2012-07-07 16:51:55

ttll wrote:

same issue here on i686, can't get it to install
do *not* use --force because it will bork your system

I can attest to that (As ewaller posts from Windows 7). Looks like I'll be fixing this for a while. Any suggestions? I don't think I'll even be able to chroot.

stupid. stupid. stupid.

stronnag · 2012-07-07 16:57:32

It happens even without --force.

Boot from rescue disk. Mount the broken partition (e.g. to /mnt), remove /mnt/lib, cd /mnt ; ln -sf usr/lib lib. Ensure you do it on the broken disk. Reboot.

ewaller · 2012-07-07 17:32:21

stronnag wrote:

It happens even without --force.
Boot from rescue disk. Mount the broken partition (e.g. to /mnt), remove /mnt/lib, cd /mnt ; ln -sf usr/lib lib. Ensure you do it on the broken disk. Reboot.

Happy, happy. Joy, joy

I knew I kept that Linux From Scratch partition around for a good reason.
The only thing that went wrong was that I did not think I needed the kernel modules that were in /lib -- there were modules laying around from previous custom kernels, I missed that the current kernel's modules were still in there before I nuked /lib. No problem, the system booted into a crippled state. Although I had no Ethernet, I did have a cached copy of core/linux which I reinstalled.

Posting from inside a fully functional Arch system. Thanks.

ttll · 2012-07-07 18:50:22

Please vote https://bugs.archlinux.org/task/30588

progandy · 2012-07-07 19:18:20

stronnag wrote:

It happens even without --force.
Boot from rescue disk. Mount the broken partition (e.g. to /mnt), remove /mnt/lib, cd /mnt ; ln -sf usr/lib lib. Ensure you do it on the broken disk. Reboot.

Good thing I have a few bootable cds. To make sure nothing was missed, I reinstalled glibc afterwards.

mathieui · 2012-07-08 03:09:56

As falconidy pointed out on reddit, you can fix that easily if you still have a root shell open:

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

(and yes, I just did that)

Last edited by mathieui (2012-07-08 03:10:21)

eaep · 2012-07-08 06:41:06

I have the same problem. First I upgrade my system using:

#pacman -Syu --ignore glibc

My system upgrade OK.

Then I put:

#pacman -S --force glibc

I broke my system.

I have debian in the same system. I restart from debian, mount archrlinux following:

#mkdir /mnt/arch

#mount -wa -t ext4 /dev/sda6 /mnt/arch

#mount -wa -t ext4 /dev/sda5 /mnt/arch/boot

#mount -wa -t ext4 /dev/sda7 /mnt/arch/var

#mount -wa -t ext4 /dev/sda8 /mnt/arch/usr

#mount -wa -t ext4 /dev/sda10 /mnt/arch/home

#mount --bind /sys /mnt/arch/sys

#mount --bind /dev /mnt/arch/dev

#mount --bind /proc /mnt/arch/proc

#cd /mnt/arch

Then make chroot:

#chroot .

The system do not make the root change because glibc in archlinux are broked. Give:

...
# /bin/bash not found
...

Then I copy glibc-2.16.0-1-x86_64.pkg.tar.xz from /mnt/arch/var/cache/pacman/pkg to /mnt/arch and uncompress it:

#cp /mnt/arch/var/cache/pacman/pkg/glibc-2.16.0-1-x86_64.pkg.tar.xz /mnt/arch/glibc-2.16.0-1-x86_64.pkg.tar.xz
#tar -Jxvf glibc-2.16.0-1-x86_64.pkg.tar.xz

Then chroot work ok.

The system do not upgrade glibc with chroot from debian. I leave the system with glibc-2.16.0-1-x86_64.pkg.tar.xz untared but with glibc-2.16.0-2 apparently installed. I reboot my system and i can boot archlinux. and with GDM broken. GDM is broken since I upgrade glibc-2.16.0-1 .

I reinstall glibc using first the previous answer:

#pacman -S glibc
...
#/usr/lib/ld-2.16.so /bin/rm -r /lib
#/usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib

#pacman -S glibc
warning: glibc-2.16.0-2 is up to date -- reinstalling
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] y
(1/1) checking package integrity                   [######################] 100%
(1/1) loading package files                        [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
(1/1) checking available disk space                [######################] 100%
(1/1) upgrading glibc                              [######################] 100%
Generating locales...
Generation complete.

I reboot my system OK, with a little problem with locales:

# locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
POSIX

I select my used locale editing /etc/locale.gen:

#nano /etc/locale.gen

Using nano as console editor. And then update locale:

locale-gen

Now my system is OK.

If you broke your system can follow the commands that I suggest to restore them, you can make this booting your system with achlinux install media.

Last edited by eaep (2012-07-08 07:41:00)

tomk · 2012-07-08 09:04:12

eaep - glad it worked for you, but you could have just done as suggested in post #8.

Worked perfectly for me, thanks stronnag.

scottro · 2012-07-08 12:36:05

Just so I'm clear--so as long as testing is enabled, right now, glibc can't be upgraded normally. Using --force will break the system. This is on the news page?

Allan · 2012-07-08 12:40:29

scottro wrote:

Just so I'm clear--so as long as testing is enabled, right now, glibc can't be upgraded normally.

It depends when you last updated...

scottro wrote:

Using --force will break the system.

It depends when you last updated...

scottro wrote:

This is on the news page?

No. We do not announce anything in [testing] there (usually). Read the arch-dev-public mailing list.

scottro · 2012-07-08 13:12:59

I understand, sort of, the philosophy, but have to respectfully disagree. On a fresh install, I ran into this. I updated, (it was a net install, so nothing to update), then uncommented testing in pacman.conf when I ran into the error.

I suspect a lot of people will get hit by it, and several will use --force.

So, I'm a bit unclear about the when one last updated issue.

Allan · 2012-07-08 13:25:29

I'll clarify... if you use [testing] and updated within the last three or four days, you will not hit this issue.

But if [testing] users are incompetent enough to use --force - which is explicitly warned against on arch-dev-public and is stupid in general - they deserved the broken system.

gamezelda · 2012-07-08 13:31:04

In my case, the /lib/ directly contained a symlink created by the gcc package, and /lib/modules/ contained some files created by nvidia-173xx (this is from AUR) and some modules from older kernels (unowned).

I uninstalled nvidia-173xx and gcc, removed /lib/modules/, and I was able to update glibc. Then I reinstalled gcc and nvidia-173xx and everything works so far.

PAdu92 · 2012-07-08 13:32:30

Allan wrote:

I'll clarify... if you use [testing] and updated within the last three or four days, you will not hit this issue.

I am up to date, only update available is glibc and I can't update it because of the modules folder.....

tomk · 2012-07-08 13:35:03

scottro wrote:

On a fresh install, I ran into this. I updated, (it was a net install, so nothing to update), then uncommented testing in pacman.conf when I ran into the error.

No, you ran into this error when you uncommented testing i.e. enabled testing. Only testing/glibc produces this error.

scottro · 2012-07-08 13:49:52

Firstly, I should specify that I wasn't trying to be confrontational, if one uses testing, then it's up to the user to keep up with it--although 95 or more percent of the time, one can be lazy, still use it, and get away with it.

So, my confusion is about what Allan about depending upon when one updates. I installed this morning. It was a net install, and I chose core. Do you mean I could have avoided this by choosing testing during installation? (I gave a quick look at the dev-public list as Allan suggested and see workarounds, but I'm getting the impression from this thread that if one had been updating regularly, one wouldn't have the issue. For those looking
http://mailman.archlinux.org/pipermail/ … bject.html is this month's archives by subject.

This one worked for me on a fresh install

http://mailman.archlinux.org/pipermail/ … 23200.html

Last edited by scottro (2012-07-08 13:53:05)

Allan · 2012-07-08 14:09:11

PAdu92 wrote:

Allan wrote:
I'll clarify... if you use [testing] and updated within the last three or four days, you will not hit this issue.
I am up to date, only update available is glibc and I can't update it because of the modules folder.....

So you paid lots of attention to the kmod post install message? Note those files are either there from non-official packages or manually installed.

PAdu92 · 2012-07-08 14:16:12

Allan wrote:

So you paid lots of attention to the kmod post install message? Note those files are either there from non-official packages or manually installed.

Yes for kmod and in the modules folder are "extramodules-3.4-ARCH" (and 3.3) and inside are OSS folders....
Anyway now it's telling me that /lib already exist on my system and fails to install because of that....

Roken · 2012-07-08 15:04:16

It seems to me that this thread and this should be merged.

Arch Linux

#1 2012-07-07 15:27:46

Can not upgrade glibc

#2 2012-07-07 15:39:21

Re: Can not upgrade glibc

#3 2012-07-07 16:07:10

Re: Can not upgrade glibc

#4 2012-07-07 16:17:22

Re: Can not upgrade glibc

#5 2012-07-07 16:27:19

Re: Can not upgrade glibc

#6 2012-07-07 16:48:55

Re: Can not upgrade glibc

#7 2012-07-07 16:51:55

Re: Can not upgrade glibc

#8 2012-07-07 16:57:32

Re: Can not upgrade glibc

#9 2012-07-07 17:32:21

Re: Can not upgrade glibc

#10 2012-07-07 18:50:22

Re: Can not upgrade glibc

#11 2012-07-07 19:18:20

Re: Can not upgrade glibc

#12 2012-07-08 03:09:56

Re: Can not upgrade glibc

#13 2012-07-08 06:41:06

Re: Can not upgrade glibc

#14 2012-07-08 09:04:12

Re: Can not upgrade glibc

#15 2012-07-08 12:36:05

Re: Can not upgrade glibc

#16 2012-07-08 12:40:29

Re: Can not upgrade glibc

#17 2012-07-08 13:12:59

Re: Can not upgrade glibc

#18 2012-07-08 13:25:29

Re: Can not upgrade glibc

#19 2012-07-08 13:31:04

Re: Can not upgrade glibc

#20 2012-07-08 13:32:30

Re: Can not upgrade glibc

#21 2012-07-08 13:35:03

Re: Can not upgrade glibc

#22 2012-07-08 13:49:52

Re: Can not upgrade glibc

#23 2012-07-08 14:09:11

Re: Can not upgrade glibc

#24 2012-07-08 14:16:12

Re: Can not upgrade glibc

#25 2012-07-08 15:04:16

Re: Can not upgrade glibc

Board footer