sys-firmware/intel-microcode recently started failing to install because /boot/efi/ is mounted read-only, even when /boot/ is read-write. It used to succeed in that condition, as it should since it only writes /boot/intel-uc.img and doesn't touch /boot/efi/. > # ls -lad /boot /boot/efi /boot/intel-uc.img > drwxr-xr-x 1 root root 234 Aug 22 00:43 /boot > drwxr-xr-x 3 root root 512 Dec 31 1969 /boot/efi > -rw-r--r-- 1 root root 63488 Sep 12 09:57 /boot/intel-uc.img > # > # mount|grep boot > /dev/sda1 on /boot/efi type vfat (ro,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) > # > # equery u intel-microcode > [ Legend : U - final flag setting for installation] > [ : I - package is installed with flag ] > [ Colors : set, unset ] > * Found these USE flags for sys-firmware/intel-microcode-20240813_p20240815: > U I > - - dist-kernel : Enable subslot rebuilds on Distribution Kernel upgrades > - - hostonly : Only install ucode(s) supported by currently available (=online) processor(s) > + + initramfs : Install a small initramfs for use with CONFIG_MICROCODE_EARLY > + + split-ucode : Install the split binary ucode files (used by the kernel directly) > - - vanilla : Only install microcode updates from Intel's official microcode tarball > # > # emerge -1 sys-firmware/intel-microcode > Calculating dependencies... done! > Dependency resolution took 1.67 s (backtrack: 0/20). > > >>> Verifying ebuild manifests > >>> Running pre-merge checks for sys-firmware/intel-microcode-20240813_p20240815 > * Assuming you do not have a separate /boot partition. > * Assuming you do not have a separate /efi partition. > * Your /boot/efi partition, was detected as being mounted, but is mounted read-only. > * Please remount it as read-write and retry. > * ERROR: sys-firmware/intel-microcode-20240813_p20240815::gentoo failed (pretend phase): > * /boot/efi mounted read-only > ... This might be due to a recent change to mount-boot.eclass: https://github.com/gentoo/gentoo/commit/e598ba3fe1f5b51c0f0e64cacd950d600b289852 "mount-boot.eclass: check for ESP as well as /boot, split eclass" The install should not require the efi directory to be accessible.
*** This bug has been marked as a duplicate of bug 937785 ***
> and doesn't touch /boot/efi/. Not true if you use e.g. systemd-boot and use an initramfs generator that does not bundle the microcode. I've already explained this at length in the duplicate bug report and on the forums. Tldr is that portage cannot know beforehand what Installkernel is going to do.
This is not a duplicate. sys-firmware/intel-microcode != sys-kernel/linux-firmware. In this case portage does know where the early fw initramfs is going to go because the intel-microcode ebuild passes the file name to iucode_tool. intel-microcode-20240910_p20240915.ebuild: >src_install() { >... > # The earlyfw cpio needs to be in /boot because it must be loaded before > # rootfs is mounted. > if ! use dist-kernel && use initramfs; then > dodir /boot && opts+=( --write-earlyfw="${ED}/boot/intel-uc.img" ) > fi > > keepdir /lib/firmware/intel-ucode > opts+=( --write-firmware="${ED}/lib/firmware/intel-ucode" ) > > iucode_tool \ > "${opts[@]}" \ > "${MICROCODE_SRC[@]}" \ > || die "iucode_tool ${opts[@]} ${MICROCODE_SRC[@]}" If mount-boot.eclass needs to stay as-is for other packages then maybe the intel-microcode ebuild should stop using it and verify that /boot/ is writable by other means. Please re-open and reassign as appropriate to get the ebuild fixed. Thanks.
(In reply to gen2dev from comment #3) > In this case portage does know where the early fw initramfs is going to go > because the intel-microcode ebuild passes the file name to iucode_tool. Elsewhere in the ebuild (pkg_postinst), other paths are written by installkernel. The logic could probably be adjusted to account for this and ignore /boot/efi under specific conditions, but I doubt it is a top priority. I would suggest mounting /boot/efi read/write, or setting DONT_MOUNT_BOOT to avoid the checks.
(In reply to gen2dev from comment #3) > This is not a duplicate. sys-firmware/intel-microcode != > sys-kernel/linux-firmware. > > In this case portage does know where the early fw initramfs is going to go > because the intel-microcode ebuild passes the file name to iucode_tool. > It is exactly the same, linux-firmware installs /boot/and-uc.img if USE=initramfs,-dist-kernel just as intel-microcode installs /boot/intel-uc.ing. There is intentionally a lot of symmetry between both packages. It also installs hooks for installkernel that may install the microcode to the EFI System Partition because the files in /boot are only usefull for grub and we support many other methods of booting. Please just read the thread on the forums about this topic. I don't want to repeat myself again, your system might not need the microcode on the ESP, many other systems do and we need to support those users as well. Yes we could refine the eclass so the ebuilds can specify exactly what to check, this would make it possible to check only for /boot for the case USE=initramfs,-dist-kernel, while checking for both /boot and the ESP if USE=initramfs,dist-kernel. That is however not something I am going to work on since I consider this completely unimportant, there is no reason to not simply mount your EFI System Partition.
Understood. Since no fix is likely I'll set DONT_MOUNT_BOOT=1 in package.env to hide the regression on my systems. Thanks for your help. *** This bug has been marked as a duplicate of bug 937785 ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a9b25945f57ea44213913ed4796582435d011b1a commit a9b25945f57ea44213913ed4796582435d011b1a Author: Nowa Ammerlaan <nowa@gentoo.org> AuthorDate: 2024-12-29 19:13:36 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2025-01-02 17:08:29 +0000 mount-boot-utils.eclass: document user variables for skipping mount check And introduce a new variable DONT_MOUNT_ESP to disable only the mount checking of the EFI System Partition. Useful for ebuilds where we know that only /boot is touched and not /efi. Or for users that know their kernel installation layout does not require mounting the ESP. Bug: https://bugs.gentoo.org/937785 Bug: https://bugs.gentoo.org/939760 Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org> Signed-off-by: Michał Górny <mgorny@gentoo.org> eclass/mount-boot-utils.eclass | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
