[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
On Tue, Jul 17, 2012 at 5:19 PM, P .NIKOLIC <p.nikolic1@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
On Tue, 17 Jul 2012 17:27:35 +0200 Tom Gundersen <teg@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
Op 17 jul. 2012 18:01 schreef "P .NIKOLIC" <p.nikolic1@btinternet.com> het volgende:
On Tue, 17 Jul 2012 17:27:35 +0200 Tom Gundersen <teg@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
On Tue, 17 Jul 2012 18:27:24 +0200 Guus Snijders <gsnijders@gmail.com> wrote:
Op 17 jul. 2012 18:01 schreef "P .NIKOLIC" <p.nikolic1@btinternet.com> het volgende:
On Tue, 17 Jul 2012 17:27:35 +0200 Tom Gundersen <teg@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
Hi .. this is the link that got the box running again .. https://bbs.archlinux.org/viewtopic.php?pid=1127251#p1127251 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
On Tue, 17 Jul 2012 17:27:35 +0200 Tom Gundersen <teg@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 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. 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
On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC <p.nikolic1@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.
On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen <teg@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
On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills <hills.as@gmail.com> wrote:
On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen <teg@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...
On Wed, 18 Jul 2012 09:09:18 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills <hills.as@gmail.com> wrote:
On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen <teg@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
On 18-07-2012 08:09, Tom Gundersen wrote:
On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills <hills.as@gmail.com> wrote:
On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen <teg@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
On Wed, Jul 18, 2012 at 10:44 AM, Mauro Santos <registo.mailling@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
On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC <p.nikolic1@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
On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC <p.nikolic1@btinternet.com> wrote:
On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC <p.nikolic1@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
On Wed, 18 Jul 2012 09:22:53 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC <p.nikolic1@btinternet.com> wrote:
On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC <p.nikolic1@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
Hummmmmmmm .. 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 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 If i boot from cd and rename lib then recreate a blank lib dir it fails to boot no matter what i have tried it will only run with lib as it stand right now . Is it because files seem to exist in /lib AND /usr/lib and if so is it safe to delete the duplicate files in /usr/lib And just how i have wound up with dupes in /lib and /usr/lib well still head scratching over that one .. 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
On Wed, Jul 18, 2012 at 12:24 PM, P .NIKOLIC <p.nikolic1@btinternet.com> wrote:
On Wed, 18 Jul 2012 09:22:53 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC <p.nikolic1@btinternet.com> wrote:
On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC <p.nikolic1@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
Hummmmmmmm ..
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 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
If i boot from cd and rename lib then recreate a blank lib dir it fails to boot no matter what i have tried it will only run with lib as it stand right now . Is it because files seem to exist in /lib AND /usr/lib and if so is it safe to delete the duplicate files in /usr/lib
And just how i have wound up with dupes in /lib and /usr/lib well still head scratching over that one ..
You sholud delete the duplicate files from /usr/lib, did you do this? Then it _should_ work... -t
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 <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 12:24 PM, P .NIKOLIC <p.nikolic1@btinternet.com> wrote:
On Wed, 18 Jul 2012 09:22:53 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC <p.nikolic1@btinternet.com> wrote:
On Wed, 18 Jul 2012 00:46:49 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC <p.nikolic1@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
Hummmmmmmm ..
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 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
If i boot from cd and rename lib then recreate a blank lib dir it fails to boot no matter what i have tried it will only run with lib as it stand right now . Is it because files seem to exist in /lib AND /usr/lib and if so is it safe to delete the duplicate files in /usr/lib
And just how i have wound up with dupes in /lib and /usr/lib well still head scratching over that one ..
You sholud delete the duplicate files from /usr/lib, did you do this? Then it _should_ work...
-t
On Wed, 18 Jul 2012 07:27:57 -0400 Alex Belanger <i.caught.air@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
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-requir... 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
-----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 benfell@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-----
2012/7/20 David Benfell <benfell@parts-unknown.org>:
-----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.
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. 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. 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 Both are untested, though. On the bright side, i know from experience that it's fairly simple to completely reinstall Arch (had a bad HDD once). mvg, Guus
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
On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans <doc.evans@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
On 07/20/2012 10:47 AM, Tom Gundersen wrote:
On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans <doc.evans@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.
On Jul 20, 2012 6:08 PM, "Baho Utot" <baho-utot@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.evans@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
On 07/20/2012 12:46 PM, Tom Gundersen wrote:
On Jul 20, 2012 6:08 PM, "Baho Utot" <baho-utot@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.evans@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......rebooted....system borked.
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-utot@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.evans@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......rebooted....system 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.
-----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.evans@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 benfell@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-----
Op 20 jul. 2012 16:21 schreef "D. R. Evans" <doc.evans@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
On Fri, Jul 20, 2012 at 12:13 PM, Guus Snijders <gsnijders@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
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-requir...
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
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
On Fri, Jul 20, 2012 at 4:27 PM, D. R. Evans <doc.evans@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
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.
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
On 07/20/12 at 03:27pm, Norbert Zeh wrote:
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've had no problems with filesystem, /lib -> /usr/lib or, today, grub -> grub2. I have at best a tenuous grasp of the issues involved in these three changes, so I can only consider myself very lucky that I'm not in the quandary others seem to be. I know, though, of enthusiastic archers who have resented the problems that have resulted from some of these changes, and feel less enthusiastic about archlinux now. I guess there is an inherent tension between the rolling-distro concept and KISS: if you want an up-to-date system you are bound to change things that work (which is hardly KISS). I was wondering if the following could be useful to minimize the impact of these, more trepidant pacman -Syu's: archlinux could publish a roadmap of user-intervention upgrades well in advance: we will do this in Q1, that in Q2, and that other thing in Q3. This way users could, for example, plan their upgrades so as not to have to deal with two such problematic migrations at the same time. It would also be nice to know a bit more of the rationale behind the moves. I'm sure that they are all for the best, and I trust arch decision-makers (and one can find out more about the changes by reading blogs and forum discussions), but still it'd be good to have a small FAQ posted to arch-general before each of the biggish moves. Manolo
On 07/20/2012 12:41 PM, Manolo Martínez wrote:
It would also be nice to know a bit more of the rationale behind the moves. I'm sure that they are all for the best, and I trust arch decision-makers (and one can find out more about the changes by reading blogs and forum discussions), but still it'd be good to have a small FAQ posted to arch-general before each of the biggish moves.
I don't know how it can get any more transparent. Most of the discussion and defense (if necessary) happens on arch-dev-public. Then there is usually some mention on arch-general, and always announcements. Look at the past three announcements: filesystem, /lib, and grub2. It's all there. It's rare that you can actually hose your system to a point where you can't fix it from the install image and using pacman -r or setting up a chroot.
On Fri, Jul 20, 2012 at 02:41:44PM -0400, Manolo Martínez wrote:
On 07/20/12 at 03:27pm, Norbert Zeh wrote:
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've had no problems with filesystem, /lib -> /usr/lib or, today, grub -> grub2. I have at best a tenuous grasp of the issues involved in these three changes, so I can only consider myself very lucky that I'm not in the quandary others seem to be.
I know, though, of enthusiastic archers who have resented the problems that have resulted from some of these changes, and feel less enthusiastic about archlinux now. I guess there is an inherent tension between the rolling-distro concept and KISS: if you want an up-to-date system you are bound to change things that work (which is hardly KISS).
I was wondering if the following could be useful to minimize the impact of these, more trepidant pacman -Syu's: archlinux could publish a roadmap of user-intervention upgrades well in advance: we will do this in Q1, that in Q2, and that other thing in Q3. This way users could, for example, plan their upgrades so as not to have to deal with two such problematic migrations at the same time.
It would also be nice to know a bit more of the rationale behind the moves. I'm sure that they are all for the best, and I trust arch decision-makers (and one can find out more about the changes by reading blogs and forum discussions), but still it'd be good to have a small FAQ posted to arch-general before each of the biggish moves.
Manolo
All of those changes were discussed by the devs on arch-dev-public filesystem -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023014.html grub -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023147.html /lib -> usr/lib -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.htm... There are also discussions there about what will happen and when stuff breaks like the pacman bug when usr lib was in testing, most of that happens that
On 07/20/12 at 02:56pm, Daniel Wallace wrote:
All of those changes were discussed by the devs on arch-dev-public
filesystem -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023014.html
grub -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023147.html
/lib -> usr/lib -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.htm...
There are also discussions there about what will happen and when stuff breaks like the pacman bug when usr lib was in testing, most of that happens that
I, for one, thought that running archlinux responsibly only committed me to subscribing to and reading arch-announce and -general. If I need to read -dev-public too I will, but it'd be good to be explicit about this. In my previous e-mail I also raised the point of having a roadmap for upgrades that require user intervention. I'd like to know if that'd be feasible; I think it would be useful. Manolo --
On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez <manolo@austrohungaro.com> wrote:
On 07/20/12 at 02:56pm, Daniel Wallace wrote:
All of those changes were discussed by the devs on arch-dev-public
I, for one, thought that running archlinux responsibly only committed me to subscribing to and reading arch-announce and -general. If I need to read -dev-public too I will, but it'd be good to be explicit about this.
You don't have to read arch-dev-public if you just want to use Arch, but your original question was about the reasoning behind the move and that information is available in the mailing list archives.
In my previous e-mail I also raised the point of having a roadmap for upgrades that require user intervention. I'd like to know if that'd be feasible; I think it would be useful.
Likely not going to happen. Just update every few weeks rather than months and you'll have the same problems as everyone else (which will be described in the news posts) rather than more than one at a time, but even that isn't really that hard to resolve (see Allan's blog post[1] about upgrading from the super old core ISO) [1]: http://allanmcrae.com/2012/07/updating-arch-linux-from-a-core-install/
On 07/20/12 at 09:31pm, Florian Pritz wrote:
On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez <manolo@austrohungaro.com> wrote:
On 07/20/12 at 02:56pm, Daniel Wallace wrote:
All of those changes were discussed by the devs on arch-dev-public
I, for one, thought that running archlinux responsibly only committed me to subscribing to and reading arch-announce and -general. If I need to read -dev-public too I will, but it'd be good to be explicit about this.
You don't have to read arch-dev-public if you just want to use Arch, but your original question was about the reasoning behind the move and that information is available in the mailing list archives.
No, apparently you do need to know why and how these things are done even if you just want to use Arch and don't plan to develop for it. That's a lesson I learnt around here anyway. Manolo
On Fri, Jul 20, 2012 at 3:37 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
On 07/20/12 at 09:31pm, Florian Pritz wrote:
On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez <manolo@austrohungaro.com> wrote:
On 07/20/12 at 02:56pm, Daniel Wallace wrote:
All of those changes were discussed by the devs on arch-dev-public
I, for one, thought that running archlinux responsibly only committed me to subscribing to and reading arch-announce and -general. If I need to read -dev-public too I will, but it'd be good to be explicit about this.
You don't have to read arch-dev-public if you just want to use Arch, but your original question was about the reasoning behind the move and that information is available in the mailing list archives.
No, apparently you do need to know why and how these things are done even if you just want to use Arch and don't plan to develop for it. That's a lesson I learnt around here anyway.
Manolo
Just to chime in here, I hadn't updated my system in about 6 months and was able to get past the /lib bump without reading the ML threads just fine. The news article linking to the wiki page was plenty.
On Fri, Jul 20, 2012 at 9:37 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
On 07/20/12 at 09:31pm, Florian Pritz wrote:
On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez <manolo@austrohungaro.com> wrote:
On 07/20/12 at 02:56pm, Daniel Wallace wrote:
All of those changes were discussed by the devs on arch-dev-public
I, for one, thought that running archlinux responsibly only committed me to subscribing to and reading arch-announce and -general. If I need to read -dev-public too I will, but it'd be good to be explicit about this.
You don't have to read arch-dev-public if you just want to use Arch, but your original question was about the reasoning behind the move and that information is available in the mailing list archives.
No, apparently you do need to know why and how these things are done even if you just want to use Arch and don't plan to develop for it. That's a lesson I learnt around here anyway.
The aim is that reading the news items should be enough to deal with any update. If you want notifications in advance of future plans or if you want to understand the reasoning behind certain changes, then following arch-dev-public should be enough. arch-general is typically for user discussions, and not so much for development discussions. -t
On 07/20/12 at 10:45pm, Tom Gundersen wrote:
On Fri, Jul 20, 2012 at 9:37 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
On 07/20/12 at 09:31pm, Florian Pritz wrote:
On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez <manolo@austrohungaro.com> wrote:
On 07/20/12 at 02:56pm, Daniel Wallace wrote:
All of those changes were discussed by the devs on arch-dev-public
I, for one, thought that running archlinux responsibly only committed me to subscribing to and reading arch-announce and -general. If I need to read -dev-public too I will, but it'd be good to be explicit about this.
You don't have to read arch-dev-public if you just want to use Arch, but your original question was about the reasoning behind the move and that information is available in the mailing list archives.
No, apparently you do need to know why and how these things are done even if you just want to use Arch and don't plan to develop for it. That's a lesson I learnt around here anyway.
The aim is that reading the news items should be enough to deal with any update. If you want notifications in advance of future plans or if you want to understand the reasoning behind certain changes, then following arch-dev-public should be enough. arch-general is typically for user discussions, and not so much for development discussions.
OK. I'll subscribe to arch-dev-public, then. I think it would be good if the "mailing lists" page at archlinux.org explained what one is to expect from each mailing list, and maybe recommend which mailing lists to follow, like you just did. Thanks, Manolo
Op 21 jul. 2012 01:13 schreef "Manolo Martínez" <manolo@austrohungaro.com> het volgende:
OK. I'll subscribe to arch-dev-public, then. I think it would be good if the "mailing lists" page at archlinux.org explained what one is to expect from each mailing list, and maybe recommend which mailing lists to follow, like you just did.
I usually just check the online archives for that list every now and then. Mainly when there are 'special' updates, sometimes just curiousity. Mvg, Guus
The problem is not Arch is bleeding edge nor this deep change from /lib to /usr/lib, the problem is that _people don't read_: everything was *clearly* explained in the website's frontpage news and in the wiki. Here's what the people at Project Zomboid had to do to ensure it's customers READ a notice: http://projectzomboid.com/blog/index.php/buy-our-games/ Again: people don't read, screw up their system and then blame the change... :P -- -msx
On 07/23/2012 09:22 PM, Martin Cigorraga wrote:
Again: people don't read, screw up their system and then blame the change... :P
In some case yes, in some cases, that's not quite true. The usrlib change depended a great deal on how old your Arch install was, how many custom packages you had built with files in /lib, how many initramfs you have generated over the years, whether you have older versions of virtualbox around, whether you every used nvidia, etc.., etc.. etc.. It was no small change for those with older systems or many custom packages. Read, yes, read, but if you read the wiki and did the first: pacman -Syu --ignore glibc _before_ you rebuilt all the needed custom packages, then you were left unable to build them until you completed the glibc install due to linker and other needed links being moved from /lib to /usr/lib before the symlink of /lib -> /usr/lib is created _after_ the glibc update. There are a few sticky wickets in there, involving temporary package removal with -Rdd in order to complete the glibc install to be able to rebuild some of the offending packages. The better was to first verify what packages had files in /lib and then rebuild until only glibc had files in /lib, then do the first pacman -Syu --ignore glibc Only experience showed that was the way to go.. -- David C. Rankin, J.D.,P.E.
On 23 July 2012 23:42, David C. Rankin <drankinatty@suddenlinkmail.com>wrote:
On 07/23/2012 09:22 PM, Martin Cigorraga wrote:
Again: people don't read, screw up their system and then blame the change... :P
In some case yes, in some cases, that's not quite true. The usrlib change depended a great deal on how old your Arch install was, how many custom packages you had built with files in /lib, how many initramfs you have generated over the years, whether you have older versions of virtualbox around, whether you every used nvidia, etc.., etc.. etc..
It was no small change for those with older systems or many custom packages.
Read, yes, read, but if you read the wiki and did the first:
pacman -Syu --ignore glibc
_before_ you rebuilt all the needed custom packages, then you were left unable to build them until you completed the glibc install due to linker and other needed links being moved from /lib to /usr/lib before the symlink of /lib -> /usr/lib is created _after_ the glibc update. There are a few sticky wickets in there, involving temporary package removal with -Rdd in order to complete the glibc install to be able to rebuild some of the offending packages.
The better was to first verify what packages had files in /lib and then rebuild until only glibc had files in /lib, then do the first pacman -Syu --ignore glibc
Only experience showed that was the way to go..
-- David C. Rankin, J.D.,P.E.
Good point - I didn't see that. I agree with you, but my personal experience with the upgrade was quite smooth in my three home machines: 1 old laptop I use as server, 1 tower I use for NAS and my personal laptop which is a 4x4 multi purpose system - being my notebook a 1 and half year old and the other two 1 year old each. All I had to do was remove a few packages that had files installed in /lib, update glibc reinstall them and continue with my life :) The beauty behind this is we are now enjoying the new paradigm without reinstalling the system while with other distros your only chance to make the switch is reinstall not only your OS but everything else! Cheers. -- -msx
On 07/24/2012 01:15 AM, Martin Cigorraga wrote:
The beauty behind this is we are now enjoying the new paradigm without reinstalling the system while with other distros your only chance to make the switch is reinstall not only your OS but everything else! Cheers.
Now that... is the beauty of Arch! The other distro's release/reinstall cycle is far more work than the rolling-release. But, after packaging trinity on Arch, I can tell you it is a double-edge sword. You get everything building just fine until the next pacman -Syu and then 5 packages quit building due to package updates (libpng, ffmpeg, gcc, on-and-on, ...) Literally you can kick off a build in the morning, then update and have it go to hell in the evening. It gives you a great deal of respect for the sheer amount of work the Arch developers put into this disto.... -- David C. Rankin, J.D.,P.E.
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
On Fri, Jul 20, 2012 at 10:36 PM, D. R. Evans <doc.evans@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
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.evans@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
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
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
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 /var/lib/pacman/local/glibc-2.15-10/files:lib/libthread_db.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libutil-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libutil.so.1 [root@shack tmp]#
I *think* that this means that in fact glibc owns all the files. So I don't understand what I'm supposed to do next. The wiki simply says that it is "most likely" that there are files that aren't owned by glibc. It doesn't seem to say what to do when glibc *does* own all the files. Maybe I'm missing an instruction somewhere, but I don't see it. Doc -- Web: http://www.sff.net/people/N7DR
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
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
On Sat, Jul 21, 2012 at 4:57 PM, D. R. Evans <doc.evans@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
On 07/21/2012 11:24 AM, Tom Gundersen 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
On Sat, Jul 21, 2012 at 4:57 PM, D. R. Evans <doc.evans@gmail.com> wrote: 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 -- {} + 2>&1 | grep 'No package'
On Wed, 18 Jul 2012 12:27:11 +0200 Tom Gundersen <teg@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 Cheers 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
On Wed, 18 Jul 2012 12:27:11 +0200 Tom Gundersen <teg@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 Thanks Pete . -- Linux 7-of-9 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012 x86_64 GNU/Linux
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 <teg@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
Thanks Pete .
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. -- дамјан
participants (20)
-
Alex Belanger
-
Andrew Hills
-
André Gasser
-
Ariel Popper
-
Baho Utot
-
D. R. Evans
-
Daenyth
-
Damjan
-
Daniel Wallace
-
David Benfell
-
David C. Rankin
-
Florian Pritz
-
Guus Snijders
-
Manolo Martínez
-
Martin Cigorraga
-
Matthew Monaco
-
Mauro Santos
-
Norbert Zeh
-
P .NIKOLIC
-
Tom Gundersen