An emerge process aborted because /usr was not writable. According to the build log this happened after ">>> Completed installing ... into .../image". I tried to fix this up by running "ebuild /path/to/ebuild qmerge", but it complained "!!! mydo=qmerge, but the install phase has not been run". Issuing a normal "merge" reran the installation phase and only then merged as expected. Reproducible: Always
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
