On Sat, 7 Jul 2012 21:51:43 +0200, Lukas Fleischer wrote:
On Sat, Jul 07, 2012 at 08:32:36PM +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 21:15:50 +0200, Lukas Fleischer wrote:
On Sat, Jul 07, 2012 at 06:53:21PM +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 19:32:57 +0200, Geert Hendrickx wrote:
On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote: >You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I did NOT.
Was /lib your current working dir when you ran pacman? Or did any other process have it open so it could not be removed?
Geert
Post event it's hard to tell. I previously removed obsolete firmware, modules and udev directories, then ran the commands from a previous thread (cut and paste, no --force).
# pacman -Syu --ignore glibc # pacman -S glibc
The current directory was NOT /lib, and as the system is now pretty much as loaded as prior, fuser /usr/lib (or /lib) shows no results.
What's the output of `grep '^lib' /var/lib/pacman/local/*/files`?
/var/lib/pacman/local/glibc-2.16.0-2/files:lib /var/lib/pacman/local/glibc-2.16.0-2/files:lib64 /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/guestfsd.service /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/multipathd.service /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/kpartx_id
See. Both libguestfs and multipath-tools-git own files in "/lib". You should have dealt with that (i.e. rebuild these and put stuff in "/usr/lib" instead of "/lib") before upgrading.
Even post-event it is interesting to see such expert analysis as to why the system gets broken, tinged with some disappointment that the packaging system does not appear to warn the user apriori of a somewhat unfortunate outcome. Anyway, thanks for your expert diagnosis. I at least now understand why this happened. -jh