Tweet
I have been maintaining quite a few computers up to now, and have seen some really weird things happen with regards to their firmware (BIOS/UEFI). I'm wondering if I'm just unlucky, or if really that many people hit issues like that. So I'm interested to know what firmware issues you have run into so far on your computers.
In my case, the weirdest issues I've hit on a PC from 2007. It has a regular BIOS, the motherboard is by Gigabyte. In theory, it supports USB 2.0 devices. By default, however, legacy USB devices are turned off. Which means that to activate the support in the first place, you absolutely need a PS/2 keyboard. You would also need it if you restored BIOS defaults, either by clearing the CMOS or updating the BIOS.
But that's the smallest issue. When this support is enabled, the BIOS does discover USB drives that are connected, and it's possible to tell the BIOS to boot off them. However, that doesn't actually work as expected... If I try to boot anything complex, like a LiveCD, the BIOS just sits there, forever, not even getting to the point of showing SYSLINUX, and without any messages about it. And if I try to boot anything simple, like memtest86+... It fails so much it reboots. If the USB device is set to be primary boot media, that means an infinite restarting loop!
I thought that updating the BIOS version could probably help with this issue. So I downloaded the update, wrote it on a USB drive, then tried to get the BIOS to update itself. And even though it showed the drive and allowed to access the files... it still wouldn't accept the update file. And it was definitely the correct version. So I had to use @BIOS (would have tried FlashROM first, but, you know, USB boot didn't work). And, well, @BIOS is supposed to get the BIOS version, connect to Gigabyte's servers, download an update, then apply it (in the process possibly destroying the system, as @BIOS is known for its notorious unreliability). But it wouldn't connect to any Gigabyte server at all. So I had to manually specify the update file (the same I had written on USB). Thankfully, it worked fine, @BIOS accepted it and flashed it successfully.
That helped... a bit. It no longer hangs or reboots, but booting off anything over USB is still super slow. And, of course, there is no hope for any updated BIOSs for that motherboard at this point, as it's no longer maintained (the update was from 2009).
The next to worst issues I've hit was on an Asus EeePC with an AMD APU, using UEFI. It's one of those silent UEFIs that masquerade as BIOSs (so that consumers wouldn't discover what type of firmware it's running, perhaps?
). By default it does MBR boots through its legacy BIOS support, and there is no way to turn it off. I wanted to install Gentoo on it, and using all the capabilities, including UEFI and GPT. In order to install anything in UEFI mode, you need to boot into UEFI mode first. So I grabbed a Kubuntu Live USB. Thankfully the UEFI automatically tries to launch whatever is in EFI/BOOT/BOOTX64.EFI on USB media (an amazing feat for it, because it surely doesn't try to do that when booting from the hard drive itself!). The installation went fairly well (especially considering that Kubuntu isn't exactly an official Gentoo installation medium - but it sure is much easier to install from it than the official one!), until I got to the bootloader installation part. Now normally that should be easy, you just use grub2-install, tell it that it should use UEFI capabilities, then point it at the EFI system partition. Except that whenever I did that... the kernel would panic citing something about EFI variables, and on reboot nothing would be booted (the GRUB entry isn't added to the UEFI). I heard that different kernel versions would have a different effect, so I would use Kubuntu's GRUB to chainload the hard disk GRUB, then change a kernel version and try again. A slightly newer kernel didn't crash any more, but instead efibootmgr game me error messages and still wouldn't put an entry into UEFI. Updating to the latest kernel would make the kernel panic return.
So that was unfortunate, conventional means are apparently not enough to make the UEFI boot Linux natively. My first thought was to upgrade the UEFI. The Asus firmware update page is extremely confusing, though. The UEFI wouldn't upgrade to what Asus claims to be the correct firmware to use, but accepts the one that they claim to be for slightly different systems fine. Either way, an update changed nothing, the same issues stayed.
My last option was to add an entry manually through the UEFI shell. Problem? The UEFI doesn't include one. Instead they have an UEFI entry that boots from the first ShellX64.EFI file it finds (thankfully it searches the hard drive as well). On one hand, that could be a workaround ? the UEFI doesn't do any checks of what the file is, so naming GRUB "ShellX64.EFI" would make it boot. But there is no way to set that as the default option, so each time you wanted to boot, you'd have to enter the UEFI options, which is of course not an option. The real fix would be to boot into an actual UEFI shell and change the variables from there.
Since there is no official UEFI shell included anywhere, I had to use TianoCore's UEFI shell. It comes in two varieties ? UEFI shell v2 (for UEFIs compliant with UEFI 2.3+ spec) and UEFI shell v1 (for earlier ones). I tried v2 first, but, surprise surprise, it failed to boot. Apparently that UEFI is not UEFI 2.3 compliant. So I booted into shell v1... but it doesn't include bcfg, which is the command that actually does the UEFI variable changing. Thankfully the Arch wiki also has a link to a modified shell v1 with bcfg that finally allowed me to add a GRUB entry manually, and set it to default. Phew! Now I just hope nothing ever touches the EFI variables of that thing again (or else get an UEFI-induced kernel panic).
And that's just two of the firmwares I've had trouble with. I'll add my experiences with some of the others a bit later. In the mean while, does anyone else have firmware-related stories to share?
In my case, the weirdest issues I've hit on a PC from 2007. It has a regular BIOS, the motherboard is by Gigabyte. In theory, it supports USB 2.0 devices. By default, however, legacy USB devices are turned off. Which means that to activate the support in the first place, you absolutely need a PS/2 keyboard. You would also need it if you restored BIOS defaults, either by clearing the CMOS or updating the BIOS.
But that's the smallest issue. When this support is enabled, the BIOS does discover USB drives that are connected, and it's possible to tell the BIOS to boot off them. However, that doesn't actually work as expected... If I try to boot anything complex, like a LiveCD, the BIOS just sits there, forever, not even getting to the point of showing SYSLINUX, and without any messages about it. And if I try to boot anything simple, like memtest86+... It fails so much it reboots. If the USB device is set to be primary boot media, that means an infinite restarting loop!
I thought that updating the BIOS version could probably help with this issue. So I downloaded the update, wrote it on a USB drive, then tried to get the BIOS to update itself. And even though it showed the drive and allowed to access the files... it still wouldn't accept the update file. And it was definitely the correct version. So I had to use @BIOS (would have tried FlashROM first, but, you know, USB boot didn't work). And, well, @BIOS is supposed to get the BIOS version, connect to Gigabyte's servers, download an update, then apply it (in the process possibly destroying the system, as @BIOS is known for its notorious unreliability). But it wouldn't connect to any Gigabyte server at all. So I had to manually specify the update file (the same I had written on USB). Thankfully, it worked fine, @BIOS accepted it and flashed it successfully.
That helped... a bit. It no longer hangs or reboots, but booting off anything over USB is still super slow. And, of course, there is no hope for any updated BIOSs for that motherboard at this point, as it's no longer maintained (the update was from 2009).
The next to worst issues I've hit was on an Asus EeePC with an AMD APU, using UEFI. It's one of those silent UEFIs that masquerade as BIOSs (so that consumers wouldn't discover what type of firmware it's running, perhaps?
). By default it does MBR boots through its legacy BIOS support, and there is no way to turn it off. I wanted to install Gentoo on it, and using all the capabilities, including UEFI and GPT. In order to install anything in UEFI mode, you need to boot into UEFI mode first. So I grabbed a Kubuntu Live USB. Thankfully the UEFI automatically tries to launch whatever is in EFI/BOOT/BOOTX64.EFI on USB media (an amazing feat for it, because it surely doesn't try to do that when booting from the hard drive itself!). The installation went fairly well (especially considering that Kubuntu isn't exactly an official Gentoo installation medium - but it sure is much easier to install from it than the official one!), until I got to the bootloader installation part. Now normally that should be easy, you just use grub2-install, tell it that it should use UEFI capabilities, then point it at the EFI system partition. Except that whenever I did that... the kernel would panic citing something about EFI variables, and on reboot nothing would be booted (the GRUB entry isn't added to the UEFI). I heard that different kernel versions would have a different effect, so I would use Kubuntu's GRUB to chainload the hard disk GRUB, then change a kernel version and try again. A slightly newer kernel didn't crash any more, but instead efibootmgr game me error messages and still wouldn't put an entry into UEFI. Updating to the latest kernel would make the kernel panic return.So that was unfortunate, conventional means are apparently not enough to make the UEFI boot Linux natively. My first thought was to upgrade the UEFI. The Asus firmware update page is extremely confusing, though. The UEFI wouldn't upgrade to what Asus claims to be the correct firmware to use, but accepts the one that they claim to be for slightly different systems fine. Either way, an update changed nothing, the same issues stayed.
My last option was to add an entry manually through the UEFI shell. Problem? The UEFI doesn't include one. Instead they have an UEFI entry that boots from the first ShellX64.EFI file it finds (thankfully it searches the hard drive as well). On one hand, that could be a workaround ? the UEFI doesn't do any checks of what the file is, so naming GRUB "ShellX64.EFI" would make it boot. But there is no way to set that as the default option, so each time you wanted to boot, you'd have to enter the UEFI options, which is of course not an option. The real fix would be to boot into an actual UEFI shell and change the variables from there.
Since there is no official UEFI shell included anywhere, I had to use TianoCore's UEFI shell. It comes in two varieties ? UEFI shell v2 (for UEFIs compliant with UEFI 2.3+ spec) and UEFI shell v1 (for earlier ones). I tried v2 first, but, surprise surprise, it failed to boot. Apparently that UEFI is not UEFI 2.3 compliant. So I booted into shell v1... but it doesn't include bcfg, which is the command that actually does the UEFI variable changing. Thankfully the Arch wiki also has a link to a modified shell v1 with bcfg that finally allowed me to add a GRUB entry manually, and set it to default. Phew! Now I just hope nothing ever touches the EFI variables of that thing again (or else get an UEFI-induced kernel panic).
And that's just two of the firmwares I've had trouble with. I'll add my experiences with some of the others a bit later. In the mean while, does anyone else have firmware-related stories to share?
With deleting even valid entries, I can see another kind of insane troll logic at work: "Bah, nobody uses anything else than Windows anyway, and it overwrites the last bootloader when new versions are installed, so we can safely delete everything but the Windows bootloader option!" Except that it defeats the purpose of such an option in the first place!
Comment