Summary: | sys-firmware/intel-microcode-20240813_p20240815 installation fails when /boot/efi is mounted ro | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | gen2dev |
Component: | Current packages | Assignee: | 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
*** 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(-) |