Why does installkernel assume I have an AMD machine?

[davidbryant]

I'm running an openrc version of Gentoo on a Dell computer with an Intel processor. I have compiled all the necessary drivers into a monolithic kernel, so when I update the kernel, I do not even generate any modules. My grub.cfg does not invoke "initrd" -- it just boots the monolithic kernel.

Recently (starting with 6.6.37, on July 8 ) I see this message when I say "make install":

Code: Select all

Generating AMD CPU Microcode early initramfs image...

After installing a new kernel, I now also find that a small file (~100 kb) named "amd-uc.img" has been added to my /boot directory.

It appears to me that this extra overhead is totally useless. I don't have an AMD processor, and I don't even use an initramfs when I boot Gentoo.

I'm just curious why "installkernel" is so sloppy. I have fixed it myself, on my own machine. But I wonder if something should be done to improve "installkernel".

[eeckwrk99]

I'm running an openrc version of Gentoo on a Dell computer with an Intel processor. I have compiled all the necessary drivers into a monolithic kernel, so when I update the kernel, I do not even generate any modules. My grub.cfg does not invoke "initrd" -- it just boots the monolithic kernel.

Recently (starting with 6.6.37, on July 8 ) I see this message when I say "make install":

Code: Select all

Generating AMD CPU Microcode early initramfs image...

After installing a new kernel, I now also find that a small file (~100 kb) named "amd-uc.img" has been added to my /boot directory.

It appears to me that this extra overhead is totally useless. I don't have an AMD processor, and I don't even use an initramfs when I boot Gentoo.

I'm just curious why "installkernel" is so sloppy. I have fixed it myself, on my own machine. But I wonder if something should be done to improve "installkernel".

As far as I'm concerned, I'm using

Code: Select all

sys-kernel/linux-firmware -initramfs

in package.use to get rid of /boot/amd-ucode.img.

[pietinger]

I'm just curious why "installkernel" is so sloppy. I have fixed it myself, on my own machine. But I wonder if something should be done to improve "installkernel".

Do you have enabled the use-flag "dracut" for the package "installkernel" ?

AFAIK installkernel emerged without any of its used use-flag will behave like we expect a "make install" for a "naked" kernel (I mean without initramfs; and Intel microcode inside the kernel image)

[davidbryant]

Do you have enabled the use-flag "dracut" for the package "installkernel" ?

No. Here's some terminal output.

Code: Select all

localhost ~ # eix --installed-with-use dracut
No matches found

AFAIK installkernel emerged without any of its used use-flag will behave like we expect a "make install" for a "naked" kernel (I mean without initramfs; and Intel microcode inside the kernel image)

Here's some more terminal output.

Code: Select all

localhost ~ # emerge --ask --verbose installkernel

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 1.86 s (backtrack: 0/20).

[ebuild   R    ] sys-kernel/installkernel-39-r1::gentoo  USE="-dracut (-efistub) -grub -refind -systemd -systemd-boot -uki -ukify" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

So no, I haven't set any special use flags for installkernel. According to the package database, there are 8 flags available with installkernel, and my system has all of them turned off. I also notice that installkernel was updated on July 3, 2024. I think I'll try digging through the source code and see if I can figure it out.

[davidbryant]

As far as I'm concerned, I'm using

Code: Select all

sys-kernel/linux-firmware -initramfs

in package.use to get rid of /boot/amd-ucode.img.

Thanks for the hint. I was just using the default USE flags with linux-firmware. I'll try your suggestion and see if that fixes it.

[eschwartz]

linux-firmware when built with savedconfig and initramfs would also error out because /lib/firmware/amd-ucode didn't exist:

Code: Select all

 * Installing the kernel via installkernel ...
Reading /usr/lib/kernel/install.conf...
/usr/lib/kernel/install.conf configures layout=compat
/usr/lib/kernel/install.conf configures initrd_generator=none
/usr/lib/kernel/install.conf configures uki_generator=none

Running /usr/lib/kernel/preinst.d/35-amd-microcode.install 6.9.9-gentoo-dist /usr/src/linux-6.9.9-gentoo-dist/arch/x86/boot/bzImage...

 * Generating AMD CPU Microcode early initramfs image...
 * Usage: /usr/bin/make-amd-ucode-img <output image> <microcode directory>
 * AMD microcode directory does not exist: /lib/firmware/amd-ucode
 * make-amd-ucode-img failed
 * 
 * The kernel was not deployed successfully. Inspect the failure
 * in the logs above and once you resolve the problems please
 * run the equivalent of the following command to try again:
 * 
 *     emerge --config '=sys-kernel/gentoo-kernel-6.9.9:6.9.9'
 * ERROR: sys-kernel/gentoo-kernel-6.9.9::gentoo failed (postinst phase):
 *   Kernel install failed, please fix the problems and run emerge --config
 * 
 * Call stack:
 *     ebuild.sh, line  136:  Called pkg_postinst
 *   environment, line 2577:  Called kernel-build_pkg_postinst
 *   environment, line 1723:  Called kernel-install_pkg_postinst
 *   environment, line 2083:  Called kernel-install_install_all '6.9.9-gentoo-dist'
 *   environment, line 2069:  Called dist-kernel_install_kernel '6.9.9-gentoo-dist' '/usr/src/linux-6.9.9-gentoo-dist/arch/x86/boot/bzImage' '/usr/src/linux-6.9.9-gentoo-dist/System.map'
 *   environment, line 1005:  Called die
 * The specific snippet of code:
 *           die "Kernel install failed, please fix the problems and run emerge --config";
 * 
 * If you need support, post the output of `emerge --info '=sys-kernel/gentoo-kernel-6.9.9::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-kernel/gentoo-kernel-6.9.9::gentoo'`.
 * The complete build log is located at '/var/log/portage/build/sys-kernel/gentoo-kernel-6.9.9:20240715-171039.log'.
 * For convenience, a symlink to the build log is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-6.9.9/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-6.9.9/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-kernel/gentoo-kernel-6.9.9/empty'
 * S: '/var/tmp/portage/sys-kernel/gentoo-kernel-6.9.9/work/linux-6.9'
 * FAILED postinst: 1

I discussed this with Andrew Ammerlaan and now as of https://gitweb.gentoo.org/repo/gentoo.g ... 4910722eef it doesn't do this anymore.

I confess it still slightly confuses me that it even thinks to recreate a file that was installed via the package -- because my configuration does have /boot/amd-uc.img as a packaged file and my AMD laptop needs it. Still, using savedconfig and stripping the amd ucode files from /lib/firmware should now mean that this runs like:

Code: Select all

Running /usr/lib/kernel/preinst.d/35-amd-microcode.install 6.9.9-gentoo-dist /usr/src/linux-6.9.9-gentoo-dist/arch/x86/boot/bzImage...

 * No AMD CPU Microcode installed, nothing to do here.

Hook /usr/lib/kernel/preinst.d/35-amd-microcode.install finished successfully

[Nowa]

I confess it still slightly confuses me that it even thinks to recreate a file that was installed via the package -- because my configuration does have /boot/amd-uc.img as a packaged file and my AMD laptop needs it. Still, using savedconfig and stripping the amd ucode files from /lib/firmware should now mean that this runs like:

The point of the change is twofold:
- /boot/amd-ucode.img is only useful for GRUB. Users of systemd-boot or (UKI) efistub booting should also get microcode updates, we can only determine which booting method we are using in installkernel.
- Whether we want an amd-ucode.img depends on whether we are using an initrd_generator that bundles the microcode (dracut) or not (ugrd), we can only determine this via installkernel.

Note also that the ebuild will NOT install a microcode image if the dist-kernel flag is enabled, because users of dist-kernels are forced to use /sbin/installkernel while users of custom kernels may or may not choose to do so (so we keep the ebuild code as "backwards compatibility" for users that do not use installkernel).

Do you have enabled the use-flag "dracut" for the package "installkernel" ?

AFAIK installkernel emerged without any of its used use-flag will behave like we expect a "make install" for a "naked" kernel (I mean without initramfs; and Intel microcode inside the kernel image)

Not necessarily true, other packages can and do install hooks.

As far as I'm concerned, I'm using
Code:
sys-kernel/linux-firmware -initramfs
in package.use to get rid of /boot/amd-ucode.img.

Indeed, this is the correct solution. The initramfs flag controls whether a microcode initramfs is built (irrespective of if the ebuild is installing it or /sbin/installkernel)

I'm just curious why "installkernel" is so sloppy. I have fixed it myself, on my own machine. But I wonder if something should be done to improve "installkernel".

It's not sloppy, it is intentional. Users should be able to create a /boot partition, ESP or UKI that can boot on both Intel and AMD machines. Configuration is done via sys-kernel/linux-firmware[+/-initramfs] and sys-microcode/intel-microcode[+/-initramfs] the default is enabled since not having the microcode when you do need it is a security risk, while the other way around (having the microcode double, built-in, via /boot, or built into an UKI) is harmless. So we intentionally do not check the CPU vendor at runtime.

[eschwartz]

I confess it still slightly confuses me that it even thinks to recreate a file that was installed via the package -- because my configuration does have /boot/amd-uc.img as a packaged file and my AMD laptop needs it. Still, using savedconfig and stripping the amd ucode files from /lib/firmware should now mean that this runs like:

The point of the change is twofold:
- /boot/amd-ucode.img is only useful for GRUB. Users of systemd-boot or (UKI) efistub booting should also get microcode updates, we can only determine which booting method we are using in installkernel.
- Whether we want an amd-ucode.img depends on whether we are using an initrd_generator that bundles the microcode (dracut) or not (ugrd), we can only determine this via installkernel.

Note also that the ebuild will NOT install a microcode image if the dist-kernel flag is enabled, because users of dist-kernels are forced to use /sbin/installkernel while users of custom kernels may or may not choose to do so (so we keep the ebuild code as "backwards compatibility" for users that do not use installkernel).

Ah thanks, that makes sense. I rarely remember that UKI exists, truth be told.

[papu]

hi,

since yesterday that I was testing things with dracut/installkernel/linux-firmware, I never have used initrd but sometimes like to take a look and so

then today, I have decided to keep the same config I had been using(no initrd), but for some reason now when I compile a kernel installkernel generate an initrd every time!
because as of today it has decided yes ? I NOT want initrd

gentoo-sources user I am

Code: Select all

DEPMOD  /lib/modules/6.10.1-gentoo
  INSTALL /boot
Reading /usr/lib/kernel/install.conf...
/usr/lib/kernel/install.conf configures layout=grub
/usr/lib/kernel/install.conf configures initrd_generator=none
/usr/lib/kernel/install.conf configures uki_generator=none
Installing kernel image for 6.10.1-gentoo...
Installing initramfs image for 6.10.1-gentoo...
Installing System.map for 6.10.1-gentoo...
Installing config for 6.10.1-gentoo...

Running /usr/lib/kernel/postinst.d/91-grub-mkconfig.install 6.10.1-gentoo /boot/vmlinuz-6.10.1-gentoo...

 * Backing up existing grub config as /boot/grub/grub.cfg~...
'/boot/grub/grub.cfg' -> '/boot/grub/grub.cfg~'
 * Generating new GRUB config as /boot/grub/grub.cfg...
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.10.1-gentoo
Found initrd image: /boot/initramfs-6.10.1-gentoo.img
Found linux image: /boot/vmlinuz-6.10.1-gentoo.old
Found initrd image: /boot/initramfs-6.10.1-gentoo.img
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done

Hook /usr/lib/kernel/postinst.d/91-grub-mkconfig.install finished successfully


Running /etc/kernel/postinst.d/dkms 6.10.1-gentoo /boot/vmlinuz-6.10.1-gentoo...

dkms: running auto installation service for kernel 6.10.1-gentoo
dkms: autoinstall for kernel 6.10.1-gentoo Done. 

Hook /etc/kernel/postinst.d/dkms finished successfully

Code: Select all

# eix --installed-with-use dracut
No matches found


# emerge -p dracut
[ebuild  N     ] sys-kernel/dracut-103-r2::gentoo  USE="(-selinux) (-test)" 0 KiB
Total: 1 package (1 new), Size of downloads: 0 KiB

Code: Select all

[ebuild   R    ] sys-kernel/linux-firmware-20240709-r1::gentoo  USE="-bindist -compress-xz -compress-zstd -deduplicate -dist-kernel -initramfs redistributable -savedconfig (-unknown-license)" 0 KiB
[ebuild   R    ] sys-kernel/installkernel-40::gentoo  USE="-dracut -efistub grub -refind -systemd -systemd-boot -ugrd -uki -ukify" 0 KiB

Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB

[Nowa]

Your log shows that no initramfs is generated, but there is one being installed. Likely there is a left-over initrd file in your kernel source directory.

Please delete /usr/src/linux-6.10.1-gentoo/arch/x86/boot/initrd (or equivalent for your system architecture) and try again. (or upgrade the kernel, this ensures a clean start and will therefore also fix your problem)

This happens because installkernel[-systemd,dracut] puts initrd and uki images in the kernel source directory, where they will get picked up and installed. Disabling the "dracut" flag disables the generation of the initrd but cannot remove the initrd that was previously generated from the kernel source directory.

[papu]

Your log shows that no initramfs is generated, but there is one being installed. Likely there is a left-over initrd file in your kernel source directory.

Please delete /usr/src/linux-6.10.1-gentoo/arch/x86/boot/initrd (or equivalent for your system architecture) and try again. (or upgrade the kernel, this ensures a clean start and will therefore also fix your problem)

This happens because installkernel[-systemd,dracut] puts initrd and uki images in the kernel source directory, where they will get picked up and installed. Disabling the "dracut" flag disables the generation of the initrd but cannot remove the initrd that was previously generated from the kernel source directory.

mmm, what a weird thing it got me mad...

so, is something from either program or both fault?

https://i.imgur.com/NvXkBLn.jpg , in fact it's clear creation time of initrd match with the changes I did last night

thanks

[Nowa]

so, is something from either program or both fault?

Nothing is at fault really, it's an unfortunate design choice of the traditional installkernel (originating from before we forked it), that we are kinda stuck with (I did document this behaviour on the wiki). No such problem exists for systemd's kernel-install, it uses a staging area and thus does not touch the kernel source directory.