Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 532264 - mount-boot.eclass fails to mount /boot (with >=sys-apps/portage-2.2.14)
Summary: mount-boot.eclass fails to mount /boot (with >=sys-apps/portage-2.2.14)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords: PullRequest
: 537402 (view as bug list)
Depends on: 378869
Blocks:
  Show dependency tree
 
Reported: 2014-12-11 12:56 UTC by Jaco Kroon
Modified: 2020-02-21 18:34 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaco Kroon 2014-12-11 12:56:05 UTC
current stable portage 2.2.14 performs a read-only check for the destination folders of an install, which is all fine, but pkg_preinst should probably run beforehand so as to ensure that remounts to rw (ala mount-boot eclass) can function properly.  Currently trying to merge packages relying on mount-boot utilizing a read-only /boot results in merge failure:

 * 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.
 * 
 *      /boot
 * 
 * Package 'sys-apps/memtest86-3.3' NOT merged due to read-only file
 * systems. If necessary, refer to your elog messages for the whole
 * content of the above message.

I tested with 2.2.15 and the same problem occurs.

Reproducible: Always

Steps to Reproduce:
1. set up a read-only /boot.
2. emerge -av memtest86 (or any other package relying on mount-boot)
Actual Results:  
 * 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.
 * 
 *      /boot
 * 
 * Package 'sys-apps/memtest86-3.3' NOT merged due to read-only file
 * systems. If necessary, refer to your elog messages for the whole
 * content of the above message.


Expected Results:  
successful merge.

Portage 2.2.14 (python 2.7.7-final-0, default/linux/amd64/13.0/no-multilib, gcc-4.7.3, glibc-2.19-r1, 3.7.3-uls x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-3.7.3-uls-x86_64-Intel-R-_Core-TM-_i3-2100_CPU_@_3.10GHz-with-gentoo-2.2
KiB Mem:     8086232 total,    689308 free
KiB Swap:    1048568 total,   1017232 free
Timestamp of tree: Wed, 10 Dec 2014 23:00:01 +0000
ld GNU ld (Gentoo 2.23.2 p1.0) 2.23.2
app-shells/bash:          4.2_p53
dev-lang/perl:            5.18.2-r1
dev-lang/python:          2.7.7, 3.2.5-r6, 3.3.5-r1, 3.4.1
dev-util/cmake:           2.8.12.2-r1
dev-util/pkgconfig:       0.28-r1
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.12.4
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.69
sys-devel/automake:       1.11.6, 1.12.6, 1.13.4
sys-devel/binutils:       2.23.2
sys-devel/gcc:            4.7.3-r1
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2-r1
sys-devel/make:           4.0-r1
sys-kernel/linux-headers: 3.13 (virtual/os-headers)
sys-libs/glibc:           2.19-r1
Repositories: gentoo uls
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA Intel-SDP"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe -g -ggdb"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=native -pipe -g -ggdb"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--backtrack=30"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_ZA.iso88591"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://tauri.local.uls.co.za/gentoo-portage"
USE="acpi amd64 apache2 bash-completion bzip2 cli cracklib crypt cxx diskio dri g729 gzip iconv iproute2 ithreads jpeg kpathsea latin1 logrotate mad mmx modules mysql ncurses nptl nptlonly openmp pam pcre png readline session sox sse sse2 ssl threads xetex zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="alias autoindex deflate dav dir env expires headers include info mime mime_magic negotiation rewrite status vhost_alias filter authz_core authz_host auth_basic auth_digest authz_default authz_user authn_core dav_fs dav_lock cgi unixd log_config socache_shmcb proxy proxy_fcgi version" APACHE2_MPMS="event" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_GB en af" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" SANE_BACKENDS="hp hpljm1005" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-01-23 05:53:36 UTC
*** Bug 537402 has been marked as a duplicate of this bug. ***
Comment 2 Zac Medico gentoo-dev 2015-01-23 06:29:21 UTC
We could add a PORTAGE_FS_RO_CHECK_EXCLUDE variable so that you could list fnmatch patterns for directories to exclude, with syntax identical to UNINSTALL_IGNORE.
Comment 3 Jaco Kroon 2015-01-23 10:54:49 UTC
Hi,

That sounds sensible.  Could that potentially be collaborated with the eclass itself?  IE, that simply inheriting mount-boot will exclude /boot from the checks?

Failing that - yes, for me to set that variable is quite trivial and I'll be happy with that as a solution.

Kind Regards,
Jaco
Comment 4 Zac Medico gentoo-dev 2015-01-23 17:36:55 UTC
(In reply to Jaco Kroon from comment #3)
> That sounds sensible.  Could that potentially be collaborated with the
> eclass itself?  IE, that simply inheriting mount-boot will exclude /boot
> from the checks?

You could file a bug for PMS, to establish some sort of protocol for the eclass to communicate this information to the package manager.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-01-23 17:51:07 UTC
We could also ban the eclass for doing insane stuff like fiddling with system mounts by default. Next thing I know, ebuilds restart daemons for my convenience...
Comment 6 Ulrich Müller gentoo-dev 2015-01-23 19:12:36 UTC
(In reply to Zac Medico from comment #4)
> You could file a bug for PMS, to establish some sort of protocol for the
> eclass to communicate this information to the package manager.

Sounds complicated. Why not run the test after pkg_preinst instead?


(In reply to Michał Górny from comment #5)
> We could also ban the eclass for doing insane stuff like fiddling with
> system mounts by default.

What problem would that solve? mount-boot.eclass used to work just fine, and /boot is special, so special treatment is justified.
Comment 7 Zac Medico gentoo-dev 2015-01-23 20:52:47 UTC
(In reply to Ulrich Müller from comment #6)
> (In reply to Zac Medico from comment #4)
> > You could file a bug for PMS, to establish some sort of protocol for the
> > eclass to communicate this information to the package manager.
> 
> Sounds complicated. Why not run the test after pkg_preinst instead?

Well, if we use the same argument as for collision-protect/protect-owned, we do it before pkg_preinst so that we can abort before pkg_preinst has had an opportunity to produce any side-effects that would put the system in an inconsistent state. The fact that mount-boot.eclass can modify mounts in pkg_preinst is just one of many possible side-effects that could occur.
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-01-23 21:31:17 UTC
(In reply to Ulrich Müller from comment #6)
> (In reply to Michał Górny from comment #5)
> > We could also ban the eclass for doing insane stuff like fiddling with
> > system mounts by default.
> 
> What problem would that solve? mount-boot.eclass used to work just fine, and
> /boot is special, so special treatment is justified.

Oh, the usual argument. We did something stupid, it worked, so it was a good thing to do!

So yes, /boot is special. If it weren't, people wouldn't be mounting it read-only in the first place. But since it is, I don't want a few random packages to be remounting it and playing with it for me silently. If at all, this should be opt-in, not opt-out.

And more generally, eclass is definitely *NOT* the place for any mount mangling. The code is poor and fragile. It may cause random issues on any more complex setup. Users with complex setups may be completely unaware of this ugly magic happening behind the scenes and unprepared for having their systems broken.

So as a QA member, my vote is kill it with fire, bury deep and surround with barbed wire so that nobody tries that again.
Comment 9 Ulrich Müller gentoo-dev 2015-01-24 00:10:45 UTC
Well then, the eclass could verify in pkg_pretend() that /boot is mounted rw. If not, emit an appropriate message and abort the build.

However, I am not convinced that this will make users happy.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-01-24 08:58:28 UTC
(In reply to Ulrich Müller from comment #9)
> Well then, the eclass could verify in pkg_pretend() that /boot is mounted
> rw. If not, emit an appropriate message and abort the build.

Yes, that's what I wanted to suggest and forgot about it :P.
Comment 11 Zac Medico gentoo-dev 2015-01-24 19:44:55 UTC
Maybe we should simply add FEATURES="fs-ro-check" setting so that users can disable the check globally? That way, users can choose to delegate re-mounting of file systems to things like mount-boot.eclass if they choose (and I agree with Michał that mount-boot.eclass should be opt-in rather than opt-out).
Comment 12 SpanKY gentoo-dev 2015-07-30 06:15:09 UTC
(In reply to Michał Górny from comment #8)

conversely, it's easy to complain about things you don't like w/out suggesting real solutions.  people often have a sep /boot for a variety of reasons ... off the top of my head:
 - the bootloader requires it
 - they use raid on the root
 - they have an encrypted root
 - they have a network root
 - their hosted services force the requirement on them
this is a fully supported configuration and trying to merge it with / is not realistic, nor is it in the same category as split /usr.

experience has shown that it's fairly common then for people to list /boot in /etc/fstab and then either use noauto or ro.  in fact, the default Gentoo fstab does exactly that.  since /boot is rarely updated, leaving it that way normally makes a bit of sense.  i've seen very few people do it as a matter of paranoia and get upset when things are managed automatically.

however, people do like it when this "just works" and they file bugs when portage does the wrong thing (installs files into the /boot that's in /, or fails with read-only errors).  especially when the window to have /boot be mounted & rw is fairly small (long enough to run the $D->$ROOT merge).

pkg_pretend is not sufficient because it doesn't cover the unmerge case -- doing `emerge -C memtest86` will fail spectacularly when ro and will silently unmerge the package but leave the files behind when noauto.  nor is it user friendly like the current code.

(In reply to Zac Medico from comment #11)

why not move the read-only checks to after the pkg_preinst phase runs ?  then mount-boot.eclass can do its thing, and the checks will pass, and there's no need for knobs (either in the ebuild or eclass or user's config).
Comment 13 Zac Medico gentoo-dev 2015-07-30 06:28:09 UTC
(In reply to SpanKY from comment #12)
> why not move the read-only checks to after the pkg_preinst phase runs ? 
> then mount-boot.eclass can do its thing, and the checks will pass, and
> there's no need for knobs (either in the ebuild or eclass or user's config).

I don't see a reason why we couldn't do that. We'd just have to move the ro_checker code further down in the dblink.treewalk method, immediately after these lines:

		# XXX: Decide how to handle failures here.
		if a != os.EX_OK:
			showMessage(_("!!! FAILED preinst: ")+str(a)+"\n",
				level=logging.ERROR, noiselevel=-1)
			return a
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-07-30 06:33:43 UTC
I'd still do single EROOT write check before pkg_preinst() -- it's quite likely that commands called there will try to write stuff.

That said, if we *really* want eclasses to randomly fiddle with mounts, I dare we have to make Portage use mount namespaces. Though it's pretty simple:

1. you call unshare() to detach the mount namespace (I guess we can reuse the code for network/ipc-sandbox),

2. you call 'mount --make-rslave /' to get all mounts detached from parent namespace.
Comment 15 SpanKY gentoo-dev 2015-07-30 06:40:43 UTC
(In reply to Michał Górny from comment #14)

yes, the eclass needs ROOT checks ... i'll take care of that

if portage started using mount namespaces, it would have to take care in this particular case.  no real way around that unfortunately.
Comment 16 SpanKY gentoo-dev 2015-07-30 07:03:42 UTC
(In reply to Michał Górny from comment #14)

all the logic should be bypassed now when ROOT is being utilized:
http://sources.gentoo.org/eclass/mount-boot.eclass?r1=1.20&r2=1.21
Comment 17 SpanKY gentoo-dev 2015-07-30 07:17:27 UTC
(In reply to Ulrich Müller from comment #9)

i like the idea of pkg_pretend, so i refactored things a bit ... now the code  will do the initial messaging/notice there:
http://sources.gentoo.org/eclass/mount-boot.eclass?r1=1.22&r2=1.23
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-12-04 21:19:52 UTC
Hmm, I suppose these days this eclass won't work at all because mount namespaces will prevent the mount changes from living past the phase function, correct?
Comment 19 Zac Medico gentoo-dev 2019-12-04 21:37:03 UTC
(In reply to Michał Górny from comment #18)
> Hmm, I suppose these days this eclass won't work at all because mount
> namespaces will prevent the mount changes from living past the phase
> function, correct?

Yes that's true, since we haven't disabled mount-sandbox for any phases (unlike pid-sandbox for bug 673794).
Comment 20 Thomas Deutschmann (RETIRED) gentoo-dev 2019-12-05 01:46:51 UTC
Interesting, this a "new".

# mount -o remount,ro /boot
# emerge -1 sys-firmware/intel-microcode  (with USE=initramfs)

fails with

> >>> Installing (1 of 1) sys-firmware/intel-microcode-20191115_p20191110::gentoo
>  * checking 237 files for package collisions
>  * 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.
>  *
>  *      /boot
>  *
>  * Package 'sys-firmware/intel-microcode-20191115_p20191110' NOT merged
>  * due to read-only file systems. If necessary, refer to your elog
>  * messages for the whole content of the above message.
> 
> >>> Failed to install sys-firmware/intel-microcode-20191115_p20191110, Log file:

It doesn't even try to run pkg_preinst() function (https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-firmware/intel-microcode/intel-microcode-20191115_p20191110.ebuild?id=adb505034b7f8a897d310d7fcc17d5a4974d60dc#n117). I.e. you can change ebuild to

> --- a/sys-firmware/intel-microcode/intel-microcode-20191115_p20191110.ebuild
> +++ b/sys-firmware/intel-microcode/intel-microcode-20191115_p20191110.ebuild
> @@ -115,6 +115,8 @@ src_install() {
>  }
> 
>  pkg_preinst() {
> +       die "pkg_preinst() started!"
> +
>         if [[ ${MICROCODE_BLACKLIST} != ${MICROCODE_BLACKLIST_DEFAULT} ]]; then
>                 ewarn "MICROCODE_BLACKLIST is set to \"${MICROCODE_BLACKLIST}\" instead of default \"${MICROCODE_BLACKLIST_DEFAULT}\". You are on your own!"
>         fi
> 

but it will never reach that die statement.
Comment 21 Jaco Kroon 2019-12-06 05:28:20 UTC
Hi,

Yes this was the whole problem.

I recommend removing the eclass once it's been removed from the following ebuilds:

app-emulation/xen/xen-4.11.2-r2.ebuild
app-emulation/xen/xen-4.11.2-r3.ebuild
app-emulation/xen/xen-4.12.1-r3.ebuild
app-emulation/xen/xen-4.13.0_rc3.ebuild
media-gfx/grub-splashes/grub-splashes-20091109.ebuild
sys-apps/fwupdate/fwupdate-10.ebuild
sys-apps/fwupdate/fwupdate-12.ebuild
sys-apps/memtest86/memtest86-4.3.7-r2.ebuild
sys-apps/memtest86+/memtest86+-5.01-r4.ebuild
sys-block/perccli/perccli-7.5.007.0529.ebuild
sys-block/perccli/perccli-7.5.007.0529-r2.ebuild
sys-block/sas2ircu/sas2ircu-19.ebuild
sys-block/sas2ircu/sas2ircu-20.ebuild
sys-block/sas3flash/sas3flash-15.ebuild
sys-block/sas3ircu/sas3ircu-14.ebuild
sys-block/sas3ircu/sas3ircu-15.ebuild
sys-block/sas3ircu/sas3ircu-5.ebuild
sys-boot/cromwell-bin/cromwell-bin-2.40-r1.ebuild
sys-boot/cromwell/cromwell-2.40-r3.ebuild
sys-boot/raspberrypi-firmware/raspberrypi-firmware-1.20190215.ebuild
sys-boot/raspberrypi-firmware/raspberrypi-firmware-1.20190709.ebuild
sys-boot/raspberrypi-firmware/raspberrypi-firmware-1.20190925.ebuild
sys-boot/raspberrypi-firmware/raspberrypi-firmware-9999.ebuild
sys-boot/shlilo-lantank/shlilo-lantank-20040408.ebuild
sys-boot/silo/silo-1.4.14_p20120819-r1.ebuild
sys-boot/silo/silo-1.4.14_p20170829.ebuild
sys-boot/tboot/tboot-1.9.6_p20171118.ebuild
sys-firmware/intel-microcode/intel-microcode-20191115_p20191110.ebuild
sys-kernel/genkernel/genkernel-4.0.0_rc3.ebuild
sys-kernel/genkernel/genkernel-9999.ebuild
sys-kernel/linux-firmware/linux-firmware-20190815.ebuild
sys-kernel/linux-firmware/linux-firmware-20190904.ebuild
sys-kernel/linux-firmware/linux-firmware-20190923.ebuild
sys-kernel/linux-firmware/linux-firmware-20191008.ebuild
sys-kernel/linux-firmware/linux-firmware-20191022.ebuild
sys-kernel/linux-firmware/linux-firmware-20191108.ebuild
sys-kernel/linux-firmware/linux-firmware-99999999.ebuild
sys-kernel/raspberrypi-image/raspberrypi-image-4.14.98_p20190215.ebuild
sys-kernel/raspberrypi-image/raspberrypi-image-4.19.57_p20190709.ebuild
sys-kernel/raspberrypi-image/raspberrypi-image-4.19.75_p20190925.ebuild
sys-kernel/raspberrypi-image/raspberrypi-image-9999.ebuild
sys-power/nvram-reboot/nvram-reboot-2004.10.03-r1.ebuild

(they're all broken anyway and will all die with the above on a read-only mounted /boot anyway, unless nothing it being installed to /boot - in which case, why use the mount-boot eclass?)

I've generated PR 13888 (https://github.com/gentoo/gentoo/pull/13888) which will do the above.

This one is probably worthy of some discussion on the ML.
Comment 22 Ulrich Müller gentoo-dev 2019-12-06 06:01:36 UTC
(In reply to Jaco Kroon from comment #21)
> I recommend removing the eclass once it's been removed from the following
> ebuilds:

I am strongly opposed against this.

> (they're all broken anyway and will all die with the above on a read-only
> mounted /boot anyway, unless nothing it being installed to /boot - in which
> case, why use the mount-boot eclass?)

The least thing that should be done is to error out in pkg_pretend() if /boot is not writable, but not randomly in the middle of a long emerge sequence. In fact I had suggested that already 5 years ago in comment #9:

| Well then, the eclass could verify in pkg_pretend() that /boot is mounted
| rw. If not, emit an appropriate message and abort the build.

Presumably, the check should be called from pkg_preinst and pkg_prerm as well.
Comment 23 Ulrich Müller gentoo-dev 2019-12-06 06:24:35 UTC
I'm working on a patch for mount-boot.eclass that keeps the tests but removes the actual mounting. Stay tuned.
Comment 24 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-12-06 07:21:18 UTC
For the record, I have a WIP ebuild that uses the mounting and umounting functions successfully, provided all of that + /boot writes happen only in postinst.
Comment 25 Jaco Kroon 2019-12-06 11:32:40 UTC
(In reply to Ulrich Müller from comment #23)
> I'm working on a patch for mount-boot.eclass that keeps the tests but
> removes the actual mounting. Stay tuned.

This would be awesome.

Another idea possibly, more generic than simply /boot:

In make.conf:

AUTO_REMOUT(_RW)="/boot"

So in the test for r/o, if such a filesystem is found, and it's listed in the above, remount it RW automatically, else fail out.

Would be nice if that can be per-package somehow, so one of two strategies possible:

AUTO_REMOUNT="/boot"
AUTO_REMOUNT_boot="list of package atoms"

Alternatively:

AUTO_REMOUNT_category_package="/boot"

I'm inclined to lean towards the former solution as it creates me a list of packages that's allowed to install into /boot.  I could take this much, much further than simply /boot ... /usr is (as far as I'm aware) also fairly write-infrequently-read-often (and also only for package installation).  *I THINK*.  I'd need to audit that.  /usr/portage ... different matter.  So think this:

AUTO_REMOUNT="/usr /boot"
AUTO_REMOUNT_boot="sys-boot/grub"

So portage will remount /usr to rw when needed, but for /boot it'll only do so for grub.

Note:  I have not looked at implementation details of existing check that causes this current breakage, but that'd be the point where to implement remount to rw, and then post install a remount back to ro just needs to be added as well.

My 5c.
Comment 26 Larry the Git Cow gentoo-dev 2019-12-11 06:05:01 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2d90570e81469bf75b2d4a4275151e282632c18e

commit 2d90570e81469bf75b2d4a4275151e282632c18e
Author:     Ulrich Müller <ulm@gentoo.org>
AuthorDate: 2019-12-06 13:11:31 +0000
Commit:     Ulrich Müller <ulm@gentoo.org>
CommitDate: 2019-12-11 06:04:49 +0000

    mount-boot.eclass: Check if /boot is sane, but don't try to mount it.
    
    The eclass failed to remount a read-only mounted /boot, because package
    collision sanity checks in recent Portage versions prevented it from
    reaching pkg_preinst() at all. Furthermore, with the "mount-sandbox"
    feature enabled, the mount won't be propagated past pkg_preinst() and
    installed files would end up under the (shadowed) mount point.
    
    Therefore don't even attempt to mount /boot ourselves, but error out
    if it isn't mounted read/write and ask the user to mount /boot.
    
    Also clean up and simplify. (For example, awk is a grown-up program
    which doesn't need any help from egrep or sed. :-)
    
    Closes: https://bugs.gentoo.org/532264
    See-also: https://bugs.gentoo.org/274130#c5
    Acked-by: Jaco Kroon <jaco@uls.co.za>
    Signed-off-by: Ulrich Müller <ulm@gentoo.org>

 eclass/mount-boot.eclass | 144 ++++++++++++++++-------------------------------
 1 file changed, 48 insertions(+), 96 deletions(-)
Comment 27 Joerg Schaible 2020-02-16 15:58:53 UTC
The current behaviour does not respect the --keep-going flag in emerge.

Emerge build with compilations of some heavy packages will take several hours and I schedule them normally over night. It happened to me now multiple times that a such a run was simply aborted completely at the beginning by a package that required a mounted /boot although emerge was started with the --keep-going flag. 

It is very annoying and not user-friendly if you had to detect this many hours later, when you look after the results and expect a upgraded system.
Comment 28 Mike Gilbert gentoo-dev 2020-02-16 17:10:04 UTC
(In reply to Joerg Schaible from comment #27)

Report new bugs in new bug reports please.
Comment 29 Ulrich Müller gentoo-dev 2020-02-16 17:18:37 UTC
(In reply to Joerg Schaible from comment #27)
> The current behaviour does not respect the --keep-going flag in emerge.
> 
> Emerge build with compilations of some heavy packages will take several
> hours and I schedule them normally over night. It happened to me now
> multiple times that a such a run was simply aborted completely at the
> beginning by a package that required a mounted /boot although emerge was
> started with the --keep-going flag. 
> 
> It is very annoying and not user-friendly if you had to detect this many
> hours later, when you look after the results and expect a upgraded system.

That /boot is not mounted should be reported immediately in the pkg_pretend phase, not "many hours later". If it isn't, it indeed qualifies as a bug.

The eclass test for exactly the same condition in mount-boot_pkg_pretend() and mount-boot_pkg_preinst(), so this could only happen if an ebuild would call the latter but not the former. With what package do you see the problem?