You are not logged in.
I somehow broke my system when trying to upgrade it (the glibc and /lib stuff). I am now trying to repair my system by booting from a live-cd and using chroot as described in the Change Root ArchWiki. I follow the instructions and mount everything, but when I'm about to chroot i get this:
/bin/bash: /lib/libc.so.6: version 'GLIBC_2.15' not found (required by /bin/bash)How can I try to repair the system when I can't get into it?
Edit: I managed to find an 2.15 version of the file libc.so.6 and replaced the one in /lib and now I can boot the system as normal, but I still have troubles upgrading glibc. I have reinstalled the 2.15-12 version of glibc using the package from my pacman cache.
A pacman -Su gives me:
error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
glibc: /usr/lib/libnss_compat.so.2 exists in filesystemWhen I use the find command (according to the arch website) to see the owner of the files in /lib - every file is owned by glibc 2.15-12 except libc.so.6 that isn't owned by any package.
I have been reading forum posts for hours now and I haven't got a clue on how to proceed.
Last edited by mindglowba7fb830d2cbbed73 (2012-08-21 21:51:44)
Offline
How can I try to repair the system when I can't get into it?
Try pacman -r /mnt/dir/some/where -Su
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
You'll have to say more about how you broke it, I think. It isn't obvious what state your system is in from the errors. How did you install the .so you found because pacman doesn't know about it...? And who owns /usr/lib/libnss_compat.so.2? And did you run the grep command also given in the wiki? You need that to figure out what to do about /lib.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Ok I will try to specify everything. At first I got the common "glibc: /lib exists in filesystem" while trying to update system with pacman, so I did 'pacman -Sy --ignore glibc' and updated everything else. When trying to run pacman again I still got the "/lib exists in filesystem" so I read the DeveloperWiki:usrlib and tried to do everything it specifies.
Since I found out that some files in /lib didn't belong to any package I tried to remove them so that only files belonging to glibc were left. I think this is when I removed libc.so.6 by mistake. This made the system break and I had to boot from a LiveCD, I found a version of libc.so.6 online that is from the same version as the one that is installed so I just moved it to /lib and the system is now bootable again.
The problem now is that all files in /lib belong to glibc - except libc.so.6 that isn't owned by any package. I have reinstalled the same version of glibc (2.15-12) but the libc.so.6 still doesnt belong to any package.
I think this is the problem and why I cant update glibc. The problem is that I can't remove libc.so.6 from /lib because it breaks the system completely, and I cant uninstall glibc.
The system is bootable and working now but a lot of applications are not working since they depend on glibc 2.16 and I have 2.15-12 installed.
Offline
Did you get any errors when you reinstalled glibc? I would expect that to also complain about libc.so.6 existing - assuming it really is part of the same version of glibc.
OK. In 2.15.12 glibc, /lib/libc.so.6 should be a symbolic link to libc-2.15.so. Is that what you've got?
By the way, you didn't need to download anything unless you've cleared out pacman's cache. Packages are kept in /var/cache/pacman/pkg. (That's where I just fished version 2.15.12 from.) Note that I'm using the 64 bit arch but I imagine the symbolic link would be similar for i686. (But I don't know this.)
If the package still exists, try:
# obviously replace the x86_64 if your architecture is different from mine
pacman -U /var/cache/pacman/pkg/glibc-2.15-12-x86_64.pkg.tar.xzIf it complains that libc.so.6 already exists, I think I would try:
# obviously replace the x86_64 if your architecture is different from mine
pacman --force -U /var/cache/pacman/pkg/glibc-2.15-12-x86_64.pkg.tar.xzIMPORTANT: do NOT force the upgrade. I am ONLY suggesting forcing the reinstall of your currently installed version of the package. This should be safe because it will only overwrite files which already exist with identical files. The only change should be that pacman will now regard the files as legitimately owned by glibc and should (hopefully) then let you update. You need to be SURE that this IS the currently installed version of the package though. Check and double-check. And, again, only use force for the reinstall of this one particular package. All you want to force is the ownership of the files. You don't want to actually force the install or upgrade of anything whatsoever.
Last edited by cfr (2012-08-20 22:02:45)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Did you get any errors when you reinstalled glibc? I would expect that to also complain about libc.so.6 existing - assuming it really is part of the same version of glibc.
No I don't get any errors when reinstalling glibc.
OK. In 2.15.12 glibc, /lib/libc.so.6 should be a symbolic link to libc-2.15.so. Is that what you've got?
Yes 'file libc.so.6' gives:
libc.so.6: symbolic link to 'libc-2.15.so'If the package still exists, try:
# obviously replace the x86_64 if your architecture is different from mine pacman -U /var/cache/pacman/pkg/glibc-2.15-12-x86_64.pkg.tar.xz
Yeah I did this and it works without any errors.
I just noticed that when i do this:
$ find /lib -exec pacman -Qo -- {} +I get a list of all the files that are owned by glibc 2.15-12 but I also get this:
error: No package owns /lib/libc.so.6but a bit further down in the list:
/lib/libc.so.6 is owned by glibc 2.15-12It's the same file?
Last edited by mindglowba7fb830d2cbbed73 (2012-08-20 22:59:46)
Offline
That sounds really weird. What does:
pacman -Qo /lib/libc.so.6give? (Or did you say this already?)
The only thing I can think is that pacman is reporting the ownership of both the symbolic link (none?) and the target of that link (glibc) but I really don't know...
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
That sounds really weird. What does:
pacman -Qo /lib/libc.so.6give? (Or did you say this already?)
That gives this:
/lib/libc.so.6 is owned by glibc 2.15-12The only thing I can think is that pacman is reporting the ownership of both the symbolic link (none?) and the target of that link (glibc) but I really don't know...
Yeah that was what I was thinking as well but I haven't got the slightest clue on how to fix it.
Offline
What does:
ls -l /lib/libc.so.6give _exactly_?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
What does:
ls -l /lib/libc.so.6give _exactly_?
lrwxrwxrwx 1 root root 12 Jun 9 08:13 /lib/libc.so.6 -> libc-2.15.soOffline
Looks right...
The only other thing I can suggest is to boot from a live Arch install media, to mount your system somewhere, delete the symlink and then reinstall glibc 2.15-12 from the cache. Don't try this without booting from the live media and don't chroot because removing the symlink will break things quite badly. But you should be able to use the pacman from the live media to reinstall the package from cache using pacman's -r option. (See the wiki page if you need details.) Pacman will surely have to admit glibc owns the link after that...
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Looks right...
The only other thing I can suggest is to boot from a live Arch install media, to mount your system somewhere, delete the symlink and then reinstall glibc 2.15-12 from the cache. Don't try this without booting from the live media and don't chroot because removing the symlink will break things quite badly. But you should be able to use the pacman from the live media to reinstall the package from cache using pacman's -r option. (See the wiki page if you need details.) Pacman will surely have to admit glibc owns the link after that...
I did all this and it seems to work without any problems, but booting into the system again and try to update glibc gives me this:
error: failed to commit transaction (conflicting files)
glibc: /usr/lib/ld-linux.so.2 exists in filesystem
glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
glibc: /usr/lib/libanl.so.1 exists in filesystem
glibc: /usr/lib/libc.so.6 exists in filesystem
glibc: /usr/lib/libcidn.so.1 exists in filesystem
glibc: /usr/lib/libcrypt.so.1 exists in filesystem
glibc: /usr/lib/libdl.so.2 exists in filesystem
glibc: /usr/lib/libm.so.6 exists in filesystem
glibc: /usr/lib/libnsl.so.1 exists in filesystem
glibc: /usr/lib/libnss_compat.so.2 exists in filesystem
glibc: /usr/lib/libnss_db.so.2 exists in filesystem
glibc: /usr/lib/libnss_dns.so.2 exists in filesystem
glibc: /usr/lib/libnss_files.so.2 exists in filesystem
glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem
glibc: /usr/lib/libnss_nis.so.2 exists in filesystem
glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem
glibc: /usr/lib/libpthread.so.0 exists in filesystem
glibc: /usr/lib/libresolv.so.2 exists in filesystem
glibc: /usr/lib/librt.so.1 exists in filesystem
glibc: /usr/lib/libutil.so.1 exists in filesystem
Errors occurred, no packages were upgraded.Offline
OK. So it is no longer complaining about files in /lib?
Have you got _two_ versions of glibc installed?
You did reinstall the 2.15-12 version of glibc, right? You didn't upgrade it by mistake?
What does
pacman -Ql glibcgive?
Who owns the files in /usr/lib which pacman complains about when you try to upgrade?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
OK. So it is no longer complaining about files in /lib?
No only files in /usr/lib
Have you got _two_ versions of glibc installed?
I don't know but I can't see how that would have happened.
You did reinstall the 2.15-12 version of glibc, right? You didn't upgrade it by mistake?
Yes i reinstalled the 2.15-12 version.
What does
pacman -Ql glibcgive?
Who owns the files in /usr/lib which pacman complains about when you try to upgrade?
None of these files are owned by any packages.
Offline
EDIT: scratch what I wrote before if you happened to read it. It's wrong.
I am fairly lost at this point.
I would be tempted to move the files pacman is complaining about to a backup directory if pacman is sure they aren't owned. However, I'm not sure about this. Certainly don't do it without the live media to boot from if things break. (Then you can always boot from the media and move them back.)
Last edited by cfr (2012-08-21 21:27:16)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I did exactly that, moved all files that pacman were complaining about to a temporary directory, and then did a pacman -Su - and whoa, everything worked ![]()
I'm happy that it is all solved, and thank you so much for the help, even though i haven't got a clue what went wrong to begin with.
Offline
Wonderful! I'm not entirely sure how that happened... either what went wrong or what exactly finally went right... ![]()
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline