Der microcode wurde in den mkinitcpio-hook integriert, darum muss der microcode nicht mehr über eine initrd Zeile des grub geladen werden.

  • segfault hat auf diesen Beitrag geantwortet.

    Richtig. Und dieser Hook funktioniert nur, wenn du das entsprechende Microcode Paket installiert hast und (diesen Hook konfiguriert hast oder autodetect verwendest).

    Josephus Miller

    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.

    a.albani

    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.

    • a.albani hat auf diesen Beitrag geantwortet.

      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.presetauskommentieren.

      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)

      • segfault hat auf diesen Beitrag geantwortet.

        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.

        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?

        • brikler hat auf diesen Beitrag geantwortet.

          T.M. 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

          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?

          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 linuxdurchgefü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.