Mkinitcpio update and changes may need some manual intervention

Important notifications
45

I’m confused,

isn’t it because

that we have to

…if so, I don’t see what from @pebcak post would need editing then? (or do you mean it was already implied and not needed to be pointed out (which would totally be needed in my case :sweat_smile:)?)

46

The preset files are generated by hooks.

You either should modify the file or delete them and let them be regenerated.

4 Likes
47

now it is clear… only 2 years not using mkinitcpio and i forget everything. :rofl:

3 Likes
48

Now I understand enough to to have the courage to make this update :sweat_smile:

1 Like
49

I’m just glad i don’t have to deal with it! :rofl:

2 Likes
50

But this is the case only when you reinstall your currently installed kernels not if you run
mkinitcpio -p/-P afterwards, because:


# rm /etc/mkinitcpio.d/*
# mkinitcpio -P 
==> ERROR: No presets found in /etc/mkinitcpio.d

Reinstalling the kernels does surely create those presets files:

 $ ls /etc/mkinitcpio.d/
linux-lts.preset  linux-zen.preset

So the whole thing can be summed up:

Either

edit the preset files, remove or comment out ALL_microcode=(/boot/*-ucode.img) and run sudo mkinitcpio -P afterwards

or

Delete the presets file and reinstall your kernels afterwards.

2 Likes
51

You can also just run the script manually to regen the preset files.

1 Like
52

And do the mkinicpio -P afterwards?

53

If you want to regenerate the initrams.

54

BTW, since the initrd line for microcode is superfluous with microcode now being built into the initramfs,
will there be any change to how kernel-install-mkinitcpio will create the systemd-boot loader entries?

55

The package itself doesn’t need any changes but, yes, the microcode will no longer be copied to /efi and the entries will only have a single initrd line.

It all “just works” due to the magic of kernel-install

1 Like
56

I guess grub-mkinitcpio users will “go on their business as usual”, with *-ucode.img under /boot and the
initrd line for microcode in grub.cfg?

57

I just went through this process with 2 (Arch) laptops and noticed something odd.
I checked mkinitcpio.conf on both machines before running paru to upgrade to the latest mkinicpio along with whatever else was due.

As expected the microcode option in hooks was missing in both files.
So after the update completed on machine1 I manually added the microcode option as described here, rebuild with sudo mkinitcpio -P, rebooted and all is good.

On machine2 however, I noticed that a hooks/microcode line showed up during the post paru upgrade kernel rebuild? And when I checked mkinitcpio.conf indeed, the microcode option got added?

Not a problem, rather the opposite, it was just strange to see that two machines which got updated within 5 minutes behaved differently.

Think I need to read up why Endevaour switched to Dracut next, whatever the reason was I might want that too? :grinning:

58

When a file is in the BACKUP array of a package, if it has been changed, a .pacnew file is created. If it has not been changed, it is directly updated.

Most likely, the file on one of your installs had changed and not on the other so that is why you saw the difference in behavior.

1 Like
59

Every day there is something new to be learned :grinning:
Thanks for clarifying @dalto

1 Like
60

I use mkinitcpio, and I use systemd-boot. I take the Arch announcement to mean that loading microcode with systemd boot entries is now superfluous. After going through the procedure below, this looks to actually be the case when I check.

I post the exact steps here, in case anyone else with mkinitcpio and systemd boot on an Arch install will need them.

Keep in mind that I have a couple extra custom systemd-boot entries, those can of course be skipped if you do not have them. And as always, if someone here with more Linux experience would find this to be a wrong procedure, listen to them.

  • open /etc/mkinitcpio.d/linux.preset

  • remove following line ALL_microcode=(/boot/*-ucode.img)

  • write out

  • open /etc/mkinitcpio.d/linux-lts.preset (if you have installed an LTS kernel)

  • remove the following line ALL_microcode=(/boot/*-ucode.img)

  • write out

  • open /etc/mkinitcpio.conf

  • search for the uncommented HOOKS=() line

  • confirm that microcode is within the parenthesis seperated by a space from the other hooks/entries

  • if microcode is not present in you uncommented hooks line, add it right after autodetect as examplified in the /etc/mkinitcpio.conf.pacnew file if you have one.

  • exit or write out as needed

  • run $ mkinitcpio the default is a dry run so it will not update your boot yet

  • check if it echoes -> Running build hook: [microcode]

  • if it does, you should be good. You have configured the microcode properly.

  • regenerate initramfs:

    sudo mkinitcpio -P

    • reboot

  • check if microcode has been loaded:
    sudo dmesg | grep -i micro

  • remove the mkinitcpio.conf.pacnew -file:
    sudo rm /etc/mkinitcpio.conf.pacnew

Remove microcode loading from systemd-boot entries:

sudo nano /boot/loader/entries/arch.conf
sudo nano /boot/loader/entries/arch-fallback.conf
sudo nano /boot/loader/entries/arch-terminal.conf
sudo nano /boot/loader/entries/arch-lts.conf

remove the line

initrd /intel-ucode.img (or amd-line if you have amd)

from each boot loader entries

  • check
    bootctl list
61

You don’t need to do this. You only need to run bootctl update when systemd updates and you should have a hook for that.

Just a quick point, anyone using kernel-install with systemd-boot can skip this section. With kernel-install, this will all happen for you automatically.

2 Likes
62

If they add the microcode hook they should set GRUB_EARLY_INITRD_LINUX_STOCK='' in /etc/default/grub

4 Likes
63

Great, thanks!

Yes, I have a hook. I’m a bit rusty, having just returned to this. I’ll edit out the bootctl update.

1 Like
64

Great info! As always.
Thanks!

2 Likes