You are not logged in.
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?
PGP key: 30D7CB92
Key fingerprint: B597 1F2C 5C10 A9A0 8C60 030F 786C 63F3 30D7 CB92
Offline
do not --force.
do pacman -Qo /lib/*
Give what you have. To someone, it may be better than you dare to think.
Offline
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'
ᶘ ᵒᴥᵒᶅ
Offline
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...
ᶘ ᵒᴥᵒᶅ
Offline
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.
Offline
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)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
EDIT: https://bbs.archlinux.org/viewtopic.php … 7#p1126667
much better
Last edited by sl1pkn07 (2012-07-08 15:59:26)
Offline
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.
Offline
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...
Offline
mv /lib /libbackup
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)
฿ 18PRsqbZCrwPUrVnJe1BZvza7bwSDbpxZz
Offline
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)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
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)
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
/ is the root of all problems.
Offline
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)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
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 ....
Offline
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)
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
/ is the root of all problems.
Offline
Thanks a lot to:
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
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)
PGP key: 30D7CB92
Key fingerprint: B597 1F2C 5C10 A9A0 8C60 030F 786C 63F3 30D7 CB92
Offline
Thank you cat @felixonmars, you saved my day. You are f***ing awesome.
Last edited by hexchain (2012-07-08 15:14:35)
Offline
SORRY FIXeD...
Last edited by PAdu92 (2012-07-08 18:16:20)
Offline
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
Offline
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)
Offline
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?
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
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
Offline
@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
Offline
@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
All men have stood for freedom...
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.
Offline