Mkinitcpio hook and consequences

I post a separate topic because the update one is already humongous and full of kde stuff.
Besides Plasma, the most important change in stable on 13.05.24 was a pacnew, that probably was not even noticed by many. And it adds microcode to the initcpio hooks of initram.

My question is, what other changes are linked to it?
I added the hook. I checked the presets - there was nothing about microcode there (kernels 6.1 and 6.6).
Than as per the recommendations from the unstable topic and arch forum i also added

GRUB_EARLY_INITRD_LINUX_STOCK=""

to /etc/default/grub. I hope that was correct? The intel-ucode.img is not in the grub menu options anymore. If i check with sudo lsinitcpio --early /boot/initramfs-6.6-x86_64.img the microcode seems to be there

early_cpio
kernel/
kernel/x86/
kernel/x86/microcode/
kernel/x86/microcode/GenuineIntel.bin

Soooo, do i need the intel-ucode.img in the boot anymore at all, can it be removed? Respectively, do i still need intel-ucode package, or the source now comes in some other way, like with the kernel package?
I just cannot figure out what provides the microcode now? Or maybe the img is not used, but the rest of the files in that package are in the time of image generation?

2 Likes

The microcode is still provided by intel-ucode package.

1 Like

So i do not delete anything. And does the grub line matter at all?

This also allows you to drop the microcode initrd lines from your boot configuration as they are now packed together with the main initramfs image.

Yes?

Yea i saw it. I understand deprecated as “you have to remove it” (it was not there in my case), but i could not quite get “allows you to drop” - you may, or you may not…as you wish? (i dropped it, i wonder what happens if i have not)

Confuse me as well a bit. I don’t have set the boot option on my systems to preventing unexpected issues.

Yeah, not the clearest wording.

Apparently no-one thinks like that regarding xmodmap, it’s been deprecated for a long long time (~10yrs I think).

You have to keep in mind that Manjaro has the update-grub script, which runs after every update and recreates /boot/grub/grub.cfg. Arch users don’t have that script — it’s specific to Manjaro — and so they may wish to edit /boot/grub/grub.cfg directly.

I did not edit the grub.cfg directly, i added the above parameter in the /etc/default/grub, so it will persist on updates (and it does, there is no more intel-ucode.img in the booting lines).
The above line GRUB_EARLY_INITRD_LINUX_STOCK="" is actually removing the microcode, because the value for “” is actually “n”. “y” will be the default like not having this line at all. As it was prior to that hook.
I have the suspicion right now it does not matter (still), because not everybody has managed the pacnew and added the hook, so it has to work both ways…and without that grub parameter it will generate microcode.img, but if i have the hook it will just not use it because it will already be loaded once from the other init image.

But someone more competent in this matter has to confirm my suspicions.

1 Like

I dont get the issue.

You still want/need the microcode and the package that provides it.
There is nothing suggesting otherwise.

yes.

no.

The same package.

…no?


Look, the only thing that changed is you can place microcode in mkinitcpio.conf.

That is not what the word means.
Though in the context of maintaining a system, or specifically when it comes to packages on a rolling release, it very most often means it should be removed.
In the simplest of terms it means you should, at some point soon, stop using that option.

Its exactly as stated. Allows. You can. But you dont have to (yet).
If left there it would be redundant for as long as both methods are functional.
It would stop being redundant when that old method stopped working.

Not all versions any more.
And that script provides absolutely nothing aside from the virtual alias of update-grub.

Arch still has the equivalent grub-mkconfig -o /boot/grub/grub.cfg, and would use it in the same circumstances.

Ah, ‘wish’, yes and they can. When it comes to just editing options.

3 Likes

You are correct. I was also a bit confused so spent some time looking into it. This is with respect to amd-ucode but I guess intel-ucode is the same.

Right now any of the following works;

  1. Do nothing

  2. Add microcode hook to /etc/mkinitcpio.conf and do nothing else

  3. Add microcode hook to /etc/mkinitcpio.conf and GRUB_EARLY_INITRD_LINUX_STOCK="" to the end of /etc/default/grub

If you do option 3 then /boot/amd-ucode.img does indeed get removed from initrd;

$ diff /boot/grub/grub.cfg grub.cfg.bak
124c124
<       initrd  /boot/initramfs-6.8-x86_64.img
---
>       initrd  /boot/amd-ucode.img /boot/initramfs-6.8-x86_64.img
136c136
<               initrd  /boot/initramfs-6.8-x86_64.img
---
>               initrd  /boot/amd-ucode.img /boot/initramfs-6.8-x86_64.img
157c157
<               initrd  /boot/initramfs-6.6-x86_64.img
---
>               initrd  /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img

And now the /boot/amd-ucode.img file is no longer required and could be removed.

BUT. The amd-ucode package contains both /boot/amd-ucode.img and the /usr/lib/firmware/amd-ucode/ files which are still required. So if you remove /boot/amd-ucode.img it’ll just get put back the next time that package is updated. I guess this will get sorted out at some point…

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.