Comment 2 for bug 1953249

Per coincidence, I worked on this same bug today, as I'm hoping to try make use of the amdpro legacy OpenCL drivers, which will need amdgpu as a base.

The issue is Ubuntu is providing newer kernel HWE stacks with amdgpu driver modules, but failing to keep related Linux firmware packages up to date and in lockstep. E.g. 20.04.3 LTS is based on kernel 5.11 from hirsute (21.04), but the linux-firmware collection is left outdated on 1.187.20 that came with kernel 5.4?

https://packages.ubuntu.com/hirsute-updates/linux-firmware shows v 1.197.3, so I'd expect a HWE stack with 20.04.3 to also provide the same level of firmware updates for kernel 5.11.

> I use UEFI and the module wasn't signed

Perhaps installing the official deb/repo instead of upstream has a good shot at the firmware that gets added into initramfs being signed properly (one would hope!). I manged the following workaround, but my case is still legacy BIOS.

curl -OL http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.197.3_all.deb
sudo dpkg -i linux-firmware_1.197.3_all.deb

Extra hint: maybe download the deb from your closest mirror because this package is almost 200MB large.

P.S. While most firmware is hopefully decoupled and backward compatible to use with older kernel modules/drivers, one never knows if a bug might show up by using very new firmware with much older modules, since you stray into a untested path between the firmware and the kernel modules. Hence I tried to match the Ubuntu release, kernel versions, and tested-at-the-time firmware more closely than just jumping to latest upstream firmware versions.

Its similar but a kinda upside version of the older proprietary graphics driver blob hell that plagued Linux over the previous decade. Firmware is the other way round where the in-tree admgpu driver needs the firmware to provide a stable interface. Can't recall if Linux ever solved the lack of a stable in-kernel/versioned ABI between drivers and binary driver blobs. It's why AMD FGLRX proprietary drivers blobs were always hell, and AMD failed to keep up with ABI changes on the kernel and often didn't work with newer kernels, hence amdgpu became the new middle layer/foundation to bridge this ABI gap and add create a stable/presumably versioned ABI for AMD that the kernel developers never bothered to provide. Now AMD-pro software and extended driver blobs can rely on the opensource amdgpu parts to be less of a moving target as ABI changes on the kernel core will need to update/include required changes to amdgpu because amdgpu is now in-tree and should be tested in lockstep with other kernel changes.