Failed to load firmware "amdgpu/green_sardine_sdma.bin"

I am on Manjaro Testing Branch. I have installed the latest updates. But afterwards I am unable to get into my system.

Whenever I try to boot the system, it comes to this screen and basically gets frozen. I can’t even get into tty from here.

From the photo you can see the culprit is “amdgpu/green_sardine_sdma.bin” is failed to load.

I have AMD Ryzen 5600G CPU with no external GPU. It was working fine prior to the last update.

I have tried to log into the system with another live usb with manjaro-chroot. From there I have looked into /lib/firmware/amdgpu and saw a file named green_sardine_sdma.bin.zst

Anyway I have tried to remove the .zst extension from that file and boot again. This time the system didn’t throw that error and went upto Started Gnome Display Manager and some other messaged after that. But then it gets stuck in this screen (blinking cursor)

From this screen I can go into tty by the way.

I have checked for updates but there is none. I am assuming it has something to do with the graphics driver. Here is the output of mhwd -l

I don’t know what else to do other than reinstalling the OS. But I really don’t want to go into that route unless I have to. Help would be much appreciated. Thanks!

no, no, no - don’t do that and why do you think that is even a solution?

Manjaro uses zst compressed modules …

And - please - do not post photos of text ( or screenshots ) - you could have described that it easily with a few words …

Just removing the extension won’t change the file.
It is a compressed file -
you could have unpacked/decompressed it
and ended up with a file with the suffix .bin
and thereby with the file name that was not found.

unzstd file_name
No chroot needed to do this - just mounting is enough.

In my stable installation, none of these firmware files are compressed.
They all have the .bin extension.

But you are on testing - I would not have expected this change, this difference.

You could always just revert back to stable branch - no?

I am thinking - although it is a grasp in the dark - is it an old installation or has it been created within - say - 6 months?

My current workstation was last reinstalled 2023-12-26 and it uses compressed modules.

That is likely due to being before - I can’t remember when - point in time where Arch switched to loading zstd compressed modules.

As I occasionally replace my system - I have a system where modules are provided compressed to the kernel.

The system I just looked at was Manjaro Gnome, installed in a VM about a week or two ago.
The iso used was this:

I thought that was just the kernel modules - this is firmware.

Sorry for the screenshots.

About the extension, it was just a hunch to see where else it might fail. Because changing the extension will not change the binary I could easily revert it back.

I have reverted it back since then.

It is infact an old installation. More than a year at this point.

I suppose I could try that. In that case I have to downgrade all my packages to the latest stable versions as well, right? Otherwise nothing changes until the stable branch catches up.

By the way it is not like I have just switched to testing branch, I am on testing for as long as the system is alive. And also this doesn’t shed any light on where the actual problem is. It was all okay before the last update.

I’d first have a look at the pacman cache - you might still have the previous version of linux-firmware
For me on stable this is:

ls -al /var/cache/pacman/pkg/linux-firmware-*                                                                                                                            ✔ 
-rw-r--r-- 1 root root 130751118 21. Feb 16:20 /var/cache/pacman/pkg/linux-firmware-20240220.97b693d2-1-any.pkg.tar.zst
-rw-r--r-- 1 root root       310 21. Feb 16:20 /var/cache/pacman/pkg/linux-firmware-20240220.97b693d2-1-any.pkg.tar.zst.sig
-rw-r--r-- 1 root root     36087 21. Feb 16:20 /var/cache/pacman/pkg/linux-firmware-whence-20240220.97b693d2-1-any.pkg.tar.zst
-rw-r--r-- 1 root root       310 21. Feb 16:20 /var/cache/pacman/pkg/linux-firmware-whence-20240220.97b693d2-1-any.pkg.tar.zst.sig

While you are at it, you could also inspect the contents of the current firmware package that presumably got installed when you switched to the testing branch.

I’d just install the “old” version - can’t hurt much:
sudo pacman -U /var/cache/pacman/pkg/linux-firmware-20240220.97b693d2-1-any.pkg.tar.zst
adapt the name if needed.

Or, as mentioned above, you could just unpack the firmware .zst file
to see whether this will solve the problem.

cd /usr/lib/firmware/amdgpu
(adapt the path when not in chroot)
unzstd /usr/lib/firmware/amdgpu/green_sardine_sdma.bin.zst

Yes, that remains …

AMD Ryzen 5600G CPU

It a fairly recent APU - there is no reason it should not load the firmware.

Just spilling some thought …

Do you have amd-ucode in /boot ?

Do you have microcode hook in /etc/mkinitcpio.conf ?

Do you have kms hook in /etc/mkinitcpio.conf ?

I just compared the contents of the linux-firmware packages between stable and testing.
In the package for stable, all the firmware files are uncompressed.

In the package for testing, all the firmware files are compressed.

I got it from one of the mirrors:

Big change - may be the reason. :man_shrugging:

Possibly - not all kernels support compressed firmware - but that shouldn’t be an issue with an APU from Q3-2021.

As I recall not all kernels support compressed firmware - I will see if I can lookup where the important point is.

Additional question

Which kernel are you booting ? As a minimum you need Linux 5.4 LTS (released 2019-11-24)


What I don’t understand is why you are getting this issue at all ?

It is strange to me, that the testing branch - for more than a year now at least - would have a version of linux-firmware with all compressed files in it
and that this would not have made it’s way into stable in the meantime.

Because there, in the stable branch, the firmware files are all uncompressed.

If your system is more than a year old, then you should have other, older versions of the same firmware package in your pacman cache - you could look if this was a recent change (and could therefore be a cause of the problem) or if that was already the case in the previous versions.

Just look inside the archives … :man_shrugging:
Then you know and there is one less thing to worry about.

When I have time and feel like it, I will clone one of my VM’s and use that to convert to testing branch
and see what happens …

after the conversion the system works as expected - no problems
But this being in a VM there is likely no Firmware involved that could fail to load.
So: test inconclusive :man_shrugging:

I don’t have that. I have intel-ucode.img!

Again no. These are the hooks HOOKS="base udev autodetect modconf block keyboard keymap consolefont filesystems fsck"


I am confused - your system is not AMD?

I mean - AMD 5600G ?

You are correct these compressed files are recent addition. In pacman cache I have found two firmware one is linux-firmware-20240409.1addd7dc-1.0-any.pkg.tar.zst which has the compressed firmware files. But there is another one linux-firmware-20240409.1addd7dc-1-any.pkg.tar.zst that has the uncompressed binaries.

It is AMD system. I am confused as well seeing the intel files.

Output of lscpu

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  12
  On-line CPU(s) list:   0-11
Vendor ID:               AuthenticAMD
  BIOS Vendor ID:        Advanced Micro Devices, Inc.
  Model name:            AMD Ryzen 5 5600G with Radeon Graphics
    BIOS Model name:     AMD Ryzen 5 5600G with Radeon Graphics          Unknown CPU @ 3.9GHz
    BIOS CPU family:     107
    CPU family:          25
    Model:               80
    Thread(s) per core:  2
    Core(s) per socket:  6
    Socket(s):           1
    Stepping:            0
    CPU(s) scaling MHz:  22%
    CPU max MHz:         4464.0000
    CPU min MHz:         400.0000
    BogoMIPS:            7788.17
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx
                          mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni
                          pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legac
                         y svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfc
                         tr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 
                         smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc 
                         cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv
                          svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload
                          vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm debug_swap
Virtualization features: 
  Virtualization:        AMD-V

It didn’t. It was getting stuck at random points.

That helped! So I am back to kernel 5.15.158 now.

Thank you both for taking your time to help.

But what would be my next course of action? If I update the system, most likely I will face the same issue again. Should I wait for next release? Or reinstall the OS?

I can only tell you that I converted my system to testing yesterday and the procedure went without issue and the system works.
I do not know what you should look for.

You should install amd-ucode - but I don’t know whether that would change anything.
Why you would not have it on an AMD system - I don’t know.

Run another update? - Don’t know whether testing also received a large one today - be careful.

I just had the same issue when running a regular pamac upgrade on the stable branch.
I have the same CPU setup as the OP - Ryzen 5600G using integrated graphics.
I don’t have a handy recovery key so can’t fix the pacman cache. Is it a reinstall from scratch situation?

What are you talking about?
What is (for you) a “handy recovery key”?
Why would you want to “fix the pacman cache”?

Create your own thread - and provide information …

Please update and see if it resolves your issue: