I happen to run on an ASRock Fatal1ty B450 Gaming-ITX/ac motherboard that used to run fine, but ever since I installed one UEFI update, it has had this one annoying issue: whenever you reboot, it gets stuck at POST. Cold boots work fine and the shutdown-and-push-the-power-button cycle also does the trick, but it’s not something I want to do all the time, especially when the machine is out of reach.

Before you say it: no, warranty service was not an option here, especially since this motherboard has suffered a fall once and it has this slight curvature in it. No, this separate incident was after this freezing issue started occurring.

Initial troubleshooting

I went through most of the standard hardware troubleshooting procedures:

  • clear CMOS
  • re-seat RAM
  • try a different CPU
  • disable features in UEFI, reduce PCIe speeds
  • disconnect storage devices

No luck, issue was still there. The POST code was stuck at A0. When taking a look at the ASRock Dr. Debug POST codes list, I saw that A0 falls under

Problem related to IDE or SATA devices. Please re-install IDE and SATA devices. If the problem still exists, please clear CMOS and try removing all SATA devices.

Since I had just done that procedure, and the issue was still there, I was stumped.

Wake-on-LAN

I had tried wake-on-LAN many years ago and was successful with it, so I thought that perhaps this could be an option. After all, I really did not want to get a new motherboard if I could just work around this issue.

I checked the ASRock UEFI for various wake-on-LAN related settings and found a couple of them. Oddly enough, the Wake on LAN setting itself only became available after I enabled booting from LAN in a completely unrelated UEFI section. In addition to the Wake on LAN setting, I also made sure to enable waking up from PS2 and PCIe devices, just in case.

After a quick Google search I found the Arch Linux Wiki page on this topic and saw that I needed to make sure that my network adapter was configured properly for wake-on-LAN to work.

[root@my-machine]# ethtool enp9s0 | grep Wake-on
	Supports Wake-on: pumbg
	Wake-on: g

Super, everything should work then!

I set up an always-on machine to send the wake-on-lan magic packets using wol every minute so that the machine eventually wakes up again. It’s configured, I shut down the problematic machine and wait.

Nothing happens.

Huh, perhaps I missed something.

No, everything was configured properly and the magic packet setting g was on by default.

I checked the wiki page again and two things caught my eye:

Note: Setting one of u, m or b along with g might also be necessary to enable the feature.

It is known that some motherboards are affected by a bug that can cause immediate or random wake-up after a shutdown whenever the BIOS WoL feature is enabled

Well, that’s interesting.

I added * * * * * ethtool -s enp9s0 wol pumbg to my crontab and shut my machine down.

Power supply does a click. Silence. Another click, ethernet port LED-s light up and my machine is powered on again. Success!

As it turns out, I did not even need to enable sending wake-on-LAN magic packets from another machine, the two motherboard issues managed to cancel each other out.