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

felixonmars · 2012-07-07 16:38:35

I'm getting this error when installing testing/glibc 2.16.0-2:

error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem

As I did not find anything particular related to this in the mailling list or the forum, I'd like to ask: Is it safe to --force this transaction?

wonder · 2012-07-07 16:44:51

do not --force.

do pacman -Qo /lib/*

litemotiv · 2012-07-07 16:50:04

Same issue here:

% 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/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
error: cannot determine ownership of directory '/lib/modules'

falconindy · 2012-07-07 16:58:27

litemotiv wrote:

Same issue here:

error: cannot determine ownership of directory '/lib/modules'

Clean up that dir first...

litemotiv · 2012-07-07 17:05:23

falconindy wrote:

litemotiv wrote:
Same issue here:
error: cannot determine ownership of directory '/lib/modules'
Clean up that dir first...

Ok i moved the contents of modules, reissued the upgrade:

(1/2) upgrading glibc                                                                            [########################################################] 100%
error: extract: not overwriting dir with file lib
error: problem occurred while upgrading glibc
call to execv failed (No such file or directory)
error: command failed to execute correctly
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

System seems dead now, hmm...

ipha · 2012-07-07 17:12:53

Same thing happened to me. I had to mount my root partition elsewhere, remove /lib, and extract glibc-2.16.0-2-x86_64.pkg.tar.xz to the file system with tar.

progandy · 2012-07-07 17:25:33

Same thing here. Mostly it was due to virtualbox (modules from vboxbuild). There were also two packages from AUR (networkmanager-git and cpufreq-systemd)

progandy@PAMobile ~ % LANG=en_US pacman -Qo `find /lib` | grep -v glibc
error: cannot determine ownership of directory '/lib'
error: cannot determine ownership of directory '/lib/udev'
error: cannot determine ownership of directory '/lib/udev/rules.d'
error: cannot determine ownership of directory '/lib/modules'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.3-mainline'
error: No package owns /lib/modules/extramodules-3.3-mainline/vboxnetflt.ko.gz
error: No package owns /lib/modules/extramodules-3.3-mainline/vboxnetadp.ko.gz
error: No package owns /lib/modules/extramodules-3.3-mainline/vboxdrv.ko.gz
error: No package owns /lib/modules/extramodules-3.3-mainline/vboxpci.ko.gz
error: cannot determine ownership of directory '/lib/modules/extramodules-3.5-rc2-mainline'
error: No package owns /lib/modules/extramodules-3.5-rc2-mainline/vboxnetflt.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc2-mainline/vboxnetadp.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc2-mainline/vboxdrv.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc2-mainline/vboxpci.ko.gz
error: cannot determine ownership of directory '/lib/modules/extramodules-3.4-rc7-mainline'
error: No package owns /lib/modules/extramodules-3.4-rc7-mainline/vboxnetflt.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc7-mainline/vboxnetadp.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc7-mainline/vboxdrv.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc7-mainline/vboxpci.ko.gz
error: cannot determine ownership of directory '/lib/modules/3.1.2-1-ARCH'
error: cannot determine ownership of directory '/lib/modules/3.1.2-1-ARCH/updates'
error: cannot determine ownership of directory '/lib/modules/3.1.2-1-ARCH/updates/drivers'
error: cannot determine ownership of directory '/lib/modules/3.1.2-1-ARCH/updates/drivers/input'
error: cannot determine ownership of directory '/lib/modules/3.1.2-1-ARCH/updates/drivers/input/mouse'
error: cannot determine ownership of directory '/lib/modules/extramodules-3.4-rc5-mainline'
error: No package owns /lib/modules/extramodules-3.4-rc5-mainline/vboxnetflt.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc5-mainline/vboxnetadp.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc5-mainline/vboxdrv.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc5-mainline/vboxpci.ko.gz
error: cannot determine ownership of directory '/lib/modules/extramodules-3.5-rc1-mainline'
error: No package owns /lib/modules/extramodules-3.5-rc1-mainline/vboxnetflt.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc1-mainline/vboxnetadp.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc1-mainline/vboxdrv.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc1-mainline/vboxpci.ko.gz
error: cannot determine ownership of directory '/lib/modules/3.1.9-2-ARCH'
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ofmap
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ccwmap
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.usbmap
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.isapnpmap
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.pcimap
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.inputmap
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.seriomap
error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ieee1394map
error: cannot determine ownership of directory '/lib/modules/extramodules-3.5-rc4-mainline'
error: No package owns /lib/modules/extramodules-3.5-rc4-mainline/vboxnetflt.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc4-mainline/vboxnetadp.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc4-mainline/vboxdrv.ko.gz
error: No package owns /lib/modules/extramodules-3.5-rc4-mainline/vboxpci.ko.gz
error: cannot determine ownership of directory '/lib/modules/3.1.4-1-ARCH'
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.symbols
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.dep
error: cannot determine ownership of directory '/lib/modules/3.1.4-1-ARCH/updates'
error: cannot determine ownership of directory '/lib/modules/3.1.4-1-ARCH/updates/drivers'
error: cannot determine ownership of directory '/lib/modules/3.1.4-1-ARCH/updates/drivers/input'
error: cannot determine ownership of directory '/lib/modules/3.1.4-1-ARCH/updates/drivers/input/mouse'
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.alias
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.alias.bin
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.devname
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.symbols.bin
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.dep.bin
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.ofmap
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.softdep
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.ccwmap
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.usbmap
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.isapnpmap
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.pcimap
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.inputmap
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.seriomap
error: No package owns /lib/modules/3.1.4-1-ARCH/modules.ieee1394map
error: cannot determine ownership of directory '/lib/modules/3.1.9-1-ARCH'
error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ofmap
error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ccwmap
error: No package owns /lib/modules/3.1.9-1-ARCH/modules.usbmap
error: No package owns /lib/modules/3.1.9-1-ARCH/modules.isapnpmap
error: No package owns /lib/modules/3.1.9-1-ARCH/modules.pcimap
error: No package owns /lib/modules/3.1.9-1-ARCH/modules.inputmap
error: No package owns /lib/modules/3.1.9-1-ARCH/modules.seriomap
error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ieee1394map
error: cannot determine ownership of directory '/lib/modules/3.2.6-2-ARCH'
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.symbols
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.dep
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.builtin.bin
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.alias
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.alias.bin
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.devname
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.symbols.bin
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.dep.bin
error: No package owns /lib/modules/3.2.6-2-ARCH/modules.softdep
error: cannot determine ownership of directory '/lib/modules/extramodules-3.4-rc6-mainline'
error: No package owns /lib/modules/extramodules-3.4-rc6-mainline/vboxnetflt.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc6-mainline/vboxnetadp.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc6-mainline/vboxdrv.ko.gz
error: No package owns /lib/modules/extramodules-3.4-rc6-mainline/vboxpci.ko.gz
/lib/udev/rules.d/77-nm-olpc-mesh.rules is owned by networkmanager-git 20120701-1

Damn, I broke my system. Error: Could not replace directory /lib with file. glibc was removed, but not reinstalled. See you later.
Edit: Fixed with rescue cd. (remove /lib, extracte whole glibc-package to /, reboot, reinstall glibc)

Last edited by progandy (2012-07-07 19:30:47)

sl1pkn07 · 2012-07-07 19:23:39

EDIT: https://bbs.archlinux.org/viewtopic.php … 7#p1126667

much better

Last edited by sl1pkn07 (2012-07-08 15:59:26)

chetwisniewski · 2012-07-07 19:47:59

progandy wrote:

Same thing here. Mostly it was due to virtualbox (modules from vboxbuild). There were also two packages from AUR (networkmanager-git and cpufreq-systemd)
Damn, I broke my system. Error: Could not replace directory /lib with file. glibc was removed, but not reinstalled. See you later.
Edit: Fixed with rescue cd. (remove /lib, extracte whole glibc-package to /, reboot, reinstall glibc)

Same here. It worked, but was ugly. I also had the vbox modules. Seems like a common trip-up here.

HarD · 2012-07-07 21:13:59

I have same error:

One file /lib/ld-linux.so.2 owner lib32-glibc 2.16.0-1

I update first - lib32-glibc
And then glibc updated fine...

All is work - thanks for themes...

Cdh · 2012-07-07 21:56:58

mv /lib /libbackup

displaypicture?imageid=33968119&large=1

But seriously, that update will be a real pain.
You are probably aware that the issue is that the linker needs a library in /lib and no dynamically linked binary will work while replacing /lib. So for testing a but during that update it's a really good idea to have (a statically compiled) busybox and a copy of /lib around.

The main issue is having files in /lib/ that are not owned by glibc. That update will fail.

My first idea was to extract the necessary libraries first to /usr/lib and then replace /lib with a symlink. But that is not good for doing automatically since that assumes that the user has not done strange things to the linker on his/her system that this would overwrite.
Also it didn't work for me but that might be because I forgot to do ldconfig after that. And probably I would have had to set LD_LIBRARY_PATH to /usr/lib or even LD_PRELOAD to the linker libs.

I can imagine two big problems though:
1. Moving the contents of /lib/ to /usr/lib/ automatically might overwrite stuff in /usr/lib with duplicate named stuff in /lib. What if the user was intentionally doing strange stuff? It's the user's fault for doing strange stuff, sure, but it's still evil to just move files around and not really being sure if it's ok to overwrite one with the other.
2. /lib/modules. If your /lib/modules/your_kernel is a symlink to /usr/lib/modules/your_kernel and it is not properly handled you're gonna have a bad time on reboot.

Last edited by Cdh (2012-07-07 21:57:13)

progandy · 2012-07-07 22:04:43

You are probably aware that the issue is that the linker needs a library in /lib and no dynamically linked binary will work while replacing /lib. So for testing a but during that update it's a really good idea to have (a statically compiled) busybox and a copy of /lib around.

Most arch installations have the core-package mkinitcpio-busybox installed, so you can find a busybox in /usr/lib/initcpio/busybox ... Or not. It has a dependency on libc.so Maybe it works with a custom LD_LIBRARY_PATH?
Anyways, the community package is statically linked. Better safe than sorry

Last edited by progandy (2012-07-07 22:17:59)

Roken · 2012-07-07 23:13:49

OK - I got lucky that I read this thread first, so I expected my system to break and knew how to get up and running again, but....

I backed up /lib before removing and linking it because it contains several libraries that are not in /usr/lib (presumably from AUR packages). Now I'm up and running again, is it safe to copy those libs to /usr/lib?

EDIT:

And, because I manually installed the updated glibc pacman no longer knows about it. Is it safe to reinstall with --force after applying the fix?

Last edited by Roken (2012-07-07 23:20:29)

progandy · 2012-07-07 23:38:55

Roken wrote:

OK - I got lucky that I read this thread first, so I expected my system to break and knew how to get up and running again, but....
I backed up /lib before removing and linking it because it contains several libraries that are not in /usr/lib (presumably from AUR packages). Now I'm up and running again, is it safe to copy those libs to /usr/lib?

I suppose.

And, because I manually installed the updated glibc pacman no longer knows about it. Is it safe to reinstall with --force after applying the fix?

Try a normal reinstall without --force first. I got no errors.

If someone has yet to update glibc, could you try this (no rescue cd needed)
1) install busybox
2) clean and backup /lib, /lib64, /lib32,
3) open a root busybox shell to fix problems lateron (sudo busybox sh)
4) upgrade glibc
5) error should appear
6) use shell from 3) to remove empty /lib and set link to /usr/lib
7) reinstall glibc

Last edited by progandy (2012-07-07 23:40:35)

falconindy · 2012-07-07 23:47:18

A few things to note...

1) If you find yourself in a position to recreate the symlink yourself, the link target is usr/lib and not /usr/lib. This is an important difference that's only evident in a chroot situation.
2) The linker is an interpreter, just like /bin/bash. If it exists on the system but the /lib symlink is missing/fubar, you can run ELF binaries directly via the linker, e.g. /usr/lib/ld-2.16.so /bin/ln -s ....

Roken · 2012-07-08 00:18:23

progandy wrote:

Try a normal reinstall without --force first. I got no errors.

I tried, and got errors. Done a forced reinstall and rebooted. Everything seems fine.

I'll wait re the libraries. On examination I have some links from /usr/lib back to /lib, so reckon I'll wait and see what's broken before I take any action on them.

Last edited by Roken (2012-07-08 00:19:54)

felixonmars · 2012-07-08 01:52:17

Thanks a lot to:

falconindy wrote:

A few things to note...
1) If you find yourself in a position to recreate the symlink yourself, the link target is usr/lib and not /usr/lib. This is an important difference that's only evident in a chroot situation.
2) The linker is an interpreter, just like /bin/bash. If it exists on the system but the /lib symlink is missing/fubar, you can run ELF binaries directly via the linker, e.g. /usr/lib/ld-2.16.so /bin/ln -s ....

I ran into the same issue with

litemotiv wrote:

falconindy wrote:

litemotiv wrote:
Same issue here:
error: cannot determine ownership of directory '/lib/modules'
Clean up that dir first...

Ok i moved the contents of modules, reissued the upgrade:

(1/2) upgrading glibc                                                                            [########################################################] 100%
error: extract: not overwriting dir with file lib
error: problem occurred while upgrading glibc
call to execv failed (No such file or directory)
error: command failed to execute correctly
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

System seems dead now, hmm...

The problem of mine: I have not a root terminal opened, root password is disabled, and I cannot use ld-2.16.so to load sudo.

Then I did the following steps to bring my machine back to live, hope this helps someone else

1. reboot, edit the line starting with linux(or kernel) in grub, add:

init=/usr/lib/ld-2.16.so /bin/sh

2. remount the disk rw:

/usr/lib/ld-2.16.so /bin/mount -o remount,rw /

3. remove the EMPTY(yes, the error above will leave it empty) /lib folder:

/usr/lib/ld-2.16.so /bin/rmdir /lib

4. ln /usr/lib to /lib:

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

5. press ctrl-alt-del to reboot the machine, and re-install glibc using pacman.

Then everything is back to normal, without using a rescue cd

Last edited by felixonmars (2012-07-08 02:03:40)

hexchain · 2012-07-08 15:06:46

Thank you cat @felixonmars, you saved my day. You are f***ing awesome.

Last edited by hexchain (2012-07-08 15:14:35)

PAdu92 · 2012-07-08 18:03:09

SORRY FIXeD...

Last edited by PAdu92 (2012-07-08 18:16:20)

Arogers10 · 2012-07-09 16:47:50

So I was still having this problem today and all I had to do was place glibc under IGNORE in /etc/pacman.conf. Then I upgraded all of the other packages that wanted to be upgraded with glibc with pacman -Syu. Then I commented out the Ignore list in pacman.conf and did pacman -Syu again and glibc installed flawlessly. It seems the install required one of the other packages to be upgraded first

martinjlowm · 2012-07-09 21:08:36

I went on and used the rescue disc.

# mkdir /fs
# mount /dev/sda3 /fs
# mv /fs/lib /fs/libbak
# pacman -Syr /fs glibc

You decide whether you need the old libraries in /libbak. sda3 is my root partition.

Last edited by martinjlowm (2012-07-09 21:09:18)

ngoonee · 2012-07-09 23:39:57

Arogers10 wrote:

So I was still having this problem today and all I had to do was place glibc under IGNORE in /etc/pacman.conf. Then I upgraded all of the other packages that wanted to be upgraded with glibc with pacman -Syu. Then I commented out the Ignore list in pacman.conf and did pacman -Syu again and glibc installed flawlessly. It seems the install required one of the other packages to be upgraded first

Wouldn't it have been much easier to use the --ignore flag?

Arogers10 · 2012-07-10 08:24:32

Wouldn't it have been much easier to use the --ignore flag?

yeah probably... I'm still new to pacman so I haven't reviewed the tags yet

padster · 2012-07-11 00:48:48

@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

loafer · 2012-07-11 03:44:28

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

Arch Linux

#1 2012-07-07 16:38:35

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

#2 2012-07-07 16:44:51

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

#3 2012-07-07 16:50:04

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

#4 2012-07-07 16:58:27

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

#5 2012-07-07 17:05:23

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

#6 2012-07-07 17:12:53

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

#7 2012-07-07 17:25:33

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

#8 2012-07-07 19:23:39

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

#9 2012-07-07 19:47:59

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

#10 2012-07-07 21:13:59

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

#11 2012-07-07 21:56:58

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

#12 2012-07-07 22:04:43

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

#13 2012-07-07 23:13:49

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

#14 2012-07-07 23:38:55

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

#15 2012-07-07 23:47:18

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

#16 2012-07-08 00:18:23

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

#17 2012-07-08 01:52:17

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

#18 2012-07-08 15:06:46

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

#19 2012-07-08 18:03:09

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

#20 2012-07-09 16:47:50

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

#21 2012-07-09 21:08:36

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

#22 2012-07-09 23:39:57

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

#23 2012-07-10 08:24:32

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

#24 2012-07-11 00:48:48

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

#25 2012-07-11 03:44:28

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

Board footer