Um zu sehen, ob Firmware nachgeladen wird, nimmt man als ersten Check (evtl. per ssh, wenn man nix sieht):

dmesg|grep -i firmware

das sollte die geladene Firmware ausgeben. Man kann aber auch anders herangehen über den Source Code und das Device.

Falls eine Firmware gebraucht wird, aber es einmal geht und mal nicht, könnte man die Checksummen so sichern:

for x in $(modinfo amdgpu -F firmware); do sha256sum -b /lib/firmware/$x 2>/dev/null;done|sort -k2|tee /root/firmware1.sha256sum

Wichtig ist aber das device. Ein Modul wird von udev/systemd geladen über die alias Einträge

modinfo amdgpu -F alias

Bei amdgpu kann man davon ausgehen, dass es primär über

pci:v00001002d0000XXXXsv*sd*bc*sc*i*

alternativ kann man auch /lib/modules/$(uname -r)/modules.alias parsen:

grep amdgpu /lib/modules/$(uname -r)/modules.alias

alias pci:v00001002d0000XXXXsv*sd*bc*sc*i* amdgpu

geladen wird, der Vendor 1002 = AMD sollte eigentlich immer gleich sein. Das könnte man schon mit

lspci -nn

sehen, wenn man es sich einfach machen möchte nimmt man gleich

lspci -nnv

dann steht das Kernel modul gleich da

Möchte man es "komplizierter" findet man nur die IDs von VGA über

lspci -n|grep 0300:

Hat man also das Device, dann geht man in den Code. In amdgpu_drv.c findet man eine Definition

static const struct pci_device_id pciidlist[] = {
        {0x1002, 0x6780, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI},
        {0x1002, 0x6784, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI},

usw. An letzter Stelle wird ein Chiptyp definiert. Im einfachsten Fall wird der Name des Chips im Firmwarenamen vorkommen.

modinfo amdgpu -F firmware|grep -i TAHITI

amdgpu/tahiti_mc.bin
amdgpu/tahiti_rlc.bin
amdgpu/tahiti_ce.bin
amdgpu/tahiti_me.bin
amdgpu/tahiti_pfp.bin
amdgpu/tahiti_uvd.bin
amdgpu/tahiti_smc.bin

Das schränkt das ganze noch weiter ein. Es kann sich dann nur noch um ein Paar Files handeln, die man betrachten müsste. Man könnte den Firmware Tree sichern, und gezielt einzelne Dateien löschen und die Initrd neu generieren. Lustigerweise scheint es ja besser zu gehen, wenn in der Initrd weniger Module sind. Es kann natürlich auch sein, dass genau das Gegenteil der Fall ist, dass zuerst gar kein amdgpu.ko* File in der initrd war, dann kann es da gar nicht geladen werden sondern erst später. Dann wäre aber das komplette /lib/firmware Verzeichnis da, wenn das Modul geladen wird. Auch in dem Falle müsste man einen Unterschied bei den Firmware Einträgen in dmesg sehen. Ohne dmesg kann man nix debuggen. Besonders schön war der Suspend Kommentar, evtl. vor Suspend

dmesg -c

und danach wieder

dmesg

das sollte evtl. auch was anzeigen.

Sollte das Problem eher bei dracut liegen, dann müsste man es wohl anders debuggen, bei Debian wird normalerweise initramfs verwendet. Meiner Meinung nach ist es belanglos wie groß die initrd ist, besonders wenn man nicht permanent bootet. Bei Cloud systemen kann die Boottime entscheidend sein (da wird auf ms optimiert), bei Desktop/Laptops dauert es vielleicht ein paar Sekunden länger. Hab gerade gelesen, man kann das Verhalten von dracut beeinflussen:

dracut --force --no-hostonly

würde eine initrd erstellen, die nicht auf das Hostsystem optimiert ist, dass man die installation auf nem komplett anderen PC evtl. auch nehmen kann, wenn es vorher Probleme gegeben hätte. initramfs hat solche Optionen nicht.