Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 378869 - sys-apps/portage: detect readonly filesystems and bail out before pkg_preinst
Summary: sys-apps/portage: detect readonly filesystems and bail out before pkg_preinst
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
Keywords: InVCS
Depends on: 505428
Blocks: 707318 713870 484436 532264
  Show dependency tree
Reported: 2011-08-12 07:37 UTC by Dennis Schridde
Modified: 2020-03-21 23:08 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

test-readonly-filesystems.patch (0001-Test-for-read-only-filesystems-bail-out-during-prein.patch,4.47 KB, patch)
2014-01-13 02:40 UTC, Chris Reffett (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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