| Summary: | sys-apps/portage-2.2.14 has overly aggressive read-only filesystem checks | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Stuart Shelton <srcshelton> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 484436 | ||
Yes, the current logic is extremely flawed. A really simple fix would be to use os.stat(path).st_dev to get the unique device number of each read-only directory, and then search for files that would be merged on a read-only device. There's a patch in the following branch: https://github.com/zmedico/portage/tree/bug_547390 It's fixed to check only if the nearest parent directory is writable. (In reply to Stuart Shelton from comment #0) > It might also be helpful, if this doesn't > already exist for debug purposes, to list /which/ files would be installed > to a read-only filesystem if the install were to be allowed to proceed.) The current patch shows only the nearest existing parent directories of those files. (In reply to Zac Medico from comment #3) > The current patch shows only the nearest existing parent directories of > those files. Now it only shows paths from mountinfo, which is more consistent with the existing output. You can install my branch for testing purposes like this: portage_LIVE_REPO=https://github.com/zmedico/portage.git \ portage_LIVE_BRANCH=bug_547390 \ ACCEPT_KEYWORDS="**" emerge --oneshot =sys-apps/portage-9999 This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=fb421c04f4754b5cdc1101bd5c64d27c00e5ea8d Released in portage-2.2.19 |
After attempting to emerge sys-apps/man-pages, an ebuild which only installs data beneath /usr/share, I get the following fatal error: * One or more files installed to this package are set to be installed to * read-only filesystems. Please mount the following filesystems as read- * write and retry. * * / * ... and to confirm: $ grep -v '/usr/' /var/db/pkg/sys-apps/man-pages-3.82/CONTENTS dir /usr ... so this is correct, in that '/' is read-only. However, '/usr' (as well as '/var', for 'db/pkg') are writable. Even if, for performance reasons, the read-only check can't examine every path that an ebuild installs files to (although getting a list of mount-points and then resolving paths from ${D} against them seems fairly do-able) then checking for common mount-points such as this would seem to be beneficial. (Is the problem actually that single '/usr' entry above lives in '/', and therefore '/' must be writable in case '/usr' doesn't exist? In this case, directories which already exist (with appropriate permissions? ... and possibly unchanged files also?) could be removed from the list of items checked by the read-only test. It might also be helpful, if this doesn't already exist for debug purposes, to list /which/ files would be installed to a read-only filesystem if the install were to be allowed to proceed.)