![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
http://bugzilla.opensuse.org/show_bug.cgi?id=1177256
http://bugzilla.opensuse.org/show_bug.cgi?id=1177256#c8
--- Comment #8 from Stefan Dirsch
The problem is that the dracut config snippet contains fw_dir+="/lib/firmware/5.3.18-lp152.36-default"
and this *overrides* the whole firmware search path, not appending the given one.
Hmm. The manual page tells me something different. # man dracut.conf [...] fw_dir+=" :<dir>[:<dir> ...] " Specify additional directories, where to look for firmwares, separated by : [...] Nevertheless I think this is what they want (replacing them).
Meanwhile the standard amdgpu firmware is provided in /lib/firmware. So this path is no longer searched, hence the firmware loading fails.
Well, I would assume the AMD Pro driver ships firmware with special features and/or better tested against the Pro driver.
So, the simplest solution would be to just drop the line above.
Well, I would assume this would removed special features of Pro driver or may make it less stable. So I wouldn't recommend this.
OTOH, if a KMP provides its own firmware in /lib/firmware/$VERSION and it must use it, it becomes a problem, indeed, when the kmp is weak-linked to a different kernel version. Is this really the case?
AFAIK AMD Pro drivers are installed via dkms, so this is not weak-linked but probably rebuilt once when the new kernel gets started (if I understood the dkms system correctly).
If yes, we'd need to fix weak-modules2 script in suse-module-tools package to deal with the firmware files in a weak-linked kmp, too.
AMD would need to fix this in dkms somehow. Probably at the same time when the
modules(s) get rebuilt for the new kernel version.
Either copying the firmware files to /lib/modules/