You are not logged in.
Hi.
I installed intel-ucode.img and have a that line in mkinitcpio.conf:
HOOKS=(base keyboard keymap autodetect microcode modconf block udev filesystems fsck encrypt lvm2 kms resume)
When I checked if it is working, I got following output:
[root@k25 ~]# lsinitcpio --early /boot/initramfs-linux.img | grep microcode
(no output)
[root@k25 ~]# lsinitcpio --early /boot/initramfs-linux-fallback.img | grep microcode
kernel/x86/microcode/
kernel/x86/microcode/GenuineIntel.bin
Why is confirmation only showing up for fallback.img?
Last edited by arch_fuz (2025-04-24 13:46:57)
Offline
Hi.
I installed intel-ucode.img and have a that line in mkinitcpio.conf:HOOKS=(base keyboard keymap autodetect microcode modconf block udev filesystems fsck encrypt lvm2 kms resume)
When I checked if it is working, I got following output:
[root@k25 ~]# lsinitcpio --early /boot/initramfs-linux.img | grep microcode (no output) [root@k25 ~]# lsinitcpio --early /boot/initramfs-linux-fallback.img | grep microcode kernel/x86/microcode/ kernel/x86/microcode/GenuineIntel.bin
Why is confirmation only showing up for fallback.img?
Hi.
You are using autodetect before your microcode-hook, it probably detected that there is no microcode for your CPU available and therefore dropped it from the final image. Any difference to fallback.img is very likely due to autodetect.
Edit: you can compare
dmesg | grep microcode
from fallback and autodetect to make sure that the output is the same (or empty) on both initrams.
Last edited by stfischr (2025-04-24 12:39:10)
Offline
Thanks, changing the hooks order in mkinitcpio.conf solved it.
For me, autodetect behavior is a bug. What do you think?
Offline
For me, autodetect behavior is a bug. What do you think?
Well I'm not so sure, I had my share of problems with weird autodetect behavior and had to cry for help in the forums. If I wanted to add workarounds to the wiki I got told that my problems are not autodetect's responsibility. But maybe a bug report won't harm, better save than sorry.
Offline
It's not a bug, hook order has always mattered and the special relation between autodetect and the microcode hook is relevantly documented: https://wiki.archlinux.org/title/Mkinit … mmon_hooks
Last edited by V1del (2025-04-24 15:33:51)
Offline
Thanks, changing the hooks order in mkinitcpio.conf solved it.
For me, autodetect behavior is a bug. What do you think?
What, exactly, do you think is a bug? I'm only seeing sane, desirable behavior, is there something you haven't mentioned?
Why did you change the hook order? For some reason, you insist on having microcode for hardware you don't have?
Offline
What, exactly, do you think is a bug?
When I define to load microcode I would guess the system would do what it was told too and not to ignore my definition.
For some reason, you insist on having microcode for hardware you don't have?
Sorry, I do not understand what you are talking about.
is there something you haven't mentioned?
No.
Why did you change the hook order?
Because of the answer stfischr gave:
You are using autodetect before your microcode-hook
Anyway, I won't file a bug.
Thanks for your help.
Last edited by arch_fuz (2025-04-24 17:45:40)
Offline
For some reason, you insist on having microcode for hardware you don't have?
Sorry, I do not understand what you are talking about.
I think this shows where this whole question comes from. You seem to be under the impression that 'intel-ucode' is one thing? It's not, it's a large collection of microcode files that's different for each processor.
Offline
OK, got it.
Still it makes me wonder why it is ignoring what it was told to do.
Anyway I am fine with it now. It works and the fact that the order matters has made it in my knowledge base.
Offline
OK, got it.
Still it makes me wonder why it is ignoring what it was told to do.
It's not. With the autodetect hook, you told it to create an initramfs for *this machine*. It determined there were no microcode updates for this machine, so there's nothing to include.
Offline
Thanks scimmia for your time and sharing your knowledge by working this out.
It determined there were no microcode updates for this machine, so there's nothing to include.
It should be mentioned that the machine was set up from scratch, this was a fresh install, no update.
[root@k25 ~]# lsinitcpio --early /boot/initramfs-linux.img | grep microcode
kernel/x86/microcode/
kernel/x86/microcode/GenuineIntel.bin
After changing the hooks order I got this output instead of an empty line I got before. How to explain this?
Offline
[root@k25 ~]# lsinitcpio --early /boot/initramfs-linux.img | grep microcode kernel/x86/microcode/ kernel/x86/microcode/GenuineIntel.bin
After changing the hooks order I got this output instead of an empty line I got before. How to explain this?
Well it tells you, that the microcode is in the initramfs. But it doesn't tell you if it actually is used on boot, I posted the dmesg command you can try with and without the autodetect to see if there is a difference or if there is just no microcode for your CPU to apply.
I read somewhere that the microcodes are mainly for server CPUs and on desktop you have to hope for a BIOS update.
Offline
I used dmesg like you told me with this Hooks order (untouched, current):
HOOKS=(base udev microcode autodetect modconf kms keyboard keymap consolefont block lvm2 filesystems fsck)
[root@kvm25 ~]# dmesg | grep microcode
[ 1.572940] microcode: Current revision: 0x0b000040
[ 1.572943] microcode: Updated early from: 0x0b00002e
After that I modified hooks order again, built the image and restarted:
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block lvm2 filesystems fsck)
Starting build: '6.14.3-arch1-1'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [microcode]
-> Running build hook: [modconf]
-> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
-> Running build hook: [block]
-> Running build hook: [lvm2]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
After Reboot:
[root@k25 ~]# dmesg | grep microcode
[ 1.564556] microcode: Current revision: 0x0b000040
[ 1.564561] microcode: Updated early from: 0x0b00002e
[root@k25 ~]# lsinitcpio --early /boot/initramfs-linux.img | grep microcode
[root@k25 ~]# (empty line)
My information to confirm proper install of microcode was based on this article:
https://wiki.archlinux.org/title/Microcode - Section 2.1.2.1 mkinitcpio:
You can verify the initramfs includes the microcode update files with lsinitcpio(1). E.g.: ...
Could it be that the recommended verification is wrong? Or am I just to dumb to understand
Offline
Well I'm quiet puzzled myself. In both cases it says "microcode: Updated early" but in one case it doesn't seem to exist in the initramfs. Were did it get the files from, maybe something has changed without the wiki being updated?
On my current system here the CPU is too old, so there is no microcode to load for it. But even then if I include it in the hooks after autoremove, lsinitcpio shows that it's there.
Edit, what tells you
mkinitcpio -Pv
with the 2 variations of autoremove?
Last edited by stfischr (2025-04-25 14:02:30)
Offline
Next to including microcode into initramfs, the "old" way was to load it via boot-loader, grub or systemd-boot...
Both ways are also described in your posted wiki link.
Which boot-loader are you using, and does it contains also the directive to load microcode ?
Offline
I am using GRUB.
Offline
Can you post your /etc/default/grub ?
Interesting would be your config regarding
GRUB_EARLY_INITRD_LINUX_STOCK
Offline
# GRUB boot loader configuration
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet ipv6.disable=1 mitigations=auto,nosmt"
# GRUB_CMDLINE_LINUX="root=/dev/mapper/vg0-root"
GRUB_CMDLINE_LINUX="root=/dev/disk/by-uuid/40b05d6f-94f4-472a-b84e-6c9be730cfa7"
# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"
# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y
# Set to 'countdown' or 'hidden' to change timeout behavior,
# press ESC key to display menu.
GRUB_TIMEOUT_STYLE=menu
# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console
# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `videoinfo'
GRUB_GFXMODE=auto
# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep
# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true
# Uncomment and set to the desired menu colors. Used by normal and wallpaper
# modes only. Entries specified as foreground/background.
#GRUB_COLOR_NORMAL="light-blue/black"
#GRUB_COLOR_HIGHLIGHT="light-cyan/blue"
# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/path/to/wallpaper"
#GRUB_THEME="/path/to/gfxtheme"
# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"
# Uncomment to make GRUB remember the last selection. This requires
# setting 'GRUB_DEFAULT=saved' above.
#GRUB_SAVEDEFAULT=true
# Uncomment to disable submenus in boot menu
#GRUB_DISABLE_SUBMENU=y
# Probing for other operating systems is disabled for security reasons. Read
# documentation on GRUB_DISABLE_OS_PROBER, if still want to enable this
# functionality install os-prober and uncomment to detect and include other
# operating systems.
#GRUB_DISABLE_OS_PROBER=false
Offline
so you did not set/change GRUB_EARLY_INITRD_LINUX_STOCK, so GRUB uses the defaults and loads the microcode as well:
The default stock images are as follows, though they may be overridden by your distribution:
intel-uc.img intel-ucode.img amd-uc.img amd-ucode.img early_ucode.cpio microcode.cpio
https://www.gnu.org/software/grub/manua … ation.html
To use microcode either patch the autodetect hook as you did, or let grub do it (too).
The result can be checked with "dmesg | grep microcode" as you did.
Offline