[pacman-dev] Orphaning files in the filesystem after unsuccessful pacman -R
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? Or maybe... $ sudo pacman -S alex resolving dependencies... looking for inter-conflicts... Packages (1): alex-3.1.3-1 Total Installed Size: 1.18 MiB :: Proceed with installation? [Y/n] y (1/1) checking keys in keyring [###] 100% (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) alex: /usr/bin/alex exists in filesystem alex: /usr/share/alex/AlexTemplate exists in filesystem alex: /usr/share/alex/AlexTemplate-debug exists in filesystem alex: /usr/share/alex/AlexTemplate-ghc exists in filesystem alex: /usr/share/alex/AlexTemplate-ghc-debug exists in filesystem alex: /usr/share/alex/AlexTemplate-ghc-nopred exists in filesystem alex: /usr/share/alex/AlexWrapper-basic exists in filesystem alex: /usr/share/alex/AlexWrapper-basic-bytestring exists in filesystem alex: /usr/share/alex/AlexWrapper-gscan exists in filesystem alex: /usr/share/alex/AlexWrapper-monad exists in filesystem alex: /usr/share/alex/AlexWrapper-monad-bytestring exists in filesystem alex: /usr/share/alex/AlexWrapper-monadUserState exists in filesystem alex: /usr/share/alex/AlexWrapper-monadUserState-bytestring exists in filesystem alex: /usr/share/alex/AlexWrapper-posn exists in filesystem alex: /usr/share/alex/AlexWrapper-posn-bytestring exists in filesystem alex: /usr/share/alex/AlexWrapper-strict-bytestring exists in filesystem alex: /usr/share/licenses/alex/BSD3 exists in filesystem Errors occurred, no packages were upgraded. ...it didn't remove anything of course, but broke the database. Here is the point of the bug report. I repaired things like this: $ sudo pacman -S --force alex resolving dependencies... looking for inter-conflicts... Packages (1): alex-3.1.3-1 Total Installed Size: 1.18 MiB :: Proceed with installation? [Y/n] y (1/1) checking keys in keyring [###] 100% (1/1) checking package integrity [###] 100% (1/1) loading package files [###] 100% (1/1) checking for file conflicts [###] 100% (1/1) checking available disk space[###] 100% (1/1) installing alex [###] 100% $ sudo pacman -R alex 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 (1/1) removing alex [###] 100% but this is all but elegant. The same problem occurred for several other packages, in identical way. I'm very surpised to find bug like that in pacman and still not sure that it isn't just my mistake somewhere. Anyway, please test it. I hope this report will help you. What do you think? Best regards Michał Szymański
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. NG
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
In fact, the first thing I thought about when noticed a bug was that
pacman actually checks before installing - but I forgot to mention it.
Of course, there are probably lots of things not worth implementing
because pacman is by its goal simple (and I like it especially for its
simplicity). However, checking for a filesystem being read-only is
rather basic feature in a package manager.
Thanks for your fast response and for opening a bug in tracker.
Pozdrawiam,
Michał Szymański
2014/1/22 Allan McRae
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
participants (3)
-
Allan McRae
-
Nagy Gabor
-
smiszym