WTF moment with linux-firmware

[miket]

While getting set up for building a kernel, I noticed a Strange Thing. I suppose that some people in this section of the forums might have a use for it, but it sure has me scratching my head.

I did a quick ls of my /boot directory to see if I had the boot partition mounted and was surprised by what I found: amd-uc.img. Not having a clue about what it was or how it got there, file told me that it is a cpio archive and equery told me it was installed by sys-kernel/linux-firmware. Installed into /boot?!? WTF! Next I saw that the IUSE for the package now turns on the initramfs USE flag by default.

This is crazy on several levels. 1. I've got an Intel CPU with Intel video, so I don't need AMD microcode; 2. most of the time, even during emerges, I don't have anything mounted on /boot--so when something is mounted there, the amd-uc.img file would no longer be visible; 2a. a subsequent emerge of linux-firmware would want to remove or replace that file, so if /boot were mounted at that time, emerge would not be able to find it; 3. I do use an initramfs, but it is hand-rolled and used with my extlinux boot loader; and 4. would you not want to build the kernel with that microcode built in? The wiki page for linux-firmware has nothing to say about how to use this cpio image.

Maybe it takes advantage of some magic in genkernel or grub, but at this point, I don't see how it would work. All in all, though, I think the file would better be installed somewhere else like /usr/share/linux-firmware-[ver]

[pjp]

There's already a topic about your exact scenario and an Intel CPU. There are other threads in general about the changes to installkernel.

Oh, and at least 1 news item if not 2 related to the changes.

[miket]

There's already a topic about your exact scenario and an Intel CPU. There are other threads in general about the changes to installkernel.

I saw a news item about installkernel. I hadn't been aware of it and since I never run make install for the kernel, I've never used installkernel unknowingly. I always hand-copy kernel images and configurations to their respective directories on the /boot partition and edit extlinux.conf by hand. The only thing I got from the news item was that--hooray--a bit of software I never use would no longer be installed.

Not only that, the news item for installkernel makes no mention of firmware, let alone linux-firmware. I've found that one of the installkernel threads does discuss linux-firmware and AMD microcode, but does not make a convincing case for me that installing a blob directly into /boot is the right solution. The big fly in the ointment is the contents of the /boot directory are ephemeral. Many of us mount it only to update the boot configuration after building a kernel. When I do a world update it is seldom mounted.

For me, the greatest question is why the recent ebuild for linux-firmware switched to enabling the initramfs USE flag by default.

Oh, and at least 1 news item if not 2 related to the changes.

Edit: <strikethru>I saw only one.</strikethru> Sorry--I did see a second news item--still no mention of linux-firmware.

[pjp]

My mistake, you're correct. I conflated the changes with installkernel more directly with another news item...

https://www.gentoo.org/support/news-ite ... kmods.html

I agree that it isn't an easy item to discover via the news item. Nevertheless, search terms: "linux-firmware amd intel" bring up this topic:

Why does installkernel assume I have an AMD machine?

It all seems related, but I honestly can't remember why. I don't use either installkernel or dracut.

[logrusx]

I think it's this:

Code: Select all

# equery uses linux-firmware
...
 - - initramfs       : Create and install initramfs for early microcode loading in /boot (only AMD for now)

Best Regards,
Georgi

[miket]

I took a look at various packages that are adjacent to automagic boot setup: grub, genkernel, dracut, and plymouth (I had never emerged any of the last three of these). Guess what? None of these install anything into /boot!

One attribute of the boot directory/partition is the wide diversity of layouts it may have. There is no one-size-fits-all solution. I argue that is is widely inappropriate for a package manager to install things there directly: leave the manipulation of the contents of the boot directory/partition to other tools or manual processes that are outside of the package manager.

I haven't found explicit documentation about what directories can be the explicit targets of package-installation operations, but documents such as https://devmanual.gentoo.org/general-co ... index.html and https://wiki.gentoo.org/wiki/Gentoo_spe ... irectories give strong hints.

It would seem that package installation should be limited to these directories:

• anywhere in /bin, /lib*, /opt, and /sbin
• anywhere in /usr except under /usr/local
• judiciously in /etc and /var

[pietinger]

I took a look at various packages that are adjacent to automagic boot setup: grub, genkernel, dracut, and plymouth (I had never emerged any of the last three of these). Guess what? None of these install anything into /boot!

One attribute of the boot directory/partition is the wide diversity of layouts it may have. There is no one-size-fits-all solution. I argue that is is widely inappropriate for a package manager to install things there directly: leave the manipulation of the contents of the boot directory/partition to other tools or manual processes that are outside of the package manager.

First of all: I'm not a fan of automagic things either ... but there are many users who don't want to/can't take care of the kernel configuration themselves. For these users you MUST offer automatic routines ... and they have to install something on the ESP and/or /boot:

If a booloader/bootmanager is to be used, at least something must be written to the ESP (mounted on /efi). The grub installs itself by default to /boot/grub ... and the kernel ... yes, the kernel always needs - if not configured itself - an EXTERNAL initramfs (if no UKI is built) ... and firmware files ...

If you are using a bootloader that looks for the kernel in /boot, I recommend simply copying it yourself instead of using "make install":
https://wiki.gentoo.org/wiki/User:Pieti ... eat_Sheets

But if you - like me - do everything yourself, you shouldn't have any problems switching all that off:

I have a self-configured, monolithic, signed Linux kernel (on the notebook even with an embedded initramfs) which I boot directly from UEFI via SecureBoot (all self-built *). No need to install the install-kernel package (certainly no "dracut"), because I don't do a "make install" at all; and for my firmware I only need USE="-initramfs ..." in the make.conf (because of linux-firmware) ... nothing else:

Code: Select all

# emerge -pvD gentoo-sources linux-firmware intel-microcode installkernel dracut
...
[ebuild   R    ] sys-kernel/linux-firmware-20240709-r1::gentoo  USE="redistributable -bindist -compress-xz -compress-zstd -deduplicate -dist-kernel -initramfs -savedconfig (-unknown-license)" 0 KiB
[ebuild  N     ] sys-kernel/installkernel-39-r2::gentoo  USE="-dracut (-efistub) -grub -refind -systemd -systemd-boot (-ugrd) -uki -ukify" 22 KiB
[ebuild   R   ~] sys-firmware/intel-microcode-20240531_p20240526-r2::gentoo  USE="split-ucode -dist-kernel -hostonly -initramfs -vanilla" 0 KiB
[ebuild  N     ] sys-kernel/dracut-060_pre20240104-r4::gentoo  USE="(-selinux) (-test)" 489 KiB
[ebuild   R   ~] sys-kernel/gentoo-sources-6.10.2:6.10.2::gentoo  USE="-build -experimental -symlink" 0 KiB

My /boot is completely empty ... and on my ESP I have only my (stub-)kernels.

*) https://wiki.gentoo.org/wiki/User:Pieti ... SecureBoot

[logrusx]

I took a look at various packages that are adjacent to automagic boot setup: grub, genkernel, dracut, and plymouth (I had never emerged any of the last three of these). Guess what? None of these install anything into /boot!

Didn't you see my replay?

I just tested it and:

Code: Select all

equery belongs /boot/amd-uc.img 
 * Searching for /boot/amd-uc.img ... 
sys-kernel/linux-firmware-20240709-r1 (/boot/amd-uc.img)

Disable initramfs on linux-firmware.

Best Regards,
Georgi

[Nowa]

This is crazy on several levels.

No it's not, and it would be nice if you'd look into something a bit more before declaring it crazy.

1. I've got an Intel CPU with Intel video, so I don't need AMD microcode;

And there are also situations where a disk must be able to boot on both systems with an AMD *and* an Intel CPU. Via USE=initramfs on linux-firmware and intel-microcode you get the choice of installing, neither, only Intel, only AMD, or both.

2. most of the time, even during emerges, I don't have anything mounted on /boot--so when something is mounted there, the amd-uc.img file would no longer be visible; 2a. a subsequent emerge of linux-firmware would want to remove or replace that file, so if /boot were mounted at that time, emerge would not be able to find it;

Which is why the ebuild enforces that /boot is mounted

3. I do use an initramfs, but it is hand-rolled and used with my extlinux boot loader;

The kernel supports loading multiple initramfs'. USE=initramfs on linux-firmware and intel-microcode is an essential feature for users that use initrd generators that do not bundle the microcode

4. would you not want to build the kernel with that microcode built in?

A good reason to prefer the initramfs approach over building the microcode into the kernel is that the initramfs gets updated directly when linux-firmware/intel-microcode updates. Whereas building it into the kernel requires rebuilding the whole kernel before microcode updates take effect. Besides there are many users that use the preconfigured distribution kernels.

The wiki page for linux-firmware has nothing to say about how to use this cpio image.

It's picked up automatically by grub-mkconfig at that location. And via sys-kernel/installkernel it is also possible to install/register it for other supported bootloaders.

For me, the greatest question is why the recent ebuild for linux-firmware switched to enabling the initramfs USE flag by default.

Because it makes sense for the most secure to be the default. You may have additional methods of updating the microcode (e.g. build it into the kernel), but applying the updates twice (built-in and via initramfs) is harmless, while applying them not at all is a security risk.

Advanced users may disable the flag because they build the microcode into the kernel. But for the not so advanced users, the default configuration ensures that their cpu microcode is up to date.

I haven't found explicit documentation about what directories can be the explicit targets of package-installation operations, but documents such as https://devmanual.gentoo.org/general-co ... index.html and https://wiki.gentoo.org/wiki/Gentoo_spe ... irectories give strong hints.

See https://devmanual.gentoo.org/eclass-ref ... index.html