Bug 935288 – sys-kernel/linux-firmware-99999999 fails to install with USE=initramfs

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Jorge López 2024-07-01 16:22:14 UTC]

I'm getting this error in the build log:

git checkout --quiet refs/git-r3/HEAD
GIT update -->
   repository:               https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
   at the commit:            d4fee3a21b1daba9ea99f2c341ab8f7386503e5b
>>> Source unpacked in /var/tmp/portage/sys-kernel/linux-firmware-99999999/work
>>> Preparing source in /var/tmp/portage/sys-kernel/linux-firmware-99999999/work/linux-firmware-99999999 ...
/var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/environment: line 2863: .//var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/make-amd-ucode-img: No such file or directory
 * ERROR: sys-kernel/linux-firmware-99999999::gentoo failed (prepare phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 136:  Called src_prepare
 *   environment, line 2863:  Called die
 * The specific snippet of code:
 *               ."/${T}/make-amd-ucode-img" "${S}/amd-ucode" "${S}/amd-ucode.img" || die;
 * 
 * If you need support, post the output of `emerge --info '=sys-kernel/linux-firmware-99999999::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-kernel/linux-firmware-99999999::gentoo'`.
sudo: The "no new privileges" flag is set, which prevents sudo from running as root.
sudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.
 * The complete build log is located at '/var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-kernel/linux-firmware-99999999/work/linux-firmware-99999999'
 * S: '/var/tmp/portage/sys-kernel/linux-firmware-99999999/work/linux-firmware-99999999'

>>> Failed to emerge sys-kernel/linux-firmware-99999999, Log file:

>>>  '/var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/build.log'

 * Messages for package sys-kernel/linux-firmware-99999999:

 * ERROR: sys-kernel/linux-firmware-99999999::gentoo failed (prepare phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 136:  Called src_prepare
 *   environment, line 2863:  Called die
 * The specific snippet of code:
 *               ."/${T}/make-amd-ucode-img" "${S}/amd-ucode" "${S}/amd-ucode.img" || die;
 * 
 * If you need support, post the output of `emerge --info '=sys-kernel/linux-firmware-99999999::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-kernel/linux-firmware-99999999::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-kernel/linux-firmware-99999999/work/linux-firmware-99999999'
 * S: '/var/tmp/portage/sys-kernel/linux-firmware-99999999/work/linux-firmware-99999999'

Reviewing the code in the ebuilds, make-amd-ucode-img and amd-ucode exist on my system's build dir. The only difference I see is that the -99999999 ebuild has this line:
- "/${T}/make-amd-ucode-img" "${S}/amd-ucode" "${S}/amd-ucode.img" || die;

While the linux-firmware-20240610-r2 ebuild has this:
- "${T}/make-amd-ucode-img" "${S}" "${S}/amd-ucode" || die

I'm not sure if the 99999999 ebuild is incorrect or not, seems like the "./" is not correct to me, as evidenced by the line:
- /var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/environment: line 2863: .//var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/make-amd-ucode-img: No such file or directory

I had just removed the initramfs USEflag from linux-firmware because of the news item about Dracut (I don't use Dracut) but after rebuilding linux-firmware, I noticed that there was no amd-ucode.img in /boot (my system is AMD). Is the code in the 99999999 ebuild needed due to the changes for Dracut?

Apart from that, it seems the argument ordering is wrong? Calling the script tells:
- Usage: /var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/make-amd-ucode-img <output image> <microcode directory>

But the ebuild is calling it as "/var/tmp/portage/sys-kernel/linux-firmware-99999999/temp/make-amd-ucode-img <microcode directory> <output image>"

[Comment 1 Larry the Git Cow 2024-07-01 17:56:57 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8d97ba8e872340f21b2739a25c6d397c396d57ae

commit 8d97ba8e872340f21b2739a25c6d397c396d57ae
Author:     Andrew Ammerlaan <[e-mail]>
AuthorDate: 2024-07-01 17:55:22 +0000
Commit:     Andrew Ammerlaan <[e-mail]>
CommitDate: 2024-07-01 17:55:22 +0000

    sys-kernel/linux-firmware: fix USE=initramfs in live, sync live
    
    Closes: https://bugs.gentoo.org/935288
    Signed-off-by: Andrew Ammerlaan <[e-mail]>

 .../linux-firmware/linux-firmware-99999999.ebuild  | 28 +++++++++++-----------
 1 file changed, 14 insertions(+), 14 deletions(-)

[Comment 2 Nowa Ammerlaan 2024-07-01 18:05:06 UTC]

> I'm not sure if the 99999999 ebuild is incorrect or not

It is, I made a stupid mistake here. I usually run diff on the individual ebuilds to verify that I have applied fixes I made while debugging to all ebuilds, but I clearly neglected to do so here. Sorry.

>  I noticed that there was no amd-ucode.img in /boot (my system is AMD). Is the code in the 99999999 ebuild needed due to the changes for Dracut?

USE=initramfs is responsible for making the early microcode initramfs image (/boot/amd-ucode.img). It either does so by simply making and installing that image itself (USE=-dist-kernel), or by delegating that task to /sbin/installkernel (USE=+dist-kernel).

What's new is that there is now a little helper script (make-amd-ucode-img) to generate the microcode image to avoid code duplication in the ebuild and the installkernel hooks. Functionally it behaves the same.

[Comment 3 Jorge López 2024-07-01 19:43:27 UTC]

Thanks Andrew, confirmed fixed!

Btw, while writing the report I just discovered I've been hardcoding the firmware in the kernel config all along, but I forgot. Back to removing USE=initramfs again, lol.