Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 378869

Summary: sys-apps/portage: detect readonly filesystems and bail out before pkg_preinst
Product: Portage Development Reporter: Dennis Schridde <dschridde+gentoobugs>
Component: CoreAssignee: Portage team <dev-portage>
Severity: normal Keywords: InVCS
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also:
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
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
Comment 1 Zac Medico gentoo-dev 2011-08-12 10:31:13 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?
Comment 2 Dennis Schridde 2011-08-13 06:42:53 UTC
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.
Comment 3 Zac Medico gentoo-dev 2011-08-13 08:45:19 UTC
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.
Comment 4 Dennis Schridde 2011-08-13 09:05:01 UTC
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...?
Comment 5 Chris Reffett (RETIRED) gentoo-dev Security 2014-01-13 02:40:49 UTC
Created attachment 367762 [details, diff]

Here's a patch for this, it's been submitted to gentoo-portage-dev@
Comment 6 Chris Reffett (RETIRED) gentoo-dev Security 2014-01-27 21:48:22 UTC
Revised patch pushed as commit 706d7479af1cb3911adfa917825b499222b781bd
Comment 7 ViliusSutkus89 2014-03-25 19:44:11 UTC
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 with false info.
Comment 8 dwfreed 2014-03-26 20:23:55 UTC
/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.
Comment 9 ViliusSutkus89 2014-03-26 20:37:05 UTC
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.
Comment 10 dwfreed 2014-03-26 20:50:14 UTC
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.
Comment 11 ViliusSutkus89 2014-03-26 20:56:19 UTC
BRB, RTM'img mount namespaces.
Comment 12 Brian Dolbec gentoo-dev 2014-08-04 02:02:37 UTC
released in portage-2.2.11