Several times in the past few weeks my Mini has become unresponsive after going into standby. The blue light (furthest from the power button) is flashing continually. This happened on Fedora 36 and now with Fedora 39.
Can anyone suggest some troubleshooting options to narrow this down? I’ve had this mini now for a couple of years, I think, and it has worked well up to this point.
thanks,
Anthony
Try a different operating system and see if the issue persists.
Disable standby? It may depend on how you use this device but, with a mains-powered device, standby is less important.
Are you able to test any earlier versions of Fedora to see whether there is a regression? (Disclaimer: I have never used Fedora.)
Given “a couple of years”, I assume that you have a Mini v1, not a Mini v2. I would be checking whether you have the latest boot firmware for your device.
Thanks! I’ll check the firmware.
I did the coreboot update. This is a Mini v2.
This morning, the machine was locked up again.
Can anyone suggest any logs I can review? If so, what should I look for?
I’m going to try to disable the standby tonight.
Thanks!
Logs can be fairly unproductive for a lock-up, for various reasons e.g. the lock-up itself prevents anything useful being written to the log or e.g. the last thing that did get written to the log is spuriously blamed.
If this is a Mini v2, it might still be under warranty so it is possible that Purism would assist you with troubleshooting. However they are probably going to ask you to run PureOS.
Can you live boot PureOS and reproduce the lock-up? (That would be ideal because it also eliminates from consideration any unusual settings that you may have made and any unusual software that you may have installed.)
Yes, live-booting PureOS is preferable as the environment is better understood by the support team and could be easily reproduced. My daily driver, for example, is a Librem Mini v2 running coreboot/SeaBIOS->Ventoy->Debian or PureOS live ISOs. However, the system in a live-boot setup differs somewhat from the same environment running on bare metal and therefore may change some variables in troubleshooting the same issue…
…but live-booting is a quick, free, and non-destructive approach, and those are the best ones to start with. 
Thanks, everyone. I’ll see about doing a live PureOs boot.
I turned off auto suspend, and the issue hasn’t happened again. I’m going to try a pureos boot next week.
thanks
Anthony
I upgraded to Fedora 39 and the problem went away.
The OP actually says that the problem happens with Fedora 39. Is one of those version numbers incorrect?
There were a few sources of failures to resume that have all been fixed in firmware in the current releases (coreboot/SeaBIOS 4.22.01-Purism-1, PureBoot 29). Disabling suspend would have worked around these issues as well. A few of the issues also would persist through the first reboot into the new firmware after upgrading, resume works properly on the next reboot or cold boot with the new firmware.
If this pops up again or anybody else is looking in this thread for an answer, please update to the latest firmware using the firmware utility script and then reboot one more time.