Arch Linux

Update von linux-firmware >= 20250613.12fe085f-5 erfordert manuellen Eingriff

Dirk

Mit der Version 20250613.12fe085f-5 von linux-firmware wurde das Paket auf herstellerspezifische Pakete aufgeteilt. linux-firmware ist nun ein leeres Paket, das das Standard-Set an Firmware-Paketen als Abhängigkeit hat.

Dies fällt zufälliger Weise mit der Neuorganisation des Symlink-Layouts der NVIDIA-Firmware zusammen, was zu einer Situation führt, mit der Pacman nicht umgehen kann.

Wenn man von Version 20250508.788aadc8-2 oder älter auf die aktuelle Version updaten will, erscheinen folgende Fehlermeldungen.

linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem

Um das Update durchführen zu können, muss zuerst das Paket linux-firmware entfernt und danach wieder installiert werden.

pacman -Rdd linux-firmware
pacman -Syu linux-firmware

Danach kann mittels pacman -Syu das System wie gewohnt aktualisiert werden.

Josephus Miller

Dirk wurde das Paket auf herstellerspezifische Pakete aufgeteilt.

Damit könnten doch die nicht benötigten Firmwarebestandteile gelöscht werden, oder habe ich da einen Denkfehler?

linux-firmware-amdgpu (für linux-firmware)                 -> 20250613.12fe085f-6
 linux-firmware-atheros (für linux-firmware)                -> 20250613.12fe085f-6
 linux-firmware-broadcom (für linux-firmware)               -> 20250613.12fe085f-6
 linux-firmware-intel (für linux-firmware)                  -> 20250613.12fe085f-6
 linux-firmware-mediatek (für linux-firmware)               -> 20250613.12fe085f-6
 linux-firmware-nvidia (für linux-firmware)                 -> 20250613.12fe085f-6
 linux-firmware-other (für linux-firmware)                  -> 20250613.12fe085f-6
 linux-firmware-radeon (für linux-firmware)                 -> 20250613.12fe085f-6
 linux-firmware-realtek (für linux-firmware)                -> 20250613.12fe085f-6

Davon brauche ich an sich nur "amdgpu" und zur Sicherheit "other", den Rest würde ich entfernen

moonwalker3

Dirk
Ich hatte die gleichen Probleme, mit AMD-Hardware. Mit deinen zwei Befehlen habe ich meine Probleme gelöst. Danke!

Dirk

Vermutlich ist das langfristig der Plan dahinter. Aktuell geht das ohne es zu erzwingen, oder linux-firmware selbst mit den gewünschten Abhängigkeiten zu paketieren nicht.

# pacman -Rns linux-firmware-mediatek
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing linux-firmware-mediatek breaks dependency 'linux-firmware-mediatek' required by linux-firmware

#

tuxnix

Dirk
Wie es aussieht ist linux-firmware jetzt ein reines meta Paket.
Sobald linux-firmware deinstalliert ist, müsste man doch die übrigen linux-firmware-'xyz' Pakete unabhängig von einander wählen können.

Dirk

tuxnix Wenn ich versuche, linux-firmware zu deinstallieren, will Pacman die ganzen individuellen Pakete direkt mit deinstallieren. Vermutlich würde es gehen, das zu machen, und dann die individuellen Pakete explizit zu installieren, aber ich lass das jetzt erst mal so, das sind keine 300 Megabyte insgesamt.

Aber wer mutig ist, kann ja mal berichten 🙂

tuxnix

Dirk
Ich war mal mutig, hier der Bericht:
Mit pacman -R linux-firmware wird lediglich das Meta Paket entfernt und damit gibt es auch die Abhängigkeit zu den anderen Paketen nicht mehr.
Danach konnte ich die überflüssigen firmeware Pakete entfernen.
Mein Laptop hat Intel Chipsatz. Nachdem ich die bei mir nicht benötigten firmeware Pakete entfernt habe, sieht es bei den installierten firmeware Paketen bei mir jetzt so aus:

pacman -Ss linux-firmware |grep Installiert
core/linux-firmware-intel 20250613.12fe085f-6 [Installiert]
core/linux-firmware-whence 20250613.12fe085f-6 [Installiert]

Und nach einem Neustart läuft auch noch alles wie gewohnt.

Josephus Miller

Danke fürs muitige Testen 😁 Dann werde ich mich die Tage auch mal daran wagen.

Dirk das sind keine 300 Megabyte insgesamt

Ist zwar relativ wenig, aber trotzdem unnötig. Funktiniert ja nun (bzw demnächst) wie bei den Grafiktreibern, da muss man ja auch nicht alle unbenötigten mit installieren.

Josephus Miller

tuxnix bei den installierten firmeware Paketen bei mir jetzt so aus:
pacman -Ss linux-firmware |grep Installiert
core/linux-firmware-intel 20250613.12fe085f-6 [Installiert]
core/linux-firmware-whence 20250613.12fe085f-6 [Installiert]

Ganz so minimalistisch siehts bei mir nun nicht aus:

core/linux-firmware-amdgpu 20250613.12fe085f-9 [Installiert]
core/linux-firmware-intel 20250613.12fe085f-9 [Installiert]
core/linux-firmware-other 20250613.12fe085f-9 [Installiert]
core/linux-firmware-radeon 20250613.12fe085f-9 [Installiert]
core/linux-firmware-realtek 20250613.12fe085f-9 [Installiert]
core/linux-firmware-whence 20250613.12fe085f-9 [Installiert]

Laut lspci werkelt bei mir nichts von Intel, aber nach dem Deinstallieren von linux-firmware-intel kam beim Erstellen des initramfs

 -> Running build hook: [encrypt]
==> WARNING: Possibly missing firmware for module: 'qat_420xx'
==> WARNING: Possibly missing firmware for module: 'qat_c62x'
==> WARNING: Possibly missing firmware for module: 'qat_c3xxx'
==> WARNING: Possibly missing firmware for module: 'qat_dh895xcc'
==> WARNING: Possibly missing firmware for module: 'qat_4xxx'

frostschutz

Musst dann nur schauen ob die bei dir jetzt in pacman -Qdt auftauchen (installierte aber nicht mehr benötigte Pakete). Bei Bedarf pacman -D --asexplicit hinterherschicken.

tuxnix

Edit:
Beim Erstellen der initramfs-linux-fallback.img gibt es dann noch ein paar zusätzliche Warnhinweise. z.B:

==> WARNING: Possibly missing firmware for module: 'amdgpu'
==> WARNING: Possibly missing firmware for module: 'nouveau'
==> WARNING: Possibly missing firmware for module: 'radeon'
==> WARNING: Possibly missing firmware for module: 'ast'

Das liegt daran, weil das fallback-image zur Sicherheit ohne Hardwareerkennung (autodetect) erstellt wird und deshalb routinemäßig warnt.

niemand

tuxnix
Kommen die Meldungen beim Bau des initramfs für den Fallback-Eintrag? Dann soll das so sein. Ich hatte das vorhin bei einem Notebook das den Eintrag nicht hat, auch gemacht, und da ist mir sowas nicht aufgefallen.

tuxnix

Ja, die Warnungen tauchen nur beim Erstellen des initramfs-linux-fallback.img auf.
Und ich entsinne mich jetzt auch. Das fallback image wird ohne autodetect der Hardware erstellt, und deshalb tauchen dann auch die "unnötigen" Warnmeldungen dabei auf.
Ich pass das oben mal an.

tuxnix

Josephus Miller

Bei mir kommt jetzt auch eine ganze Reihe solcher Meldungen von potenziell fehlenden Treiben beim Erstellen des fallback images.

Das normale image prüft mit autodetect und läd nur die module die auch benötigt werden.
Das fallback prüft nicht. Das "Possibly missing firmware" sagt lediglich aus, dass die firmware nicht da ist, aber nicht ob dein PC diese Treiber überhaupt gebrauchen kann.
Bei mir sieht das beim Erstellen des image dann so aus:

==> Starting build: '6.15.3-arch1-1'
  -> Running build hook: [autodetect]
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: '6.15.3-arch1-1'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'amdgpu'
==> WARNING: Possibly missing firmware for module: 'nouveau'
==> WARNING: Possibly missing firmware for module: 'radeon'
==> WARNING: Possibly missing firmware for module: 'ast'
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci_renesas'
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: 'advansys'
==> WARNING: Possibly missing firmware for module: 'qed'
==> WARNING: Possibly missing firmware for module: 'aic94xx'
==> WARNING: Possibly missing firmware for module: 'cxgb4'
==> WARNING: Possibly missing firmware for module: 'cxgb3'
==> WARNING: Possibly missing firmware for module: 'qla2xxx'
==> WARNING: Possibly missing firmware for module: 'bfa'
==> WARNING: Possibly missing firmware for module: 'csiostor'
==> WARNING: Possibly missing firmware for module: 'wd719x'
==> WARNING: Possibly missing firmware for module: 'qla1280'
==> WARNING: Possibly missing firmware for module: 'ums_eneub6250'
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful

Es gibt jetzt bei mir eine ganze Liste dieser potenziell fehlenden Treiber. Aber auch nach einem Neustart funktioniert noch alles.
Wenn dein PC kein Intel verbaut hat, dann benötigt er auch keine Treiber für Intel.
Aber leg dir sicherheitshalber einen aktuellen arch-linux.iso Stick bereit, dann kann nichts mehr schief gehen.

Josephus Miller

tuxnix Bei mir kommt jetzt auch eine ganze Reihe solcher Meldungen von potenziell fehlenden Treiben beim Erstellen des fallback images.

Dirk Die potentiell fehlenden Treiber haben nur indirekt mit der beschriebenen Änderung zu tun, das Phänomen trat auch schon vorher auf.

Bei mir trats wie geschrieben beim Erstellen des normalen Image auf, nicht nur beim Fallback. Erst nach der erneuten Installation der Intel-Firmware war es wieder weg. Scheint - wenn mit dem Hook zusammenhängt- vermutlich mit der Verschlüsselung zu tun zu haben.

GerBra ngenommen ich hänge die Platte in ein komplett anderes Motherboard/CPU-Vendor rein:
Mit dem "alten" per autodetect erstellten InitRamdFS-Image würde der Boot wohl sowieso nicht funktionieren. Da wahrscheinlich eben die nun notwendigen early module nicht drin sind.
Dafür ist ja dann das fallback-Image da, da dort alle Module drin sind. Nun kann es dann halt nur sein, daß bestimmte Firmware dann nicht vorhanden ist wenn man nicht das Meta-Paket verwendet.
(Aber dafür gibt es ja externe Boot-Medien zum reparieren...)

Oder man denkt vorher dran und installiert das Meta-Paket 😏

Dirk

Die potentiell fehlenden Treiber haben nur indirekt mit der beschriebenen Änderung zu tun, das Phänomen trat auch schon vorher auf.

GerBra

Dieser Link ist auch hilfreich, damit kann geprüft werden welche Firmware geladen wird beim Boot.
https://wiki.archlinux.org/title/Linux_firmware#Detecting_loaded_firmware

Bei der gesplitteten Firmware muß man halt im Hinterkopf behalten, daß ggf. bei einem Hardware-Zuwachs oder einer Hardware-Änderung weitere/andere Firmware gebraucht wird.

Angenommen ich hänge die Platte in ein komplett anderes Motherboard/CPU-Vendor rein:
Mit dem "alten" per autodetect erstellten InitRamdFS-Image würde der Boot wohl sowieso nicht funktionieren. Da wahrscheinlich eben die nun notwendigen early module nicht drin sind.
Dafür ist ja dann das fallback-Image da, da dort alle Module drin sind. Nun kann es dann halt nur sein, daß bestimmte Firmware dann nicht vorhanden ist wenn man nicht das Meta-Paket verwendet.
(Aber dafür gibt es ja externe Boot-Medien zum reparieren...)

tuxnix

Josephus Miller Bei mir trats wie geschrieben beim Erstellen des normalen Image auf, nicht nur beim Fallback. Erst nach der erneuten Installation der Intel-Firmware war es wieder weg. Scheint - wenn mit dem Hook zusammenhängt- vermutlich mit der Verschlüsselung zu tun zu haben.

Seltsam, wenn das auch beim normalen Image auftritt. Wie sieht denn die Reihenfolge in der /etc/mkinitcpio.conf in die Zeile HOOKS= aus? autodetect darf hier auch ganz vorne stehen.

GerBra

Josephus Miller Scheint - wenn mit dem Hook zusammenhängt- vermutlich mit der Verschlüsselung zu tun zu haben.

Ist wohl so, da der encrypt-Hook per Default alle Kernelmodule aus dem <kerneldir>/crypto/ hinzufügt - eben auch welche, die für Intel-Hardware gedacht sind. //Edit: Und dann eben ggf. Firmware benötigen.

Wenn du das unbedingt vermeiden möchtest, dann müßtest du deine verwendeten Crypto-Module in /etc/mkinitcpio.conf oder als Schnipsel in /etc/mkinitcpio.conf.d/ eintragen:
CRYPTO_MODULES=(foo bar baz)
Dadurch werden nur diese Module ins initcpio-Image gepackt, wobei evtl. nötige Firmware ja schon vorhanden sein sollte (sonst funktionierte Encrypt aktuell ja garnicht).
//Edit2: Der Hook ist in:
/usr/lib/initcpio/install/encrypt

Ist halt die Frage, wieviel "Spieltrieb" man aufgrund der Möglichkeiten des Firmware-Splits investieren will. Aus der Wiki-Seite:

Install the linux-firmware meta package to pull all commonly used firmware. This is the recommended way for most users.

Die ganzen Jahre "schleppte" man ja auch diversen "Firmware-Ballast" mit sich rum, mußte sich aber keine Gedanken machen. Wie @Dirk schon sagte: Sind nur ein paar Hundert MB.
Wer jetzt halt eine "kuhle Socke" sein will oder spielen, der/die/das muß halt an vieles denken - und zwar nicht nur jetzt, sondern auch noch in einem halben Jahr was man da "feingetüftelt hat an seinem Hochtechnikmaschinengerät" ;-)

Josephus Miller

tuxnix Wie sieht denn die Reihenfolge in der /etc/mkinitcpio.conf in die Zeile HOOKS= aus?

HOOKS=(base udev autodetect microcode modconf block keyboard keymap encrypt lvm2 filesystems fsck shutdown)

tuxnix

GerBra
Ich fand es einfach mal interessant hier näher rein zu schauen. Außerdem kann ich mir vorstellen, dass der Split einen Hintergrund hat. Bei Ubuntu (das soll jetzt kein Maßstab sein) sind es nicht knapp 300MB wie bisher bei Arch Linux, sondern 800MB in einem einzigen firmware Paket, das jedes mal ein upgrade verlangt, auch wenn sich dabei nur ein einziger Treiber ändert, den man womöglich nicht einmal braucht. 800MB x der Anzahl der Rechner die damit versorgt werden müssen ist dann schon eine ganze Menge. Jedenfalls macht man sich dort auch inzwischen Gedanken über einen Split.
Es ist natürlich praktisch, wenn die meiste Hardware nach einer Neu-Installation funzt ohne sich einen Kopf darüber machen zu müssen, aber vielleicht gibt es da auch elegantere Lösungen und der Split könnte der erste Schritt in diese Richtung sein. Die Hinweise beim fallback sind jedenfalls auch nicht besonders elegant.
Aber das ist jetzt wohl doch eher im Bereich von Philosophie.

Josephus Miller

GerBra Ist halt die Frage, wieviel "Spieltrieb" man aufgrund der Möglichkeiten des Firmware-Splits investieren will.
...
Wer jetzt halt eine "kuhle Socke" sein will oder spielen, der/die/das muß halt an vieles denken - und zwar nicht nur jetzt, sondern auch noch in einem halben Jahr was man da "feingetüftelt hat an seinem Hochtechnikmaschinengerät" ;-)

Kuhle Socke bin ich eh 😎, der Ursprungsgedanke war einfach das System verschlanken. Aber zuviel schrauben mag ich da nicht (mehr), mach ich lieber an meinem Bike 😁

Nächste Seite »