| Summary: | sys-apps/portage: detect readonly filesystems and bail out before pkg_preinst | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=664380 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 505428 | ||
| Bug Blocks: | 707318, 713870, 484436, 532264 | ||
| Attachments: | test-readonly-filesystems.patch | ||
|
Description
Dennis Schridde
2011-08-12 07:37:38 UTC
The merge phase removes $PORTAGE_BUILDDIR/.installed just before pkg_preinst, since merge moves files out of $D and therefore the state created by src_install is no longer valid. So, that's why you had to run src_install again. I don't see anything wrong with this. Is there something we can do to improve it? It was just very unexpected that I first saw the install phase completing (in the build.log) and then qmerge claiming it was never run. I think we can improve it by checking for readonly filesystems during the collision detection phase. Then we'll be able to bail out before the merge phase, and avoid corrupting ${D}, so there won't be any need to run src_install over again.
That would be an awesome feature! The next step might be to automatically mount these if requested, e.g. via FEATURES=automount (non-default), to cause even less disturbance. Iirc there exist such mechanisms for /boot in the grub ebuilds...? Created attachment 367762 [details, diff]
test-readonly-filesystems.patch
Here's a patch for this, it's been submitted to gentoo-portage-dev@
Revised patch pushed as commit 706d7479af1cb3911adfa917825b499222b781bd Can I suggest using /etc/mtab instead of /proc/mounts ? Use case: /proc/mounts inside a chroot does see mount points that are outside of chroot, thus providing writeable_check.py with false info. /etc/mtab is not a source of truth by any means. The kernel could remount a filesystem readonly due to errors, or /etc/mtab may not be writable at the time of the mount or unmount, or you could lazy unmount an entire tree of mounts. /proc/mounts is the only definitive source of what's mounted and what state it's in. Reversing the order of the /proc/mounts search for the filesystem being checked would resolve most of the issues with the current implementation, though it presents its own edge cases. I've suggested this to creffett on IRC already. dwfreed, totally agree on the "non 100% true" part.... Hovever, reverse order wouldn't be the "correct" way, as it wouldn't be able to pick the right mount point when there's multiple of them mounted. It would just get the last mounted one. I have this particular use case going on... If anyone know how to filter /proc/mounts, please let me know. Only for ancillary filesystems. For example: 1. Mount /mnt/gentoo from somewhere, unpack stage3, and chroot into it 2. In another session still in real root, mount a readonly filesystem to /srv 3. Try to install a package that puts files in /srv from inside the chroot (It's important to note that it has to be a *new* mount; using mount -o remount does not reorder /proc/mounts at all) Portage would fail, thinking /srv was readonly, even though it's not. This is one of few edge cases that a reverse search would not cover. However, the usual case, /, would always get you the correct mountpoint in a reverse search. An workaround outside of portage would be to use a separate mount namespace for the chroot, and only share mounts that are or are under the chroot path with that new namespace. BRB, RTM'img mount namespaces. released in portage-2.2.11 |
