[arch-general] glibc issues during first update in several months
After several months of not updating my home server, I decided to run updates tonight. I still hadn't done the /usr/lib symlink move, so I followed the guide on the wiki like I did for my other boxes and still ended up borking my system. Think this is because I accidentally said "yes" to upgrading pacman before the other packages. I ended up finding this thread on the forum: https://bbs.archlinux.org/viewtopic.php?pid=1167283 After booting with a rescue disc and untar-ing the package into my root partition as that thread suggested, I was able to get booted back up and continue with the upgrade. However, once I got to the point where I do the final pacman -Su, I got a bunch of file conflicts: error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem glibc: /usr/include/bits/byteswap-16.h exists in filesystem glibc: /usr/include/bits/epoll.h exists in filesystem glibc: /usr/include/bits/eventfd.h exists in filesystem glibc: /usr/include/bits/hwcap.h exists in filesystem glibc: /usr/include/bits/inotify.h exists in filesystem glibc: /usr/include/bits/poll2.h exists in filesystem glibc: /usr/include/bits/signalfd.h exists in filesystem glibc: /usr/include/bits/socket_type.h exists in filesystem glibc: /usr/include/bits/sysctl.h exists in filesystem glibc: /usr/include/bits/timerfd.h exists in filesystem glibc: /usr/include/stdc-predef.h exists in filesystem glibc: /usr/include/sys/auxv.h exists in filesystem glibc: /usr/include/sys/elf.h exists in filesystem glibc: /usr/include/sys/vm86.h exists in filesystem glibc: /usr/include/uchar.h exists in filesystem glibc: /usr/share/i18n/locales/mag_IN exists in filesystem Errors occurred, no packages were upgraded. Is it safe to run the pacman -Su with --force since these files are all owned by newer glibc on my other Arch boxes? % for file in /usr/include/bits/byteswap-16.h /usr/include/bits/epoll.h /usr/include/bits/eventfd.h /usr/include/bits/hwcap.h /usr/include/bits/inotify.h /usr/include/bits/poll2.h /usr/include/bits/signalfd.h /usr/include/bits/socket_type.h /usr/include/bits/sysctl.h /usr/include/bits/timerfd.h /usr/include/stdc-predef.h /usr/include/sys/auxv.h /usr/include/sys/elf.h /usr/include/sys/vm86.h /usr/include/uchar.h /usr/share/i18n/locales/mag_IN; do pacman -Qo $file; done /usr/include/bits/byteswap-16.h is owned by glibc 2.16.0-4 /usr/include/bits/epoll.h is owned by glibc 2.16.0-4 /usr/include/bits/eventfd.h is owned by glibc 2.16.0-4 /usr/include/bits/hwcap.h is owned by glibc 2.16.0-4 /usr/include/bits/inotify.h is owned by glibc 2.16.0-4 /usr/include/bits/poll2.h is owned by glibc 2.16.0-4 /usr/include/bits/signalfd.h is owned by glibc 2.16.0-4 /usr/include/bits/socket_type.h is owned by glibc 2.16.0-4 /usr/include/bits/sysctl.h is owned by glibc 2.16.0-4 /usr/include/bits/timerfd.h is owned by glibc 2.16.0-4 /usr/include/stdc-predef.h is owned by glibc 2.16.0-4 /usr/include/sys/auxv.h is owned by glibc 2.16.0-4 /usr/include/sys/elf.h is owned by glibc 2.16.0-4 /usr/include/sys/vm86.h is owned by glibc 2.16.0-4 /usr/include/uchar.h is owned by glibc 2.16.0-4 /usr/share/i18n/locales/mag_IN is owned by glibc 2.16.0-4 -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." -- Carl Sagan
On 10/02/2012 01:30 AM, Erik Johnson wrote:
After several months of not updating my home server, I decided to run updates tonight. I still hadn't done the /usr/lib symlink move, so I followed the guide on the wiki like I did for my other boxes and still ended up borking my system. Think this is because I accidentally said "yes" to upgrading pacman before the other packages. I ended up finding this thread on the forum:
https://bbs.archlinux.org/viewtopic.php?pid=1167283
After booting with a rescue disc and untar-ing the package into my root partition as that thread suggested, I was able to get booted back up and continue with the upgrade.
I recently ran into similar issues resulting from my taking care of this upgrade much later than when it was released. FYI, though, for future reference: there's an alternative (and an arguably more "correct" one) to untar-ing a package into your root directory to fix issues like this. If you boot into an Arch Linux installation disk, you can then use the copy of pacman installed on that disk to "properly" install packages onto your hard disk. You just have to use the "-r" (change root) parm of pacman to do it. So for example, you can do things like this (e.g., if the root file system of your hard disk is mounted at /mnt/temp): $ pacman -r /mnt/temp -U /mnt/temp/var/cache/pacman/pkg/<some-package>.pkg.xz Doing things this way will make sure that the pacman database on your hard disk gets updated correctly when you install the packages to fix the breakage. HTH, DR
On Tue, Oct 2, 2012 at 12:49 AM, David Rosenstrauch
On 10/02/2012 01:30 AM, Erik Johnson wrote:
After several months of not updating my home server, I decided to run updates tonight. I still hadn't done the /usr/lib symlink move, so I followed the guide on the wiki like I did for my other boxes and still ended up borking my system. Think this is because I accidentally said "yes" to upgrading pacman before the other packages. I ended up finding this thread on the forum:
https://bbs.archlinux.org/**viewtopic.php?pid=1167283https://bbs.archlinux.org/viewtopic.php?pid=1167283
After booting with a rescue disc and untar-ing the package into my root partition as that thread suggested, I was able to get booted back up and continue with the upgrade.
I recently ran into similar issues resulting from my taking care of this upgrade much later than when it was released.
FYI, though, for future reference: there's an alternative (and an arguably more "correct" one) to untar-ing a package into your root directory to fix issues like this. If you boot into an Arch Linux installation disk, you can then use the copy of pacman installed on that disk to "properly" install packages onto your hard disk. You just have to use the "-r" (change root) parm of pacman to do it. So for example, you can do things like this (e.g., if the root file system of your hard disk is mounted at /mnt/temp):
$ pacman -r /mnt/temp -U /mnt/temp/var/cache/pacman/** pkg/<some-package>.pkg.xz
Doing things this way will make sure that the pacman database on your hard disk gets updated correctly when you install the packages to fix the breakage.
HTH,
DR
Yeah... I got everything sorted, by the way, so no worries. -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." -- Carl Sagan
participants (2)
-
David Rosenstrauch
-
Erik Johnson