The Electrons Must Flow!

File this under #cool-story-bro…

My little part of the world was experiencing high winds a week or so ago, which caused a power outage one morning. I was using my main machine when the lights went out, and when the electrons came back, I tried restarting my machine, hoping for and expecting the best possible outcome.

However, the best wasn’t what I got. The sudden unexpected power drop caused some problems.

While my main machine seemed to boot properly at first, the Bluetooth stack wasn’t working at all. This is a problem because my mouse is Bluetooth, so I had to fall back on my keyboard and shell skills. I tried several times to restart the Bluetooth driver stack, and threw in a few reboots for good measure, all to no avail.

So, I decided to drop back and try some BIOS diagnostics to see if there was an actual hardware issue.

Bad news: Diagnostics showed a metric buttload of memory and HD errors.

Well, maybe not a butt-load — there were just five errors, after all. Still, it was more than I expected, which was zero. Even worse, those five errors said the HD was bad, along with each bank of memory.

However, the reported errors just didn’t jive with my experience. After all, I could boot my machine — it was just that Bluetooth wasn’t working.

  • If the HD was failing, I shouldn’t have been able to boot at all.
  • And if every bank of memory was bad, I should have seen all sorts of weird errors which were different every time.

It just didn’t feel like the massive hardware problem my diagnostics were reporting.

There was one thing I noticed: BIOS Diagnostics recommended I update my BIOS. Since I wasn’t at all keen on replacing a 2Tb SSD and 32 Gb of RAM on a barely two year old machine, I decided to try that route first.

If I’m In, Tell Them I’m Out

So I grab my laptop and head to my manufacturer’s website to download the latest BIOS update, which comes as an EXE file. This is great… if you run Windows.

I don’t run Windows — both my main and laptop machines run Manjaro Linux, and you can’t run .EXE files on Linux. (You can in some cases, but that’s another story.)

So what to do? Well, on my machine (and many others), you can access the BIOS boot menu by hitting F12 as the machine restarts. This gives you an option to update your BIOS directly by providing the EXE file on a USB drive.

So I copy the new BIOS .EXE file to a USB key, insert it into my main machine, reboot, hit F12, and select the BIOS Update option. I’m taken to a screen which asks me to find the .EXE file to use. I do this, then select the "Flash Update BIOS" button.

This immediately shows an error dialog with the message "AMI BIOS Guard feature disabled". No new BIOS was installed.

I try again, holding my tongue in a different position this time. No effect.

So I fall back to searching the internet for answers.

If No One Writes About a Problem, Is It Still a Problem?

Apparently, I am only the second person ever to write about this problem, because my best DuckDuckGo-fu turned up only one page with this specific error message.

Sadly, the suggested resolution on that one page was the equivalent of "dust off and nuke the site from orbit". There were no updates on whether that killed the alien or not.

Since I didn’t want to whack my BIOS and restart from scratch, I did what any good former support/test engineer would do — I started changing things to see if I could change the problem. Since this was a BIOS issue, I started changing BIOS settings.

Now, I’d love to tell you I spent hours tweaking this thing or revising that setting, but the truth is the first thing I tried was also the thing which worked. What can I say — sometimes you get lucky.

What did I do? I enabled Secure Boot in the BIOS, and disabled Legacy Boot.

It’s So Secure, Even We Can’t Access It

According to Microsoft, "Secure boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM)."

It’s meant to help protect your boot files, like UEFI firmware drivers and the OS kernel, from being replaced by bad actors. However, it also prevents you from doing things like replacing the OS on the device with something else.

Secure Boot kept me from installing Manjaro on my machine, so I disabled it. This allowed me to finally install the new BIOS, since AMI BIOS Guard is a part of the Secure Boot system.

How do I know this? I know this because the error went away when I turned on Secure Boot. More specifically, I did not learn this from AMI — there’s nothing on their site about BIOS Guard that I could find.

Of course, I had to disable Secure Boot again after the BIOS was updated so I could get back into Manjaro, but that was easily done. I also re-ran diagnostics, and wouldn’t you know, all the reported problems were gone. It’s a miracle!

Morals

Now, I’m not Aesop, so my posts don’t need to have a moral, but there may be one or two of them here anyway…

The first is that problems are just that: problems. They’re not judgments. They’re not punishments. They’re obstacles that are meant to be solved and overcome. Solving problems increases your skills, boosts your confidence, and makes you a better steward of your possessions.

The second moral is related to the first, and is a sentiment I’ve held for a while, which I first heard from the maker community:

If you can’t fix it, you don’t own it.

This is closely linked to the right to repair movement. Simply put, I paid a lot of money for my computer and other devices, and I want them to work the way I want them to work. If the only way to fix, modify, change, or update the device is through a manufacturer’s process, then I don’t want it.

This is also why I don’t like ink-jet printers, but that’s a rant for another day.