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

Bug 939760

Summary: sys-firmware/intel-microcode-20240813_p20240815 installation fails when /boot/efi is mounted ro
Product: Gentoo Linux Reporter: gen2dev
Component: Current packagesAssignee: Gentoo's Team for Core System packages <base-system>
Status: RESOLVED DUPLICATE    
Severity: normal CC: gen2dev, nowa
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description gen2dev 2024-09-17 05:42:41 UTC
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.
Comment 1 Nowa Ammerlaan gentoo-dev 2024-09-17 18:57:14 UTC

*** This bug has been marked as a duplicate of bug 937785 ***
Comment 2 Nowa Ammerlaan gentoo-dev 2024-09-17 18:59:45 UTC
> 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.
Comment 3 gen2dev 2024-09-17 20:19:47 UTC
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.
Comment 4 Mike Gilbert gentoo-dev 2024-09-17 20:41:57 UTC
(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.
Comment 5 Nowa Ammerlaan gentoo-dev 2024-09-17 21:07:53 UTC
(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.
Comment 6 gen2dev 2024-09-17 21:33:46 UTC
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 ***
Comment 7 Larry the Git Cow gentoo-dev 2025-01-02 17:08:49 UTC
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(-)