* Tom Gundersen [07.07.2012 15:55]:

On Sat, Jul 7, 2012 at 3:42 PM, fredbezies wrote:

...

I upgraded a few minutes ago my archlinux + testing installation. As I cannot install glibc (because of some AUR software which had links or binary in /lib), I made the mistake of forcing installation. My system is dead. I will try repairing using archboot on an USB key.

This is expected behavior. It is good you mention this on the list, to remind everyone that you should never use --force unless you really, really know exactly what is going to happen.

In this case glibc moved from /lib to /usr/lib. The upgrade should have replaced /lib by a symlink to /usr/lib. This is necessary to make the linker keep working. However, since you had some stuff from AUR still in /lib this did not work. The correct solution would have been to move that stuff out of the way, so that the upgrade could continue normally.

Since you used --force, however, pacman ignored the fact that the symlink could not be created and basically hosed your system.

It should be simple enough to fix though: mount your root from a rescue system, empty /lib manually and replace it with a symlink to /usr/lib. Assuming I guessed correctly at what exactly happened that is.

Cheers,

Tom

I have the same problem, but I didn't force the update :) Here's what pacman spits out :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (2): Name Old Version New Version Net Change Download Size glibc 2.16.0-1 2.16.0-2 0.00 MiB lib32-glibc 2.16.0-1 2.16.0-2 -0.18 MiB Total Installed Size: 51.95 MiB Net Upgrade Size: -0.19 MiB Proceed with installation? [Y/n] (2/2) checking package integrity [-------------------------------------] 100% (2/2) loading package files [-------------------------------------] 100% (2/2) checking for file conflicts [-------------------------------------] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. So, looks like there's AUR-stuff in /lib, but I also get the following # for i in /lib/*;do pacman -Qo $i;done /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 Is this caused by the fact that there are two packages with files in /lib ? How can I solve this problem? Is it ok this time to force the update? I _could_ remove lib32-glibc first, run the update and then reinstall my lib32 stuff, since I don't have much lib32 stuff installed. But I think for many people this isn't an option! That's why I'm asking here. Best Army

On 07/07/2012 06:27 PM, Mantas Mikulėnas wrote:

On Sat, Jul 7, 2012 at 5:57 PM, Uli Armbruster wrote:

...

Is this caused by the fact that there are two packages with files in /lib ? How can I solve this problem? Is it ok this time to force the update?

I _could_ remove lib32-glibc first, run the update and then reinstall my lib32 stuff, since I don't have much lib32 stuff installed. But I think for many people this isn't an option! That's why I'm asking here.

I hit the same problem myself, and used `pacman -Rdd` to temporarily remove lib32-glibc bypassing the dependency checks. After upgrade, `pacman -S --asdeps lib32-glibc` to reinstall.

a new update for lib32-glibc exists in multilib-testing. You don't have that repo enabled? -- Ionuț

On 07/07/2012 05:47 PM, Jan Steffens wrote:

...

* Tom Gundersen [07.07.2012 15:55]:

...

On Sat, Jul 7, 2012 at 3:42 PM, fredbezies wrote:

...

I upgraded a few minutes ago my archlinux + testing installation. As I cannot install glibc (because of some AUR software which had links or binary in /lib), I made the mistake of forcing installation. My system is dead. I will try repairing using archboot on an USB key. This is expected behavior. It is good you mention this on the list, to remind everyone that you should never use --force unless you really, really know exactly what is going to happen.

In this case glibc moved from /lib to /usr/lib. The upgrade should have replaced /lib by a symlink to /usr/lib. This is necessary to make the linker keep working. However, since you had some stuff from AUR still in /lib this did not work. The correct solution would have been to move that stuff out of the way, so that the upgrade could continue normally.

Since you used --force, however, pacman ignored the fact that the symlink could not be created and basically hosed your system.

It should be simple enough to fix though: mount your root from a rescue system, empty /lib manually and replace it with a symlink to /usr/lib. Assuming I guessed correctly at what exactly happened that is.

Cheers,

Tom I have the same problem, but I didn't force the update :)

Here's what pacman spits out

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

Targets (2):

Name Old Version New Version Net Change Download Size

glibc 2.16.0-1 2.16.0-2 0.00 MiB lib32-glibc 2.16.0-1 2.16.0-2 -0.18 MiB

Total Installed Size: 51.95 MiB Net Upgrade Size: -0.19 MiB

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

So, looks like there's AUR-stuff in /lib, but I also get the following

# for i in /lib/*;do pacman -Qo $i;done /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

Is this caused by the fact that there are two packages with files in /lib ? How can I solve this problem? Is it ok this time to force the update?

I _could_ remove lib32-glibc first, run the update and then reinstall my lib32 stuff, since I don't have much lib32 stuff installed. But I think for many people this isn't an option! That's why I'm asking here.

Best Army

On Sat, Jul 7, 2012 at 4:57 PM, Uli Armbruster wrote: * Updated lib32-glibc in [multilib-testing]. Just install glibc last. $ pacman -Syu --ignore glibc $ pacman -S glibc * Is this the correct way to upgrade without breaking a system? Shall I use with confidence this method?

TY for any hints.

* Jan Steffens [07.07.2012 17:48]:

Updated lib32-glibc in [multilib-testing]. Just install glibc last. $ pacman -Syu --ignore glibc $ pacman -S glibc

Thanks, that did the trick :)