Hi, I ran an emerge --depclean. That went smoothly. Later I found that /usr was mounted ro at the time. Basically, portage told me that it was removing all those files from the system, when it actually didn't happen because /usr was mounted read only. Reproducible: Always Steps to Reproduce: 1. Mount /usr read only. 2. Unmerge a package that installs its files in /usr. Actual Results: Portage told me that it was removing the files, when it couldn't actually do it because /usr was ro. Portage didn't recognise that the files weren't actually deleted and assumed that the unmerge was successful. Expected Results: Portage should actually notice if the files its trying to remove are actually removed from the disk. I think it should also notice that it is trying to remove a file on a read only filesystem.
What exactly is it supposed to do if it realizes in the middle of an unmerge that 1 file can't be deleted? You can't really abort an unmerge in the middle.
(In reply to comment #1) > What exactly is it supposed to do if it realizes in the middle of an unmerge > that 1 file can't be deleted? You can't really abort an unmerge in the middle. Well, emerge will abort if pkg_postrm() fails, for example. I suppose we can do the same if an OSError occurs when trying to unlink a file. Then, at least the user will have an opportunity to retry the unmerge.
!!! Cannot write to '/usr'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/app-text/nopaste/nopaste-1992.ebuild merge !!! And finish by running this: env-update If that happens while installing a package, why can't it happen while uninstalling it? And no, portage shouldn't stop after deleting a few files and leaving the package in a chaotic state, but it should at least warn the user or something. Maybe keep available the list of files not removed, due to an error, so the user doesn't have emerge and then unmerge the package again. I had to remerge 63 packages and then unmerge them to recover all the wasted hard disk space.
I was about to report this when I remembered I need to search first.... :-) The unlink(2) system call sets a specific error code (EROFS) when requested to unlink a file on a read-only filesystem. Portage could perhaps check for this result, as distinguished from harmless errors (file not found, etc.) and abort the unmerge with a message similar to that cited in comment #3. This would squash the nasty part of this bug: removal of a package from the database while its contents remain on the live filesystem. Speaking as a user, this is behavior I would understand and desire. I wouldn't mind if Portage left a package half-cleaned, provided: 1) it didn't uninstall such a package from the database. and 2) it gracefully continued past already-cleaned files on subsequent unmerge attempts. At least this way, a record of any cruft would still exist on the system, in /var/db/pkg/${package}/CONTENTS. I will attach a simple ebuild I slapped together to verify this as a bug; perhaps it will be useful. To use: 1. Install the ebuild in an overlay. 2. Make a small filesystem (1MB on a loopback is more than plenty) and mount it read-write at /mnt. 3. ACCEPT_KEYWORDS="~x86" emerge -1a rofs-bug-demo 4. Note the file installed to /mnt. 5. mount -o remount,ro /mnt 6. emerge -C rofs-bug-demo 7. ls /mnt -- you will see the installed file still exists 8. emerge -s rofs-bug-demo -- Portage claims the package is not installed.
Created attachment 118959 [details] app-misc/rofs-bug-demo-0.1.ebuild Installs a single file under /mnt. Unmerge it with /mnt mounted RO to reproduce this bug.
In svn r7804 it's fixed so that it will only ignore some specific exceptions.
This has been released in 3.1.3.10.
(In reply to comment #7) > This has been released in 3.1.3.10. > I pray you meant 2.1.3.10, as I don't recall jumping an entire version ahead ;)
