Summary: | Portage (successfully?) trying to delete files on a read only file system | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Mrugesh Karnik <floyd_n_milan> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | floyd_n_milan, hkbst, timebandit |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 194041 | ||
Attachments: | app-misc/rofs-bug-demo-0.1.ebuild |
Description
Mrugesh Karnik
2007-02-28 18:21:28 UTC
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 ;) |