Der microcode wurde in den mkinitcpio-hook integriert, darum muss der microcode nicht mehr über eine initrd Zeile des grub geladen werden.
Update mkinitcpio 38-3
- Bearbeitet
Richtig. Und dieser Hook funktioniert nur, wenn du das entsprechende Microcode Paket installiert hast und (diesen Hook konfiguriert hast oder autodetect verwendest).
Ich sollte mir wieder angewöhnen die News zu lesen.
Ja das ist installiert.
Ich war nur irritiert, weil das ja in /boot installiert ist und bei einem "update-grub" wieder in die "grub.cfg" geschrieben wird, was ja nicht mehr nötig ist.
Das ist mir schon klar. Nur wie bekomme ich das denn aus der grub.cfg raus? Die wird ja automatisch generiert:
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: amd-ucode.img initramfs-linux-fallback.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.
Adding boot menu entry for UEFI Firmware Settings ...
done
Ich habe ja gar keinen Einfluss darauf, ob der Microcode geladen wird oder nicht.
Es entsteht kein Schaden wenn das doppelt gemoppelt ist. Du kannst es also auch einfach so lassen.
grub-mkconfig verwendet hier die Variablen GRUB_EARLY_INITRD_LINUX_STOCK und GRUB_EARLY_INITRD_LINUX_CUSTOM. Eventuell kann man diese in /etc/default/grub überschreiben (leer lassen). Ich kanns leider gerade nicht ausprobieren... viel Glück.
frostschutz
Ja GRUB_EARLY_INITRD_LINUX_STOCK="" funktioniert.
Danke
- Bearbeitet
Und damit der folgende Warnhinweis nicht mehr beim mkinitcpio -p linux
auftaucht ...
==> WARNING: Deprecated option 'ALL_microcode' found. Update '/etc/mkinitcpio.d/linux.preset' to use the 'microcode' hook instead.
... könnte man noch die Zeile ALL_microcode=(/boot/*-ucode.img)
in der /etc/mkinitcpio.d/linux.preset
auskommentieren.
P.S:
In der /etc/mkinitcpio.conf Datei sollte dann in der HOOKS Zeile so etwas wie
HOOKS=(base udev microcode .......
oder
HOOKS=(base udev autodetect microcode .......
stehen.
(Verbessert s. u. bzw. siehe mkinitcpio -H microcode)
Update: autodetect
scheint entgegen meiner Annahme den Microcode nicht zu erkennen und einzubinden.
Man muss microcode
explizit angeben.
Habe von den mkinitcpio-devs wohl zu viel erwartet. :-D
tuxnix In der /etc/mkinitcpio.conf Datei sollte dann in der HOOKS Zeile so etwas wie
HOOKS=(base udev microcode .......
stehen.
Ich habe die microcode Hook hinter autodetect, da ja mkinitcpio -H microcode
sagt:
If the autodetect hook runs before this hook, it will only add early microcode
update files for the processor of the system the image is built on.
Und damit sollte ja der Status wir vor dem Upgrade sein.
- Bearbeitet
Ich frage mich ob es auch "späten Microcode" gibt. Braucht es den?
Autodetect würde den aussortieren.
autodetect reduziert die initramfs. "Any hooks placed before 'autodetect' will be installed in full. "
Auch ein HOOKS=(base udev microcode autodetect ...
wäre richtig.
mkinitcpio -H autodetect
This hook shrinks your initramfs to a smaller size by autodetecting the needed modules. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before 'autodetect' will be installed in full.
Hier fehlt mir Hintergrundswissen. Man könnte die verschiedenen Varianten der initramfs mal mit lsinitcpio /boot/initramfs-linux.img
analysieren und vergleichen.
P.S.: Vielleicht weiß ja @tpowa mehr darüber wie autodetect konkret arbeitet und was es bewirkt. (mkinitcpio wurde von phrakture und tpowa mit Hilfe aus der Community entwickelt. )
Der Begleittext für autodetect ist für mich vieldeutig.
Fragen:
Was wird detektiert ? Was wird ergänzt? Was wird vermindert? Und was bedeutet hier auto?
Wie wäre denn nachträglich, also im laufenden System, zu überprüfen, daß das Laden des jeweiligen Microcodes nun über mkinitcpio ordnungemäß konfiguriert ist?
journalctl -k --grep=microcode
Mär 06 17:47:35 I-NET kernel: SRBDS: Mitigation: Microcode
Mär 06 17:47:35 I-NET kernel: GDS: Vulnerable: No microcode
Mär 06 17:47:35 I-NET kernel: microcode: Current revision: 0x000000f0
Mär 06 17:47:35 I-NET kernel: microcode: Updated early from: 0x000000c2
Ist das jetzt gut oder schlecht?
- Bearbeitet
Ich habe ein wenig nachgeforscht was es mit dem Eintrag autodetect auf sich hat.
Hier das script von autodetect: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/master/install/autodetect
Wenn ich das richtig interpretiere dann wird mit modprobe -S "$KERNELVERSION" -qaR "${mods[@]}
geprüft welche Module geladen werden können und alles was nicht geladen werden kann, wird dann auch nicht in die initramfs-linux.img geschrieben. Auf diese Weise bleibt die initramfs möglichts klein.
autodetect wirkt sich nur auf die in der Liste folgenden (rechts stehenden) hooks aus, und dort auch nicht auf alle.
Ich habe das praktisch einmal durchprobiert und die Position von autodetect verschoben und danach jeweiles ein mkinitcpio -p linux
durchgeführt.
Position von autodetect in
HOOKS=(base udev microcode modconf kms keyboard keymap consolefont block resume filesystems fsck) und die Größe der resultierenden initramfs-linux.img in MiB.
autodetect jeweils vor dem hook :
- base 15,3 MiB
- udev 15,3 MiB
- microcode 15,3 MiB
- modconf 27,2 MiB
- kms 27,2 MiB
- keyboard 94,6 MiB
- keymap 96,0 MiB
- consolefont 96,0 MiB
- block 96,0 MiB
- resume 110,4 MiB
- filesystems 110,4 MiB
- fsck 123,5 MiB
Die Größe der initramfs-linux-fallback.img Datei bleibt dabei immer 123,5 MiB. autodetect wirkt sich auf sie nicht aus. Wenn man autodetect ganz weglässt hat die initramfs-linux.img Datei auch 123,5 MiB.
autodetect detektiert nichts und hat auch nichts damit zu tun welche hooks geladen werden.
Sie prüft lediglich welche Treiber relevant sind und hält die initramfs-linux.img Datei klein.
- Bearbeitet
Ich hab schon mit journalctl geschaut, aber meine Erkundung war eben nicht sehr optimistisch:
journalctl -k --grep=microcode
Mär 07 06:32:43 thot kernel: Speculative Return Stack Overflow: IBPB-extending microcode not applied!
Mär 07 06:32:43 thot kernel: Speculative Return Stack Overflow: Vulnerable: Safe RET, no microcode
Mär 07 06:32:43 thot kernel: microcode: Current revision: 0x0a704103
Es ist ein AMD Ryzen, soll also amd-ucode.img laden.
Update: Hier ...
https://forum.endeavouros.com/t/new-microcode-how-can-i-check-if-it-is-loaded/26086/7
... diskutieren sie darüber, dass Microcode wenn ich das richtig verstehe u.U. gar nicht geladen wird, nämlich wenn der Prozessor alle Erfordernisse bereits selbst mitbringt. Dem liegt die Überlegung zugrunde, dass Microcode vor allem Fehler früher Prozessorserien ausgleichen soll, bei späteren aber eben nicht muss.