On 22/01/14 06:01, Nagy Gabor wrote: >> Hello, >> >> It seems I found a bug in pacman. Some information first: >> version: pacman 4.1.2-5 prebuilt from official repo >> system: Linux 3.12.7-2-ARCH i686 >> >> So it happened when I tried to remove alex package. >> >> $ sudo pacman -R alex >> [sudo] password for michael: >> checking dependencies... >> >> Packages (1): alex-3.1.3-1 >> >> Total Removed Size: 1.18 MiB >> >> :: Do you want to remove these packages? [Y/n] y >> error: cannot remove file '/usr/': Read-only file system >> ldconfig: Can't create temporary cache file /etc/ld.so.cache~: >> Read-only file system >> error: command failed to execute correctly >> >> Uhm... I forgot I have root filesystem mounted read-only. No problem. >> >> $ sudo mount / -o remount,rw >> $ sudo pacman -R alex >> error: target not found: alex >> >> What? How could pacman remove the package from a read-only filesystem? > > Well, pacman just removed the database entry (from the > writeable /var/lib/pacman/)... > This behaviour is clearly odd here, but it is not easy to say what is > the expected behaviour in general, for example, what should we do when > only ONE file cannot be removed? AFAIK, pacman cannot "undo" > transaction after it has been started atm (transaction rollback is not > implemented), so the only options are "pre-remove check" or stop. > > Theoretically, pacman should collect "file foo has become untracked due > to a removal error" somehow (for example, we could rename the package to > alex-garbage in the database, keeping the non-removed files in its > filelist), but that would definitely violate KISS and it would be not so > easy to implement (directories are also listed in the filelist of a > package, possible conflicts of garbage packages, etc.). > > I cannot see a clean "filesystem check" solution neither. >
I can... we already check if a filesystem is read-only during an install/upgrade (with the DiskSpace option). I think it would be quite simple to add a check before any package removal starts. I have opened a bug to track this: https://bugs.archlinux.org/task/38615 Allan
