80
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 04 Mar 2024
80 points (98.8% liked)
Arch Linux
7173 readers
2 users here now
The beloved lightweight distro
founded 4 years ago
MODERATORS
So basically:
mkinitcpio.conf
--> make sure you havemicrocode
after theautodetect
in theHOOKS
line/etc/mkinitcpio.d/<kernel>.preset
--> remove the lineALL_microcode=(/boot/*-ucode.img)
arch.conf
--> remove or comment out theinitrd /amd-ucode.img (or intel-ucode.img)
linesudo mkinitcpio -p <kernel>
to generate your new initrd, and then rebootOptional: run
grep microcode /proc/cpuinfo
before and after the reboot to verify that your microcode version hasn't changed after the reboot - which means that the new microcode loading method is working correctly.On a tangential note, the above is a perfect example of why I don't recommend Arch (and so-called "easy" derivatives like EndeavourOS) for newbies (ie people who don't RTFM / keep up with Arch news / inspect their .pacnew files etc). Feel free to link this post in your future internet arguments. :)
😡
Oh, right. Carry on.
Other reason is that a newbie (or even advanced user, but someone digging in more) won't even benefit from Arch.
I personally cannot imagine using anything other than Arch, but no way I am going to recommend it for someone who don't know what a bootloader is. But recommending to install it in VM is good tho, teaches a lot.
I might have missed something VERY obvious - I did ~~skim through~~ check the mkinitcpio, grub and microcode wikipages - but just merging .pacnew to current config (mkinitcpio, grub defaults),
mkinitcpio -p linux
andgrub-mkconfig -o /boot/grub/grub.cfg
, newly created grub.conf still had intel-ucode on the initrd -line. This happened on both machines I have atm.Arch forums had the magic words here: https://bbs.archlinux.org/viewtopic.php?pid=2154769#p2154769
and then my grub.cfg generated fine without the intel-ucode, and after rebooting dmesg seems to indicate the new method works fine
Always something :P
As I read the announcement it sounds like you only need to do changes if you setup early-microcode stuff. So if you have a completely standard install, no changes would be needed other than updating packages.
Am I wrong in this?
It's the other way round. Early-loading is the default and in fact late-loading doesn't even work on stock Arch kernels, because it requires the kernel to be built with that config option enabled. So any "standard" install would be taking about early-loading microcode, so this should be applicable to you as well.
Okay. But they do state in the announcement, that to ensure that no breaking occurs, they introduced some conflicts. So even if I just update packages, I should get my system up and running and be able to make any changes when they are required?
They don't mention anywhere that manual intervention is required for this update.
So there's two parts to this announcement. The first one deals with the upstreaming of modules and the resultant conflicts with the Arch packaged versions - this was solved by Arch upstream by introducing conflicts. In this case, you don't need to do anything.
The second part is about the microcode loading, where the old method of loading the microcode is deprecated, in favor of the new method (ie making it part of your main initrd). Now it's just deprecated, so you don't have to take any action either, but if you don't, you'll see annoying warning messages from mkinitcpio, whenever your kernel/initrd gets updated. But eventually, the legacy option will go away, and you'll be forced to take action. So might as well do it now, because Arch ain't going to do it for you in the future.
Ah, that's good to hear. So my system will come back up, it will just complain until I do these microcode changes.
So your post/comment was just being preemptive of future changes. :)
In addition to what @Malix@sopuli.xyz said about grub, I didn't need to edit kernel.preset files, but I did need to have the
encrypt
hook, and/crypto_keyfile.bin
, in files, andcrc32c-intel
(only on my intel machine, justcrc32c
on my amd machine) in modules.https://wiki.archlinux.org/title/Mkinitcpio#HOOKS
I was trying to do this, didn't find the directory, figured out that mkinitcpio wasn't installed. Turns out EndeavourOS set up dracut which means I don't even have to do this. (Hides behind purple SDDM theme)
Step 3 is optional. mkinitcpio will just issue a warning, and any kernel packages you have installed should eventually update their presets.
Could you please elaborate on the full path for the arch.conf file? I looked at
/usr/share/systemd/bootctl/arch.conf
and there was noinitrd /amd-ucode.img (or intel-ucode.img)
line, instead all I had wasinitrd /initramfs-linux.img
Furthermore, for step 3 I didnt have any entry starting with
ALL_microcode=
I have yet to do step 5 fyi. Thank you
Could be called something else, but it should be in
/boot/loader/entries/
. But if you don't have theinitrd /amd-ucode.img
line then that's fine, you don't need to do anything. Same with step 3, if you don't have theALL_microcode line
you can ignore that step.Thanks, ill look in there, and ignore that step if it doesn't exist, then do step 5. :)