Re: [arch-general] Still Glibc problems
On Sat, Jul 21, 2012 at 02:11:00PM -0700, David Benfell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/12 15:34, John Briggs wrote: General Discussion about Arch Linux arch-general@archlinux.org On Fri, Jul 20, 2012 at 03:41:08PM -0600, D. R. Evans wrote: pacman -Su Not OK: [root@shack n7dr]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 33.94 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@shack n7dr]# After much investigation the only workaround for this problem I could discover and I have used on my three computers this week is: system reboot : updates system with new packages. This : step is critical or you could end up with : a borked system # pacman -Sfu : This forces the loading of glibc-2.16.0-2 : but errors out because /lib directory exists ignore errors : on the system. # /usr/lib/ld-2.16.0.so /bin/rm -r /lib /usr/lib/ld-2.16.so # /usr/lib/ld-2.16.0.so /bin/ln -s /usr/lib /lib /usr/lib/ld-2.16.so system reboot DANGER: If the above procedure is not followed exactly you can bork your system and it will need a complete rebuild. An other workaround is: # system reboot # pacman -Sfu Ignore errors use a live CD/USB and boot Linux. # mkdir /archroot # mount /dev/ /archroot : where is the root partition # cd /archroot /archroot]# rm -r lib /archroot]# ln -s usr/lib ./lib system reboot HTH John PS: I have not read the complete thread so I do not know if someone else has already offered these solutions. JEB You're using some tricks I didn't know about (there are, I'm sure, lots in that category), but I don't see how this procedure addresses the problem of other packages having files in /lib. It doesn't I didn't have other packages having files in /lib. One of my machines uses wifi and I had to update the carl9170-fw package so it was installed to /usr/lib. The residual entries in /lib was the modules and firmware directories. I was only seeking to get these systems working not on why they weren't according to the news. I followed the links to manual installation and got most of my information from there and I followed most of the sublinks too. I made an error in the above procedures: all instance of /usr/lib/ld-2.26.0.so should be replaced with /usr/lib/ld-2.16.so The system reboot is the critical step as it sets the system into a known configuration and prevent it from borking on the next step. If it is critical to know what packages are causing the problems use # pacman -Sfu and see whats left in the /lib directory or subdirectories. You'll probably find its the proprietary drivers that you use. Regards John
Re: [arch-general] Still Glibc problems
General Discussion about Arch Linux arch-general@archlinux.org On Fri, Jul 20, 2012 at 03:41:08PM -0600, D. R. Evans wrote: pacman -Su Not OK: [root@shack n7dr]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 33.94 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@shack n7dr]# After much investigation the only workaround for this problem I could discover and I have used on my three computers this week is: system reboot : updates system with new packages. This : step is critical or you could end up with : a borked system # pacman -Sfu : This forces the loading of glibc-2.16.0-2 : but errors out because /lib directory exists ignore errors : on the system. # /usr/lib/ld-2.16.0.so /bin/rm -r /lib # /usr/lib/ld-2.16.0.so /bin/ln -s /usr/lib /lib system reboot DANGER: If the above procedure is not followed exactly you can bork your system and it will need a complete rebuild. An other workaround is: # system reboot # pacman -Sfu Ignore errors use a live CD/USB and boot Linux. # mkdir /archroot # mount /dev/ /archroot : where is the root partition # cd /archroot /archroot]# rm -r lib /archroot]# ln -s usr/lib ./lib system reboot HTH John PS: I have not read the complete thread so I do not know if someone else has already offered these solutions. JEB
Re: [arch-general] Still Glibc problems
Norbert Zeh said the following at 07/20/2012 05:34 PM : pacman -Su Not OK: [root@shack n7dr]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 33.94 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. I got the same error at that point. What this means is that you either have some unowned (by any package) files in /lib (/lib/modules/* is a good candidate) or you have some other packages (most likely from AUR) owning files under /lib. The wiki page explains well how to look for them. At least, I followed those instructions and managed to identify the packages that blocked the upgrade. The key here really seems to be to make sure that glibc is the only package which at this point owns anything under /lib. I think in my case it also helped to uninstall some packages and reinstall them after the glibc upgrade. Keep pushing, you're almost there ;) The instructions (as so often) are not clear. If after this the pacman -Su still has conflicts with /lib, this is likely because a package on your system other than glibc owns files in /lib. Such packages can be detected using: $ grep '^lib/' /var/lib/pacman/local/*/files So this gives: root@shack tmp]# grep '^lib/' /var/lib/pacman/local/*/files /var/lib/pacman/local/glibc-2.15-10/files:lib/ /var/lib/pacman/local/glibc-2.15-10/files:lib/ld-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/ld-linux.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libBrokenLocale-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libBrokenLocale.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libSegFault.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libanl-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libanl.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libc-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libc.so.6 /var/lib/pacman/local/glibc-2.15-10/files:lib/libcidn-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libcidn.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libcrypt-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libcrypt.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libdl-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libdl.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libm-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libm.so.6 /var/lib/pacman/local/glibc-2.15-10/files:lib/libmemusage.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnsl-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnsl.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_compat-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_compat.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_db-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_db.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_dns-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_dns.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_files-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_files.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_hesiod-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_hesiod.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nis-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nis.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nisplus-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nisplus.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libpcprofile.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libpthread-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libpthread.so.0 /var/lib/pacman/local/glibc-2.15-10/files:lib/libresolv-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libresolv.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/librt-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/librt.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libthread_db-1.0.so
Re: [arch-general] Still Glibc problems
Maybe I'm missing an instruction somewhere, but I don't see it.
Doc
My reading comprehension may be lacking, but did you check to see if
there are any files in /lib that are *not* owned by any package?
find /lib -exec pacman -Qo -- {} +
Commonly there are some directories like /lib/modules or in my case a
stray udev file that didn't get cleaned up automatically.
Ariel
Re: [arch-general] Still Glibc problems
On Sat, Jul 21, 2012 at 4:57 PM, D. R. Evans doc.ev...@gmail.com wrote: I *think* that this means that in fact glibc owns all the files. It means that no other package owns any files. It might still be that there are files in /lib that are not owned by any package. pacman -Qo /lib/* should tell you (or simply ls /lib and compare with the list you pasted in your previous email). -t
Re: [arch-general] Still Glibc problems
Ariel Popper said the following at 07/21/2012 09:24 AM :
My reading comprehension may be lacking, but did you check to see if
there are any files in /lib that are *not* owned by any package?
find /lib -exec pacman -Qo -- {} +
Commonly there are some directories like /lib/modules or in my case a
stray udev file that didn't get cleaned up automatically.
Ariel
I concluded that I should just cross my fingers and delete /lib/modules. That
worked. Thank you to everyone for helping me with this. Sorry it took so long.
Doc
--
Web: http://www.sff.net/people/N7DR
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
On 07/21/2012 11:24 AM, Tom Gundersen wrote:
On Sat, Jul 21, 2012 at 4:57 PM, D. R. Evans doc.ev...@gmail.com wrote:
I *think* that this means that in fact glibc owns all the files.
It means that no other package owns any files. It might still be that
there are files in /lib that are not owned by any package. pacman -Qo
/lib/* should tell you (or simply ls /lib and compare with the list
you pasted in your previous email).
-t
find /lib -exec pacman -Qo -- {} + 21 | grep 'No package'
Re: [arch-general] Still Glibc problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/12 15:34, John Briggs wrote: General Discussion about Arch Linux arch-general@archlinux.org On Fri, Jul 20, 2012 at 03:41:08PM -0600, D. R. Evans wrote: pacman -Su Not OK: [root@shack n7dr]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 33.94 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@shack n7dr]# After much investigation the only workaround for this problem I could discover and I have used on my three computers this week is: system reboot : updates system with new packages. This : step is critical or you could end up with : a borked system # pacman -Sfu : This forces the loading of glibc-2.16.0-2 : but errors out because /lib directory exists ignore errors : on the system. # /usr/lib/ld-2.16.0.so /bin/rm -r /lib # /usr/lib/ld-2.16.0.so /bin/ln -s /usr/lib /lib system reboot DANGER: If the above procedure is not followed exactly you can bork your system and it will need a complete rebuild. An other workaround is: # system reboot # pacman -Sfu Ignore errors use a live CD/USB and boot Linux. # mkdir /archroot # mount /dev/ /archroot : where is the root partition # cd /archroot /archroot]# rm -r lib /archroot]# ln -s usr/lib ./lib system reboot HTH John PS: I have not read the complete thread so I do not know if someone else has already offered these solutions. JEB You're using some tricks I didn't know about (there are, I'm sure, lots in that category), but I don't see how this procedure addresses the problem of other packages having files in /lib. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCxrjAAoJELT202JKF+xpmCEP+wTlt5/a3ZRgtZT+1/ZsBT97 XNFK4QTOaq3bb+kHO1pMkarvq3e52GoSIMGysqRSWAhiqeZ40aOwqDcpUmdpB7VM fqLeY/0izJmR9lsbSAKiyH3JvjzdcLUdR/qJnTkihOY+MzO9QwOtNrn+QzoT26yo +SJvoDGPjOisgL+sPuK8QfZP1ET4Avu4xxI7bv+kGAJj6QNLvMf5Kj30GF1d8a0/ F0cxKRV55cR9pthTx9SLceOhyB/IPMWQBfj7Ng2ONXoJpkQF5+/3BahDBjXV5h9R c5zlNt0nC8ckucyGcstVq9eKCIAfrBxtq+k995Ty6ZQEJfwUnTRYkU61YeN4NZxT olMIWMbqyF5YnaEDEsQ75x1m/9BwVz4c2HDs7Exe6yCk3+HNGN4opTjyU7n62zvl CWu/UFzoU+TcmsqBK7tklE1R7JdwjY8z/zVRHl8cL+kw/PM2yJqZxnuVjTv2vGDL x0fc8MFGpa0HGdBmOP0IqglbW6AzqY89TXiG1prhGAzUZFAsqSgAAkK1isIwKa1P 4msQz/9KGftEjIEtUTXJ4GqCc02HTHYM4bJno0d47EA2bJNnkoFGvNkYKc00eFxE Zf6I+pkd/6RQTa3vixMsFTVV+TgZb1CIqg91rrDYfdxv/ICKqoGSUTsLuEt7QSXd yf6dLhAvtCh4cH2dRiqK =R7sP -END PGP SIGNATURE-
Re: [arch-general] Still Glibc problems
Guus Snijders said the following at 07/20/2012 04:13 AM : I'm a bit confused at this point if filesystem is now upgraded or not. Your confusion can't possibly be as great as mine :-) There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( If i understand correctly, the symlinks for /var/run and /var/lock are there already. Yes. If fileystem is not yet upgraded, what might just work is to restore I don't know what you mean by the filesystem is not yet upgraded. Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
Norbert Zeh said the following at 07/19/2012 06:08 PM : Well, the filesystem instructions are older and applied at the time the glibc upgrade was not an issue yet. Combining the two instructions, I would guess the following should work: pacman -Syu --ignore filesystem --ignore glibc pacman -S --force filesystem --ignore glibc pacman -Sd everything you couldn't upgrade due to ignored glibc Incidentally, this is quite a long list. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest that the list will contain only a few items, but the actual number is of the order a couple of dozen packages. pacman -Su Note that I did not try this, but it seems to be the logical combination of the two. Maybe one of the developers can chime in and confirm that this is the right strategy. I am rather reticent to try something untested, especially when I see the --force option in use. So yes, PLEASE, can a developer address this issue so that I can have more confidence that I won't end up with a hosed system. (I am very puzzled as to why this is happening at all. This is not a system to which anything fancy has ever been done. If I'm having this problem, I don't know why lots of others aren't seeing it too.) Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
On Fri, Jul 20, 2012 at 12:13 PM, Guus Snijders gsnijd...@gmail.com wrote: I'm a bit confused at this point if filesystem is now upgraded or not. If i understand correctly, the symlinks for /var/run and /var/lock are there already. You should always have the symlink, regardless of whether or not filesystem is up-to-date (read the news item again, it is explained there). The difference is that with the new filesystem package, the symlinks are owned by the package as they should be, rather than not having any owner at all. To check if your pacakge is up-to-date, you can simply do pacman -Qi filesystem and it will tell you. If fileystem is not yet upgraded, what might just work is to restore the previous state: delete /var/run and /var/lock (the symlinks), re-create them as directories and then install filesystem again. That way the situation is exactly as filesystem expects and the upgrade should go smoothly without --force. This seems wrong. Please re-read the filesystem news announcement. There should never be any reason to replace the symlinks by directories, that will not help at all. Notice that if you are in the situation that you have to force a filesystem upgrade, make sure you force only that, and nothing else (in particular not glibc). I /think/ the same goes for glibc, although i'm not sure about that one. If /lib is already a symlink but the package doesn't install, the safest procedure would appear to be something like: - boot from livecd - mount the local filesystems - delete the /lib symlink and create the /lib directory - use pacmans's --root parameter to update glibc No point in creating a /lib directory. If you are booting from a live-cd, all you should have to do is: uninstall all pacakges that cause file-conflicts; delete (or move out of the way) all files that are not owned by any packages and cause file conflicts; install glibc; and finally reinstall whatever packages you had to remove (though if you had to remove them that probably means that there is something wrong with them, all official packages have been updated to not need removing). Both are untested, though. I suggest to anyone who still have problems, to first try the guide on the wiki, if that does not work, find one of the guides on the forum (but first check that other commenters are confirming that they are correct). -t
Re: [arch-general] Still Glibc problems
On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans doc.ev...@gmail.com wrote: There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any stale packages or re-enable any repos so you get all the most recent updates. Lastly, AUR is user-maintained so could contain anything at all (i.e. it is not surprising that they are causing problems). I'd suggest just removing all packages from the AUR for the time being, and once the update has succeeded you can reinstall them. -t
Re: [arch-general] Still Glibc problems
On Fri, Jul 20, 2012 at 4:27 PM, D. R. Evans doc.ev...@gmail.com wrote: Norbert Zeh said the following at 07/19/2012 06:08 PM : Well, the filesystem instructions are older and applied at the time the glibc upgrade was not an issue yet. Combining the two instructions, I would guess the following should work: pacman -Syu --ignore filesystem --ignore glibc [and ignore any other packages that block the upgrade] pacman -S --force filesystem --ignore glibc pacman -Sd everything you couldn't upgrade due to ignored glibc Looks good to me. Incidentally, this is quite a long list. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest that the list will contain only a few items, but the actual number is of the order a couple of dozen packages. That's surprising that it is so many, however, it appears you haven't updated this system in some time which might explain that it is different to what most people are seeing. -t
Re: [arch-general] Still Glibc problems
On 07/20/2012 10:27 AM, D. R. Evans wrote: Norbert Zeh said the following at 07/19/2012 06:08 PM : Well, the filesystem instructions are older and applied at the time the glibc upgrade was not an issue yet. Combining the two instructions, I would guess the following should work: pacman -Syu --ignore filesystem --ignore glibc pacman -S --force filesystem --ignore glibc pacman -Sd everything you couldn't upgrade due to ignored glibc Incidentally, this is quite a long list. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest that the list will contain only a few items, but the actual number is of the order a couple of dozen packages. pacman -Su Note that I did not try this, but it seems to be the logical combination of the two. Maybe one of the developers can chime in and confirm that this is the right strategy. I am rather reticent to try something untested, especially when I see the --force option in use. So yes, PLEASE, can a developer address this issue so that I can have more confidence that I won't end up with a hosed system. (I am very puzzled as to why this is happening at all. This is not a system to which anything fancy has ever been done. If I'm having this problem, I don't know why lots of others aren't seeing it too.) Doc I had this problem on the few remaining arch desktop boxes that I admin. I fixed those by installing Fedora 17, the server boxes were fixed by my own distro...LFS and pacman-3.3.3 as the package manager.
Re: [arch-general] Still Glibc problems
On 07/20/2012 10:47 AM, Tom Gundersen wrote: On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans doc.ev...@gmail.com wrote: There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any stale packages or re-enable any repos so you get all the most recent updates. I had a desktop system hosed that only packages in core, extra and community installed.
Re: [arch-general] Still Glibc problems
On Jul 20, 2012 6:08 PM, Baho Utot baho-u...@columbus.rr.com wrote: On 07/20/2012 10:47 AM, Tom Gundersen wrote: On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans doc.ev...@gmail.com wrote: There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any stale packages or re-enable any repos so you get all the most recent updates. I had a desktop system hosed that only packages in core, extra and community installed. I never heard of anyone actually hosing their system without using --force. What happened? (I'm assuming you don't use testing?). -t
Re: [arch-general] Still Glibc problems
Op 20 jul. 2012 16:21 schreef D. R. Evans doc.ev...@gmail.com het volgende: Guus Snijders said the following at 07/20/2012 04:13 AM : [...] If i understand correctly, the symlinks for /var/run and /var/lock are there already. Yes. If fileystem is not yet upgraded, what might just work is to restore I don't know what you mean by the filesystem is not yet upgraded. My apologies, i meant the package filesystem there. I understand now that in your current situation a forced install of the package filesystem would be safe. I guess it would be wise to wait with the glibc package until everything else is updated and the box rebooted (just to be sure). I'm not a big fan of rebooting, but in this case ;-) Hope that helpes. Mvg, Guus
Re: [arch-general] Still Glibc problems
D. R. Evans [2012.07.20 0827 -0600]: Norbert Zeh said the following at 07/19/2012 06:08 PM : Well, the filesystem instructions are older and applied at the time the glibc upgrade was not an issue yet. Combining the two instructions, I would guess the following should work: pacman -Syu --ignore filesystem --ignore glibc pacman -S --force filesystem --ignore glibc pacman -Sd everything you couldn't upgrade due to ignored glibc Incidentally, this is quite a long list. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest that the list will contain only a few items, but the actual number is of the order a couple of dozen packages. pacman -Su Note that I did not try this, but it seems to be the logical combination of the two. Maybe one of the developers can chime in and confirm that this is the right strategy. I am rather reticent to try something untested, especially when I see the --force option in use. So yes, PLEASE, can a developer address this issue so that I can have more confidence that I won't end up with a hosed system. (I am very puzzled as to why this is happening at all. This is not a system to which anything fancy has ever been done. If I'm having this problem, I don't know why lots of others aren't seeing it too.) I got a fairly long list of packages I had to ignore in the first run, too, and I had a few unowned files in /lib I had to clean out. It all worked very well following the instructions on the wiki, though. So no complaints at all. I think the reason why you are having a much more serious issue is that it seems you haven't updated your system in a long time. So now you're running into dealing with two slightly tricky upgrades (filesystem + glibc) at the same time. I upgrade packages very frequently. So I dealt with the filesystem upgrade a few weeks ago, and all went smoothly. Having an up-to-date filesystem package, the upgrade of glibc was also fairly straightforward, even if it involved quite a bit of manual intervention. I think the lesson to be learned here is that not upgrading packages on an arch box for a long time is not the best idea, and I think most arch users do upgrade quite frequently. Cheers, Norbert
Re: [arch-general] Still Glibc problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/12 07:47, Tom Gundersen wrote: On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans doc.ev...@gmail.com wrote: There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any stale packages or re-enable any repos so you get all the most recent updates. This is one thing I found I had to do. It's certainly fast enough. I just removed these packages prior to the upgrade and reinstalled them afterwards. Once the sym-link for /lib is in place, everything lands in the right place. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCb36AAoJELT202JKF+xpe9MQAJatGuaBy5xCXeeTsxJTisZp uUQQNxrlj7ChsNgSLn97ebdZUBCYNsBwKvYQYrpOaR7mct/Wnco7NmzflH5QgWb5 D2mG4UQFhALEXeSLdSn09+Cfl/T1FJTiBmUHdwuTC1s3GykKX4r/ev9VhC9FBqXL mttQJfoNiq73CasWz1L9LcRzXwD4HCkH/Cnf5arxGFMcJfVyVVzzq9Z1V8ZKXh78 qYl2+uI6ZAis9/QB9b1JDjUnTdJbcNMOMXTmhdgh+MqmE6lNADflRgMwyTm8xoIG 9e3/ljNsya+SarAnanC8f8B7Xb+wpN+UymM6OE4FXc50S9R8LeAvb7RyM9WaqP7k rBOelqmqzIeM/yqInUKm9aVxmic7OMNpv88Nzh02LTpFPWM9dQkRXGRvxIYuHAJM U3r7po6CyW6yR3wG3ErOojGJ22Bq989f7QVSRYjGyDPUmIYfn8ijd5TxZgtotft3 k3Z50CWt4Ww1psGmEJyP6ZXFFH6rT9j3IPhqh6cmaQYmHsQm7MQx5t6lDV7eB/BA wuA45uTcbuH4+AChBy50yoEy+8bkco59v0qVPOpKMubFL8qXELnVhSUaRwvcs5C9 jAu80fFO3l8/oE5z+ZqkSEzRiy0sxxHphfvPBjEAWM2PpQBSrzTA9BS4EyTJiF2q MlyA6npY9x5Uz8SwQK5O =WaCS -END PGP SIGNATURE-
Re: [arch-general] Still Glibc problems
Norbert Zeh said the following at 07/20/2012 12:27 PM : think the reason why you are having a much more serious issue is that it seems you haven't updated your system in a long time. So now you're running into Approximately a month, I believe. Certainly not a whole lot longer. I don't regard that as a long time, but perhaps in the arch world it is. But since the box I'm upgrading often goes a couple of months without even being powered up, it would be hard to upgrade more frequently. Maybe I made a mistake putting arch on it, if arch really does have to be upgraded more frequently than that. I was unaware that that was a consideration. I've never used a rolling release distribution before, and perhaps I shouldn't have done so on the machine in question. I (naïfly) thought that the package manager system would automagically take care of everything regardless of how many updates needed to be applied. Computers... even after all this time, still a learning experience. Even when I don't want them to be. Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
On Fri, Jul 20, 2012 at 10:36 PM, D. R. Evans doc.ev...@gmail.com wrote: Norbert Zeh said the following at 07/20/2012 12:27 PM : think the reason why you are having a much more serious issue is that it seems you haven't updated your system in a long time. So now you're running into Approximately a month, I believe. Certainly not a whole lot longer. I don't regard that as a long time, but perhaps in the arch world it is. But since the box I'm upgrading often goes a couple of months without even being powered up, it would be hard to upgrade more frequently. No, a month is not a long time. I would have thought more than half a year (which is still not awfully long, but would mean you would be hit by the problem explained in http://allanmcrae.com/2012/07/updating-arch-linux-from-a-core-install/). Anyway, I didn't mean to imply that you have to update at a certain frequency, just to offer a possible explanation why you are seeing problems that relatively few other people are seeing. -t
Re: [arch-general] Still Glibc problems
Tom Gundersen said the following at 07/20/2012 02:41 PM : On Fri, Jul 20, 2012 at 10:36 PM, D. R. Evans doc.ev...@gmail.com wrote: Norbert Zeh said the following at 07/20/2012 12:27 PM : think the reason why you are having a much more serious issue is that it seems you haven't updated your system in a long time. So now you're running into Approximately a month, I believe. Certainly not a whole lot longer. I don't regard that as a long time, but perhaps in the arch world it is. But since the box I'm upgrading often goes a couple of months without even being powered up, it would be hard to upgrade more frequently. No, a month is not a long time. I would have thought more than half a year (which is still not awfully long, but would mean you would be hit Definitely nothing even close to that. I do note that, as I mentioned, /var/run and /var/lock were symlinks, which I think is a change from about six months ago. I'm about to try the suggested sequence: pacman -Syu --ignore filesystem --ignore glibc pacman -S --force filesystem --ignore glibc pacman -Sd everything you couldn't upgrade due to ignored glibc pacman -Su and we'll see what happens. Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
Norbert Zeh said the following at 07/19/2012 06:08 PM : Well, the filesystem instructions are older and applied at the time the glibc upgrade was not an issue yet. Combining the two instructions, I would guess the following should work: pacman -Syu --ignore filesystem --ignore glibc OK. pacman -S --force filesystem --ignore glibc OK. pacman -Sd everything you couldn't upgrade due to ignored glibc OK. FWIW, the list of packages was: attica binutils boost-libs eclipse eclipse-cdt faac ffmpeg gcc gcc-libs gnutls grep gstreamer0.10-bad-plugins icu jedit kdebase-runtime kdelibs libcups libgl liblrdf libmp4v2 libproxy libtool libva linux mesa mkinitcpio openjdk6 pcre poppler poppler-glib qt raptor soprano swig xine-lib xorg-server-xephyr pacman -Su Not OK: [root@shack n7dr]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 33.94 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@shack n7dr]# Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
On 07/20/2012 12:46 PM, Tom Gundersen wrote: On Jul 20, 2012 6:08 PM, Baho Utot baho-u...@columbus.rr.com wrote: On 07/20/2012 10:47 AM, Tom Gundersen wrote: On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans doc.ev...@gmail.com wrote: There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any stale packages or re-enable any repos so you get all the most recent updates. I had a desktop system hosed that only packages in core, extra and community installed. I never heard of anyone actually hosing their system without using --force. What happened? (I'm assuming you don't use testing?). -t No I didn't use testing. Followed the news release..rebootedsystem borked.
Re: [arch-general] Still Glibc problems
D. R. Evans [2012.07.20 1541 -0600]: Norbert Zeh said the following at 07/19/2012 06:08 PM : Well, the filesystem instructions are older and applied at the time the glibc upgrade was not an issue yet. Combining the two instructions, I would guess the following should work: pacman -Syu --ignore filesystem --ignore glibc OK. pacman -S --force filesystem --ignore glibc OK. pacman -Sd everything you couldn't upgrade due to ignored glibc OK. FWIW, the list of packages was: attica binutils boost-libs eclipse eclipse-cdt faac ffmpeg gcc gcc-libs gnutls grep gstreamer0.10-bad-plugins icu jedit kdebase-runtime kdelibs libcups libgl liblrdf libmp4v2 libproxy libtool libva linux mesa mkinitcpio openjdk6 pcre poppler poppler-glib qt raptor soprano swig xine-lib xorg-server-xephyr pacman -Su Not OK: [root@shack n7dr]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 33.94 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. I got the same error at that point. What this means is that you either have some unowned (by any package) files in /lib (/lib/modules/* is a good candidate) or you have some other packages (most likely from AUR) owning files under /lib. The wiki page explains well how to look for them. At least, I followed those instructions and managed to identify the packages that blocked the upgrade. The key here really seems to be to make sure that glibc is the only package which at this point owns anything under /lib. I think in my case it also helped to uninstall some packages and reinstall them after the glibc upgrade. Keep pushing, you're almost there ;) Cheers, Norbert
Re: [arch-general] Still Glibc problems
On 07/20/2012 04:45 PM, Baho Utot wrote: On 07/20/2012 12:46 PM, Tom Gundersen wrote: On Jul 20, 2012 6:08 PM, Baho Utot baho-u...@columbus.rr.com wrote: On 07/20/2012 10:47 AM, Tom Gundersen wrote: On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans doc.ev...@gmail.com wrote: There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any stale packages or re-enable any repos so you get all the most recent updates. I had a desktop system hosed that only packages in core, extra and community installed. I never heard of anyone actually hosing their system without using --force. What happened? (I'm assuming you don't use testing?). -t No I didn't use testing. Followed the news release..rebootedsystem borked. Tom, Baho, After Updating 3 boxes and created 3 new arch chroots, you do have manual intervention required in just about every case if you have ever used mkinitcpio to rebuild initramfs (leaves old module trees in /lib/modules) or if you have ever used virtualbox (old vb modules left in /lib/modules/misc or /lib/modules/kernel/misc) udev-compat is also a problem. Just pacman -R that. Then after you do the initial pacman -Syu --ignore glibc, you need to manually pick though lib and make sure there is _nothing_ but glibc files in it. (no empty dirs, no links, no nothing) Then you can do the final pacman -Syu Also, if you attempt to create or update an arch chroot -- make sure you have no stale repos in pacman.conf. The install will fail and half your system will be mounted under the chroot dir. There is no way to update an arch chroot with the glibc 2.15-2.16 update. Just create a new one. Hope some of this helps.. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Still Glibc problems
Hello all, I also experienced initial problems getting the new glibc 2.16.0-2 to work. In my case, the problem was an older version of lib32-glibc (I think I had version 2.14.x installed, sorry can't remember exactly). After enabling the multilib repo in /etc/pacman.conf and doing sudo pacman -Syu --ignore glibc sudo pacman -Su Here is a link to a corresponding forum post: https://bbs.archlinux.org/viewtopic.php?pid=1131545 Everything was updated well. HTH, André On 07/18/2012 11:10 PM, P .NIKOLIC wrote: On Wed, 18 Jul 2012 12:27:11 +0200 Tom Gundersen t...@jklm.no wrote: Pruned You sholud delete the duplicate files from /usr/lib, did you do this? Then it _should_ work... -t Hi Tom Well word on the street is it seems to have worked at last now i have another problem cropped up for which i will start a new thread ThanksPete .
Re: [arch-general] Still Glibc problems
Alex Belanger said the following at 07/18/2012 05:27 AM : pacman -Syu --ignore glibc pacman -Su I had the same problem, went to archlinux website and they say exactly what you need to do and why. You shouldn't toy with it yourself, nor use the --force option. Try this, if it doesn't work, they have an in-depth guide too. I have tried this, and there seems to be a catch-22... 1. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib If running pacman -Syu --ignore glibc gives: warning: ignoring package glibc-2.16.0-2 warning: cannot resolve glibc=2.16, a dependency of gcc-libs ... :: The following packages cannot be upgraded due to unresolvable dependencies: binutils gcc gcc-libs Do you want to skip the above packages for this upgrade [y/N] Say y to skipping the packages, then install them all using (e.g.): But if I do that, I hit the /var/run and /var/lock problem: (127/127) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) filesystem: /var/lock exists in filesystem filesystem: /var/run exists in filesystem Errors occurred, no packages were upgraded. [root@shack n7dr]# 2. https://www.archlinux.org/news/filesystem-upgrade-manual-intervention-required-1/ So instead of dealing with glibc, I try to deal with the /var/run and /var/lock problem first. On my system, these are both symlinks. So, following instructions, I do: If the symlinks are already in place on your system (which should be the case for most people), then you can simply perform pacman -Syu --ignore filesystem pacman -S filesystem --force and that gives: error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. So it looks to me that I'm being told, basically, you have two errors, α and β. Before you fix α you must fix β. And before you fix β you must fix α. Am I misinterpreting or misunderstanding the instructions? They seem pretty clear, and I believe I followed them faithfully. Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/19/12 16:42, D. R. Evans wrote: pacman -Syu --ignore filesystem pacman -S filesystem --force and that gives: error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. Somebody will need to clarify the precise syntax. But it looks to me like you can't just ignore filesystem here; you also need to ignore glibc, then--I think--do the glibc upgrade without the --force option following the filesystem upgrade. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCKEMAAoJELT202JKF+xpyyIP/jWg2DW+0+XiJUQV9E+xVKRE gPHw3t1X/AUhG6Xijtu9ApfjiUlSQg44Zk9uJoGjhGdb/a/SqdROUzvnoHc7A7/3 FI32L+fQTyJJb84f1V93MeC/T1hyC3Pjht8xHOjIoDcgf1LmlWsy0gnXothJFagV h0hYrQ8nQbtmib1GHKlGyfMdRReL9+dZKm9p3n4G29rkvTzCEfG/S52/lgvCyoQZ gmJ2rJq4h2IQpIHIN6sSKJc8GlgYJMyYGuxTxi/XztBFUtl9mzhNvrmMILVPAvC9 qkuiF1fuZv7322jPfI6F3eBmvttrFS6SJMpRnK6D1oAS06pPWrksSul6O4ckguTM jNWwxS4oz1+1KhwcRrGx7jr3Df+/eVTYMREPBkjqEAyt1s2rtH7R9Yx08nB2Lfd5 1dnLYSDyFI7H5zmR6xbnq2+Bz9oSkpUCIK3Wn4Li0Z0SgW4dinzisO59AQKG64hS /3SSOzQxvcsMnIExL3D1uOh5Wu5ibew9IKd9wEfKsyq9iFsLBnHtlCx/lc93keb1 CpHUuEpyD+dRzB95iHqwr3pKgK5iFDuyehZTYvnyWNtieaJt53Yl3S67phc9jBzr rwh8w0NYWD870vvJnu239L4ZxwkaUru5KAiJE+iDN/o3fKbjorLkxmq0komhTq4x Rj8HqUOr2tCDulVG8gdV =v+z4 -END PGP SIGNATURE-
Re: [arch-general] Still Glibc problems
D. R. Evans [2012.07.19 1742 -0600]: Alex Belanger said the following at 07/18/2012 05:27 AM : pacman -Syu --ignore glibc pacman -Su I had the same problem, went to archlinux website and they say exactly what you need to do and why. You shouldn't toy with it yourself, nor use the --force option. Try this, if it doesn't work, they have an in-depth guide too. I have tried this, and there seems to be a catch-22... 1. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib If running pacman -Syu --ignore glibc gives: warning: ignoring package glibc-2.16.0-2 warning: cannot resolve glibc=2.16, a dependency of gcc-libs ... :: The following packages cannot be upgraded due to unresolvable dependencies: binutils gcc gcc-libs Do you want to skip the above packages for this upgrade [y/N] Say y to skipping the packages, then install them all using (e.g.): But if I do that, I hit the /var/run and /var/lock problem: (127/127) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) filesystem: /var/lock exists in filesystem filesystem: /var/run exists in filesystem Errors occurred, no packages were upgraded. [root@shack n7dr]# 2. https://www.archlinux.org/news/filesystem-upgrade-manual-intervention-required-1/ So instead of dealing with glibc, I try to deal with the /var/run and /var/lock problem first. On my system, these are both symlinks. So, following instructions, I do: If the symlinks are already in place on your system (which should be the case for most people), then you can simply perform pacman -Syu --ignore filesystem pacman -S filesystem --force and that gives: error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. So it looks to me that I'm being told, basically, you have two errors, α and β. Before you fix α you must fix β. And before you fix β you must fix α. Am I misinterpreting or misunderstanding the instructions? They seem pretty clear, and I believe I followed them faithfully. Doc -- Web: http://www.sff.net/people/N7DR Well, the filesystem instructions are older and applied at the time the glibc upgrade was not an issue yet. Combining the two instructions, I would guess the following should work: pacman -Syu --ignore filesystem --ignore glibc pacman -S --force filesystem --ignore glibc pacman -Sd everything you couldn't upgrade due to ignored glibc pacman -Su Note that I did not try this, but it seems to be the logical combination of the two. Maybe one of the developers can chime in and confirm that this is the right strategy. Cheers, Norbert
Re: [arch-general] Still Glibc problems
On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills hills...@gmail.com wrote: On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen t...@jklm.no wrote: So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. And if /lib IS a symbolic link, delete it and let the glibc sync create it. No. Then you'll lose your loader and can't do anything...
Re: [arch-general] Still Glibc problems
On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: Right after much faffing about i now have the box back to So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. Hi . Right i have sort of put a list together but well see below .. :error: No package owns /usr/lib/libanl-2.16.so error: No package owns /usr/lib/libanl.so.1 error: No package owns /usr/lib/libBrokenLocale-2.16.so error: No package owns /usr/lib/libBrokenLocale.so.1 error: No package owns /usr/lib/libc-2.16.so error: cannot determine ownership of directory '/usr/lib/libcanberra-0.28' error: No package owns /usr/lib/libcidn-2.16.so error: No package owns /usr/lib/libcidn.so.1 error: No package owns /usr/lib/libcrypt-2.16.so error: No package owns /usr/lib/libcrypt.so.1 error: No package owns /usr/lib/libc.so.6 error: No package owns /usr/lib/libdl-2.16.so error: No package owns /usr/lib/libdl.so.2 error: cannot determine ownership of directory '/usr/lib/libfakeroot' error: cannot determine ownership of directory '/usr/lib/libffi-3.0.11 error: cannot determine ownership of directory '/usr/lib/locale' error: cannot determine ownership of directory '/usr/lib/man-db' error: cannot determine ownership of directory '/usr/lib/mc' error: cannot determine ownership of directory '/usr/lib/modprobe.d' error: cannot determine ownership of directory '/usr/lib/modules' error: cannot determine ownership of directory '/usr/lib/modules-load.d' error: cannot determine ownership of directory '/usr/lib/mono' error: cannot determine ownership of directory '/usr/lib/mozilla' error: cannot determine ownership of directory '/usr/lib/mpg123' 1error: cannot determine ownership of directory '/usr/lib/mysql' error: cannot determine ownership of directory '/usr/lib/networkmanager' error: cannot determine ownership of directory '/usr/lib/ntrack' error: cannot determine ownership of directory '/usr/lib/ocaml' I have a huge number of the directory complaints are they ignoreable ..? Pete . -- Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux
Re: [arch-general] Still Glibc problems
On Wed, 18 Jul 2012 09:09:18 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills hills...@gmail.com wrote: On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen t...@jklm.no wrote: So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. And if /lib IS a symbolic link, delete it and let the glibc sync create it. No. Then you'll lose your loader and can't do anything... Been there not again thanks .. Pete . -- Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux
Re: [arch-general] Still Glibc problems
On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: Right after much faffing about i now have the box back to So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. Hi . Right i have sort of put a list together but well see below .. You just have to delete the files that show up as being in conflict when you try to upgrade. Just make sure that 1) /lib is not a symlink and 2) those files are not owned by any other package. -t
Re: [arch-general] Still Glibc problems
On 18-07-2012 08:09, Tom Gundersen wrote: On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills hills...@gmail.com wrote: On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen t...@jklm.no wrote: So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. And if /lib IS a symbolic link, delete it and let the glibc sync create it. No. Then you'll lose your loader and can't do anything... It's not in the wiki and I haven't seen it suggested but for really stubborn and possibly borked cases couldn't one boot from other media and tell pacman to update outside of the default path with --root, --cachedir, --config and --gpgdir? Or this a bad idea like using --force? -- Mauro Santos
Re: [arch-general] Still Glibc problems
On Wed, Jul 18, 2012 at 10:44 AM, Mauro Santos registo.maill...@gmail.com wrote: It's not in the wiki and I haven't seen it suggested but for really stubborn and possibly borked cases couldn't one boot from other media and tell pacman to update outside of the default path with --root, --cachedir, --config and --gpgdir? Or this a bad idea like using --force? That should work (TM) :-) -t
Re: [arch-general] Still Glibc problems
On Wed, 18 Jul 2012 09:22:53 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: Right after much faffing about i now have the box back to So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. Hi . Right i have sort of put a list together but well see below .. You just have to delete the files that show up as being in conflict when you try to upgrade. Just make sure that 1) /lib is not a symlink and 2) those files are not owned by any other package. -t Hu .. No matter what it try it still boils down to this list of errors error: failed to commit transaction (conflicting files) glibc: /usr/lib/ld-2.16.so exists in filesystem glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem glibc: /usr/lib/libSegFault.so exists in filesystem glibc: /usr/lib/libanl-2.16.so exists in filesystem glibc: /usr/lib/libanl.so.1 exists in filesystem glibc: /usr/lib/libc-2.16.so exists in filesystem glibc: /usr/lib/libc.so.6 exists in filesystem glibc: /usr/lib/libcidn-2.16.so exists in filesystem glibc: /usr/lib/libcidn.so.1 exists in filesystem glibc: /usr/lib/libcrypt-2.16.so exists in filesystem glibc: /usr/lib/libcrypt.so.1 exists in filesystem glibc: /usr/lib/libdl-2.16.so exists in filesystem glibc: /usr/lib/libdl.so.2 exists in filesystem glibc: /usr/lib/libm-2.16.so exists in filesystem glibc: /usr/lib/libm.so.6 exists in filesystem glibc: /usr/lib/libmemusage.so exists in filesystem glibc: /usr/lib/libnsl-2.16.so exists in filesystem glibc: /usr/lib/libnsl.so.1 exists in filesystem glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem glibc: /usr/lib/libnss_compat.so.2 exists in filesystem glibc: /usr/lib/libnss_db-2.16.so exists in filesystem glibc: /usr/lib/libnss_db.so.2 exists in filesystem glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem glibc: /usr/lib/libnss_dns.so.2 exists in filesystem glibc: /usr/lib/libnss_files-2.16.so exists in filesystem glibc: /usr/lib/libnss_files.so.2 exists in filesystem glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem glibc: /usr/lib/libnss_nis.so.2 exists in filesystem glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem glibc: /usr/lib/libpcprofile.so exists in filesystem glibc: /usr/lib/libpthread-2.16.so exists in filesystem glibc: /usr/lib/libpthread.so.0 exists in filesystem glibc: /usr/lib/libresolv-2.16.so exists in filesystem glibc: /usr/lib/libresolv.so.2 exists in filesystem glibc: /usr/lib/librt-2.16.so exists in filesystem glibc: /usr/lib/librt.so.1 exists in filesystem glibc: /usr/lib/libthread_db-1.0.so exists in filesystem glibc: /usr/lib/libthread_db.so.1 exists in filesystem glibc: /usr/lib/libutil-2.16.so exists in filesystem glibc: /usr/lib/libutil.so.1 exists in filesystem Errors occurred, no packages were upgraded. lib is NOT a symlink 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/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/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/libc-2.16.so 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/libc.so.6 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/libmemusage.so is owned by glibc 2.16.0-1 /lib/libm.so.6 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_nisplus-2.16.so is owned by glibc 2.16.0-1 /lib/libnss_nisplus.so.2 is owned by glibc
Re: [arch-general] Still Glibc problems
On Wed, Jul 18, 2012 at 12:24 PM, P .NIKOLIC p.nikol...@btinternet.com wrote: On Wed, 18 Jul 2012 09:22:53 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: Right after much faffing about i now have the box back to So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. Hi . Right i have sort of put a list together but well see below .. You just have to delete the files that show up as being in conflict when you try to upgrade. Just make sure that 1) /lib is not a symlink and 2) those files are not owned by any other package. -t Hu .. No matter what it try it still boils down to this list of errors error: failed to commit transaction (conflicting files) glibc: /usr/lib/ld-2.16.so exists in filesystem glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem glibc: /usr/lib/libSegFault.so exists in filesystem glibc: /usr/lib/libanl-2.16.so exists in filesystem glibc: /usr/lib/libanl.so.1 exists in filesystem glibc: /usr/lib/libc-2.16.so exists in filesystem glibc: /usr/lib/libc.so.6 exists in filesystem glibc: /usr/lib/libcidn-2.16.so exists in filesystem glibc: /usr/lib/libcidn.so.1 exists in filesystem glibc: /usr/lib/libcrypt-2.16.so exists in filesystem glibc: /usr/lib/libcrypt.so.1 exists in filesystem glibc: /usr/lib/libdl-2.16.so exists in filesystem glibc: /usr/lib/libdl.so.2 exists in filesystem glibc: /usr/lib/libm-2.16.so exists in filesystem glibc: /usr/lib/libm.so.6 exists in filesystem glibc: /usr/lib/libmemusage.so exists in filesystem glibc: /usr/lib/libnsl-2.16.so exists in filesystem glibc: /usr/lib/libnsl.so.1 exists in filesystem glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem glibc: /usr/lib/libnss_compat.so.2 exists in filesystem glibc: /usr/lib/libnss_db-2.16.so exists in filesystem glibc: /usr/lib/libnss_db.so.2 exists in filesystem glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem glibc: /usr/lib/libnss_dns.so.2 exists in filesystem glibc: /usr/lib/libnss_files-2.16.so exists in filesystem glibc: /usr/lib/libnss_files.so.2 exists in filesystem glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem glibc: /usr/lib/libnss_nis.so.2 exists in filesystem glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem glibc: /usr/lib/libpcprofile.so exists in filesystem glibc: /usr/lib/libpthread-2.16.so exists in filesystem glibc: /usr/lib/libpthread.so.0 exists in filesystem glibc: /usr/lib/libresolv-2.16.so exists in filesystem glibc: /usr/lib/libresolv.so.2 exists in filesystem glibc: /usr/lib/librt-2.16.so exists in filesystem glibc: /usr/lib/librt.so.1 exists in filesystem glibc: /usr/lib/libthread_db-1.0.so exists in filesystem glibc: /usr/lib/libthread_db.so.1 exists in filesystem glibc: /usr/lib/libutil-2.16.so exists in filesystem glibc: /usr/lib/libutil.so.1 exists in filesystem Errors occurred, no packages were upgraded. lib is NOT a symlink 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/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/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/libc-2.16.so 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/libc.so.6 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/libmemusage.so is owned by glibc 2.16.0-1 /lib/libm.so.6 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
Re: [arch-general] Still Glibc problems
pacman -Syu --ignore glibc pacman -Su I had the same problem, went to archlinux website and they say exactly what you need to do and why. You shouldn't toy with it yourself, nor use the --force option. Try this, if it doesn't work, they have an in-depth guide too. Otherwise I cannot stress out more the importance of reading the announcements whenever you're upgrading. On Jul 18, 2012, at 6:27 AM, Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 12:24 PM, P .NIKOLIC p.nikol...@btinternet.com wrote: On Wed, 18 Jul 2012 09:22:53 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen t...@jklm.no wrote: On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: Right after much faffing about i now have the box back to So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. Hi . Right i have sort of put a list together but well see below .. You just have to delete the files that show up as being in conflict when you try to upgrade. Just make sure that 1) /lib is not a symlink and 2) those files are not owned by any other package. -t Hu .. No matter what it try it still boils down to this list of errors error: failed to commit transaction (conflicting files) glibc: /usr/lib/ld-2.16.so exists in filesystem glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem glibc: /usr/lib/libSegFault.so exists in filesystem glibc: /usr/lib/libanl-2.16.so exists in filesystem glibc: /usr/lib/libanl.so.1 exists in filesystem glibc: /usr/lib/libc-2.16.so exists in filesystem glibc: /usr/lib/libc.so.6 exists in filesystem glibc: /usr/lib/libcidn-2.16.so exists in filesystem glibc: /usr/lib/libcidn.so.1 exists in filesystem glibc: /usr/lib/libcrypt-2.16.so exists in filesystem glibc: /usr/lib/libcrypt.so.1 exists in filesystem glibc: /usr/lib/libdl-2.16.so exists in filesystem glibc: /usr/lib/libdl.so.2 exists in filesystem glibc: /usr/lib/libm-2.16.so exists in filesystem glibc: /usr/lib/libm.so.6 exists in filesystem glibc: /usr/lib/libmemusage.so exists in filesystem glibc: /usr/lib/libnsl-2.16.so exists in filesystem glibc: /usr/lib/libnsl.so.1 exists in filesystem glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem glibc: /usr/lib/libnss_compat.so.2 exists in filesystem glibc: /usr/lib/libnss_db-2.16.so exists in filesystem glibc: /usr/lib/libnss_db.so.2 exists in filesystem glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem glibc: /usr/lib/libnss_dns.so.2 exists in filesystem glibc: /usr/lib/libnss_files-2.16.so exists in filesystem glibc: /usr/lib/libnss_files.so.2 exists in filesystem glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem glibc: /usr/lib/libnss_nis.so.2 exists in filesystem glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem glibc: /usr/lib/libpcprofile.so exists in filesystem glibc: /usr/lib/libpthread-2.16.so exists in filesystem glibc: /usr/lib/libpthread.so.0 exists in filesystem glibc: /usr/lib/libresolv-2.16.so exists in filesystem glibc: /usr/lib/libresolv.so.2 exists in filesystem glibc: /usr/lib/librt-2.16.so exists in filesystem glibc: /usr/lib/librt.so.1 exists in filesystem glibc: /usr/lib/libthread_db-1.0.so exists in filesystem glibc: /usr/lib/libthread_db.so.1 exists in filesystem glibc: /usr/lib/libutil-2.16.so exists in filesystem glibc: /usr/lib/libutil.so.1 exists in filesystem Errors occurred, no packages were upgraded. lib is NOT a symlink 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/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/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/libc-2.16.so 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/libc.so.6 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/libmemusage.so is owned by glibc 2.16.0-1 /lib/libm.so.6 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
Re: [arch-general] Still Glibc problems
On Wed, 18 Jul 2012 07:27:57 -0400 Alex Belanger i.caught@gmail.com wrote: pacman -Syu --ignore glibc pacman -Su I had the same problem, went to archlinux website and they say exactly what you need to do and why. You shouldn't toy with it yourself, nor use the --force option. Try this, if it doesn't work, they have an in-depth guide too. Otherwise I cannot stress out more the importance of reading the announcements whenever you're upgrading. Been there done that still fails ...else i would not be trying to solve the problem here .. Pete -- Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux
Re: [arch-general] Still Glibc problems
On Wed, 18 Jul 2012 12:27:11 +0200 Tom Gundersen t...@jklm.no wrote: Pruned You sholud delete the duplicate files from /usr/lib, did you do this? Then it _should_ work... -t Hi Tom Ok i will give it a whirl see what transpires CheersPete -- Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux
Re: [arch-general] Still Glibc problems
On Wed, 18 Jul 2012 12:27:11 +0200 Tom Gundersen t...@jklm.no wrote: Pruned You sholud delete the duplicate files from /usr/lib, did you do this? Then it _should_ work... -t Hi Tom Well word on the street is it seems to have worked at last now i have another problem cropped up for which i will start a new thread ThanksPete . -- Linux 7-of-9 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012 x86_64 GNU/Linux
[arch-general] Still Glibc problems
Right then Hi .. I have followed all there is to follow tried all i can find to try yet i am still getting error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem glibc: /usr/lib/ld-2.16.so exists in filesystem glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem glibc: /usr/lib/libSegFault.so exists in filesystem glibc: /usr/lib/libanl-2.16.so exists in filesystem glibc: /usr/lib/libanl.so.1 exists in filesystem glibc: /usr/lib/libc-2.16.so exists in filesystem glibc: /usr/lib/libc.so.6 exists in filesystem glibc: /usr/lib/libcidn-2.16.so exists in filesystem glibc: /usr/lib/libcidn.so.1 exists in filesystem glibc: /usr/lib/libcrypt-2.16.so exists in filesystem glibc: /usr/lib/libcrypt.so.1 exists in filesystem glibc: /usr/lib/libdl-2.16.so exists in filesystem glibc: /usr/lib/libdl.so.2 exists in filesystem glibc: /usr/lib/libm-2.16.so exists in filesystem glibc: /usr/lib/libm.so.6 exists in filesystem glibc: /usr/lib/libmemusage.so exists in filesystem glibc: /usr/lib/libnsl-2.16.so exists in filesystem glibc: /usr/lib/libnsl.so.1 exists in filesystem glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem glibc: /usr/lib/libnss_compat.so.2 exists in filesystem glibc: /usr/lib/libnss_db-2.16.so exists in filesystem glibc: /usr/lib/libnss_db.so.2 exists in filesystem glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem glibc: /usr/lib/libnss_dns.so.2 exists in filesystem glibc: /usr/lib/libnss_files-2.16.so exists in filesystem glibc: /usr/lib/libnss_files.so.2 exists in filesystem glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem glibc: /usr/lib/libnss_nis.so.2 exists in filesystem glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem glibc: /usr/lib/libpcprofile.so exists in filesystem glibc: /usr/lib/libpthread-2.16.so exists in filesystem glibc: /usr/lib/libpthread.so.0 exists in filesystem glibc: /usr/lib/libresolv-2.16.so exists in filesystem glibc: /usr/lib/libresolv.so.2 exists in filesystem glibc: /usr/lib/librt-2.16.so exists in filesystem glibc: /usr/lib/librt.so.1 exists in filesystem glibc: /usr/lib/libthread_db-1.0.so exists in filesystem glibc: /usr/lib/libthread_db.so.1 exists in filesystem glibc: /usr/lib/libutil-2.16.so exists in filesystem glibc: /usr/lib/libutil.so.1 exists in filesystem Errors occurred, no packages were upgraded. What has got to be done to solve this once and for all .. lib is a symlink to usr/lib.. # l lib lrwxrwxrwx 1 root root 7 Jul 17 16:08 lib - usr/lib/ pacman -Qo /lib/* Just generates screens full of the below error: cannot determine ownership of directory '/lib/akonadi' error: cannot determine ownership of directory '/lib/alsa-lib' error: cannot determine ownership of directory '/lib/ao' /lib/apr.exp is owned by apr 1.4.6-1 error: cannot determine ownership of directory '/lib/apr-util-1' /lib/aprutil.exp is owned by apr-util 1.4.1-1 /lib/aspell is owned by aspell 0.60.6.1-1 error: cannot determine ownership of directory '/lib/aspell-0.60' error: cannot determine ownership of directory '/lib/atkmm-1.6' /lib/attica_kde.so is owned by kdebase-runtime 4.8.4-2 And grep '^lib/' /var/lib/pacman/local/*/files | grep -v glibc Generates absolutely nothing so what gives .. Pete . -- Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux
Re: [arch-general] Still Glibc problems
On Tue, Jul 17, 2012 at 5:19 PM, P .NIKOLIC p.nikol...@btinternet.com wrote: I have followed all there is to follow tried all i can find to try yet i am still getting error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem glibc: /usr/lib/ld-2.16.so exists in filesystem glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem glibc: /usr/lib/libSegFault.so exists in filesystem glibc: /usr/lib/libanl-2.16.so exists in filesystem glibc: /usr/lib/libanl.so.1 exists in filesystem glibc: /usr/lib/libc-2.16.so exists in filesystem glibc: /usr/lib/libc.so.6 exists in filesystem glibc: /usr/lib/libcidn-2.16.so exists in filesystem glibc: /usr/lib/libcidn.so.1 exists in filesystem glibc: /usr/lib/libcrypt-2.16.so exists in filesystem glibc: /usr/lib/libcrypt.so.1 exists in filesystem glibc: /usr/lib/libdl-2.16.so exists in filesystem glibc: /usr/lib/libdl.so.2 exists in filesystem glibc: /usr/lib/libm-2.16.so exists in filesystem glibc: /usr/lib/libm.so.6 exists in filesystem glibc: /usr/lib/libmemusage.so exists in filesystem glibc: /usr/lib/libnsl-2.16.so exists in filesystem glibc: /usr/lib/libnsl.so.1 exists in filesystem glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem glibc: /usr/lib/libnss_compat.so.2 exists in filesystem glibc: /usr/lib/libnss_db-2.16.so exists in filesystem glibc: /usr/lib/libnss_db.so.2 exists in filesystem glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem glibc: /usr/lib/libnss_dns.so.2 exists in filesystem glibc: /usr/lib/libnss_files-2.16.so exists in filesystem glibc: /usr/lib/libnss_files.so.2 exists in filesystem glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem glibc: /usr/lib/libnss_nis.so.2 exists in filesystem glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem glibc: /usr/lib/libpcprofile.so exists in filesystem glibc: /usr/lib/libpthread-2.16.so exists in filesystem glibc: /usr/lib/libpthread.so.0 exists in filesystem glibc: /usr/lib/libresolv-2.16.so exists in filesystem glibc: /usr/lib/libresolv.so.2 exists in filesystem glibc: /usr/lib/librt-2.16.so exists in filesystem glibc: /usr/lib/librt.so.1 exists in filesystem glibc: /usr/lib/libthread_db-1.0.so exists in filesystem glibc: /usr/lib/libthread_db.so.1 exists in filesystem glibc: /usr/lib/libutil-2.16.so exists in filesystem glibc: /usr/lib/libutil.so.1 exists in filesystem Errors occurred, no packages were upgraded. What has got to be done to solve this once and for all .. lib is a symlink to usr/lib.. Hm how did /lib end up as a symlink to /usr/lib without those files being owned by glibc? Did you just copy it over manually and create the link yourself? -t
Re: [arch-general] Still Glibc problems
On Tue, 17 Jul 2012 17:27:35 +0200 Tom Gundersen t...@jklm.no wrote: Pruned Hm how did /lib end up as a symlink to /usr/lib without those files being owned by glibc? Did you just copy it over manually and create the link yourself? -t Quite easily I followed what was on the Arch web site and the links therein nothing fancy Pete . -- Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux
Re: [arch-general] Still Glibc problems
Op 17 jul. 2012 18:01 schreef P .NIKOLIC p.nikol...@btinternet.com het volgende: On Tue, 17 Jul 2012 17:27:35 +0200 Tom Gundersen t...@jklm.no wrote: Pruned Hm how did /lib end up as a symlink to /usr/lib without those files being owned by glibc? Did you just copy it over manually and create the link yourself? -t Quite easily I followed what was on the Arch web site and the links therein nothing fancy ;-) It might help to know which steps you took. Afaik, the instructions were to check if any files were still in /lib -other then glibc's- and to rebuild those packages. But maybe you took some other steps? Checking the ownership of files in the symlinked /lib has little purpose. Just my two cents. mvg, Guus
Re: [arch-general] Still Glibc problems
On Tue, 17 Jul 2012 17:27:35 +0200 Tom Gundersen t...@jklm.no wrote: Hm how did /lib end up as a symlink to /usr/lib without those files being owned by glibc? Did you just copy it over manually and create the link yourself? -t Right after much faffing about i now have the box back to # 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/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/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/libc-2.16.so 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/libc.so.6 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/libmemusage.so is owned by glibc 2.16.0-1 /lib/libm.so.6 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_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/libnss_nis.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/libSegFault.so 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 and grep '^lib/' /var/lib/pacman/local/*/files | grep -v glibc returns nothing at all so now how do i get to install the new glibc all i get right now is error: failed to commit transaction (conflicting files) glibc: /usr/lib/ld-2.16.so exists in filesystem glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem glibc: /usr/lib/libSegFault.so exists in filesystem glibc: /usr/lib/libanl-2.16.so exists in filesystem glibc: /usr/lib/libanl.so.1 exists in filesystem glibc: /usr/lib/libc-2.16.so exists in filesystem glibc: /usr/lib/libc.so.6 exists in filesystem glibc: /usr/lib/libcidn-2.16.so exists in filesystem glibc: /usr/lib/libcidn.so.1 exists in filesystem glibc: /usr/lib/libcrypt-2.16.so exists in filesystem glibc: /usr/lib/libcrypt.so.1 exists in filesystem glibc: /usr/lib/libdl-2.16.so exists in filesystem glibc: /usr/lib/libdl.so.2 exists in filesystem glibc: /usr/lib/libm-2.16.so exists in filesystem glibc: /usr/lib/libm.so.6 exists in filesystem glibc: /usr/lib/libmemusage.so exists in filesystem glibc: /usr/lib/libnsl-2.16.so exists in filesystem glibc: /usr/lib/libnsl.so.1 exists in filesystem glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem glibc: /usr/lib/libnss_compat.so.2 exists in filesystem glibc: /usr/lib/libnss_db-2.16.so exists in filesystem glibc: /usr/lib/libnss_db.so.2 exists in filesystem glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem glibc: /usr/lib/libnss_dns.so.2 exists in filesystem glibc: /usr/lib/libnss_files-2.16.so exists in filesystem glibc: /usr/lib/libnss_files.so.2 exists in filesystem glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem glibc: /usr/lib/libnss_nis.so.2 exists in filesystem glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem glibc: /usr/lib/libpcprofile.so exists in filesystem glibc: /usr/lib/libpthread-2.16.so exists in filesystem glibc: /usr/lib/libpthread.so.0 exists in filesystem glibc: /usr/lib/libresolv-2.16.so exists in filesystem glibc: /usr/lib/libresolv.so.2 exists in filesystem glibc: /usr/lib/librt-2.16.so exists in filesystem glibc: /usr/lib/librt.so.1 exists in filesystem glibc: /usr/lib/libthread_db-1.0.so exists in filesystem glibc: /usr/lib/libthread_db.so.1
Re: [arch-general] Still Glibc problems
grep '^lib/' /var/lib/pacman/local/*/files | grep -v glibc returns nothing at all Please try that with grep -v local/glibc-2.16.0 grep -v glibc is too simple actually and will filter out lib32-glibc for example. -- дамјан
Re: [arch-general] Still Glibc problems
On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC p.nikol...@btinternet.com wrote: Right after much faffing about i now have the box back to So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade.
Re: [arch-general] Still Glibc problems
On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen t...@jklm.no wrote: So if /lib is NOT a symlink, then all you should need is to delete all the files in /usr/lib that are not owned by any package. Then you should be able to upgrade. And if /lib IS a symbolic link, delete it and let the glibc sync create it. --Andrew Hills
