The trouble with UEFI Boot, and a helping hand from a BIOS firmware update

The trouble with UEFI Boot, and a helping hand from a BIOS firmware update

Summary: Sometimes a firmware update can be the answer to a tricky problem — but alas, not always.


I have written a number of times recently about UEFI Boot, and how much trouble I have had getting it set up and getting it to stay the way I want it. 

It is important to remember that system manufacturers sometimes make BIOS firmware updates available, and installing such updates can sometimes be of significant help with existing problems.

An example is my Acer Aspire One 725. I have installed several different Linux distributions on it (openSuSE, Fedora, Ubuntu and Debian), and I had run into two related problems. 

First, when the Linux installation was finished the system still only booted Windows, and second, even when I changed the UEFI Boot parameters in NVRAM (using efibootmgr), the changes would be lost on the next reboot (which was actually the root cause of the first problem). 

How I installed Fedora 18 with UEFI Secure Boot

How I installed Fedora 18 with UEFI Secure Boot

How I installed Fedora 18 with UEFI Secure Boot

I noticed not long ago that a BIOS firmware update was available from Acer for this system, so I downloaded and installed that. The first thing that I saw on rebooting was that the BIOS setup menus had been modified, and there was a new option to change the boot targets and sequence. 

A bit of investigation and experimentation with that led me to discover that now I am able to make some changes which stick. It's not completely configurable in the way I would like it to be, but I can define any one of my Linux installations as the default boot target, and as long as I then define Windows Boot Manager as the last boot target, it all sticks. 

Don't ask me why Windows has to be last (although I will say that seems fitting to me), but I found that no matter what else I did, Windows had to be first or last or else the entire configuration would get overwritten with some kind of default setup.

The other case is not so nice. I had basically the same problems on my HP Pavilion dm1-5310ez, I couldn't get any changes to the UEFI Boot configuration to survive across a reboot. 

Today I saw that there was also a BIOS firmware update available for that system, so I downloaded and installed it with high hopes. Unfortunately, those hopes were dashed on the cruel rocks of reality. I am still not able to make any permanent changes to the UEFI Boot configuration.

So, the moral of the story is that if you are struggling with UEFI boot, it might be worth your while to check for BIOS updates from time to time. 

Of course, even when updates are available they might not solve the problem you are struggling with, but at the least you are not likely to end up any worse off than you were before.

Topics: Operating Systems, Linux

J.A. Watson

About J.A. Watson

I started working with what we called "analog computers" in aircraft maintenance with the United States Air Force in 1970. After finishing military service and returning to university, I was introduced to microprocessors and machine language programming on Intel 4040 processors. After that I also worked on, operated and programmed Digital Equipment Corporation PDP-8, PDP-11 (/45 and /70) and VAX minicomputers. I was involved with the first wave of Unix-based microcomputers, in the early '80s. I have been working in software development, operation, installation and support since then.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Yep It's hardly surprising Microsoft took to this

    Everything they touch becomes a complicated hybrid of a mess
    • This is the reason i won't buy any Windows 8 UEFI-machine...

      ...yep ... these machines have totally zero $/€ value in my stock market. Instead the next machine i most likely will buy will be ChromeBook because it's much, much easier to install Ubuntu, Mint, Debian or what ever Linux distribution on it.

      Goodbye Microsoft - we don't need you.
  • This is why Micro$oft needs to be sued

    They don't own the OEM hardware that they monopolistically plant on 90% of all the machines out there. We do.

    Let's hope there is a United States vs. Micro$oft, Part II because they clearly haven't learned their lesson.
    • What?

      UEFI has nothing much to do with Microsoft. They're on the UEFI committee, but then, so is the entire tech industry.

      UEFI is not some sort of Microsoft conspiracy, it's just your regular tech industry screw-up by committee.
      • UEFI has EVERYTHING to do with Microsoft

        UEFI Secure Boot means that the hardware will look for the presence of a Microsoft key in the boot file. If the Microsoft key is not present, the hardware will refuse to boot the software.

        ONLY Microsoft supplies these keys.

        It may be your hardware, but you are only allowed to use it for Microsoft's software.
        • Nope.

          Nope. No cigar for you.

          One, I said "UEFI", not "UEFI Secure Boot". I know zdnet readers, confused by SJVN's early efforts, persist in believing they are the same thing, but they are not. UEFI is an industry-wide effort to replace BIOS as the firmware standard for PCs (and other devices). Secure Boot is one element of the UEFI spec, introduced at v1.2, which is effectively optional. They are not the same thing.

          Two, SB does not mean that, though you're not too far off a reasonable simplification. SB is a mechanism for doing cryptographic validation of the boot chain. The Secure Boot spec itself says absolutely nothing about any particular key; Microsoft's or anyone else's. It just describes a mechanism by which a firmware can cryptographically verify the integrity of a boot chain.

          It is Microsoft's OEM licensing requirements that introduce the requirements you (slightly incorrectly) summarize: they only apply to system builders who want to get OEM Windows (8) licenses. A more correct summary of the requirements is that systems must trust Microsoft's SB key (but not *exclusively*: the requirements do not in any way restrict vendors from trusting any *other* keys), must ship with SB enabled, but must provide a mechanism for turning SB off entirely and also a mechanism for entering 'Setup Mode', which is a mode that allows you to enrol your own verification keys.

          Seriously, Microsoft's Secure Boot stuff is mostly unobjectionable (there are a couple of unfortunate consequences, but this post is already too long). And MS' SB requirements per se are actually not turning out to be much of a problem at all: the requirement that you be able to disable SB is a pretty clear and unambiguous one, and indeed, I've yet to hear of a production system that doesn't allow it.

          No, what's turning out to be more of a problem is the *rest* of the UEFI spec, and the problem there is, as I said, not conspiracy but cock-up. It's rather like the ACPI spec: it's huge, but it _still_ doesn't cover everything, and vendors are managing to come up with some incredibly wacky interpretations of things. So you can have ten different UEFI spec-compliant firmwares which all behave extremely differently and all cause some different problem for people who want to boot something other than whatever OS came pre-installed.

          Oh, and if you really want to bitch about a Microsoft requirement, bitch about this one:

          Because it's causing us a lot more trouble than Secure Boot is.
      • What @trentreviso said

        M$ was pushing for UEFI and their OEM slaves went along with it like a bunch of PEZ.

        Gotta preserve those volume license discounts ya know...

        • At least...

          Until someone in the Linux community understands it enough to enable secure boot Linux. Gotta secure those free licenses that you can't hand away.
  • or not

    "Of course, even when updates are available they might not solve the problem you are struggling with, but at the least you are not likely to end up any worse off than you were before."

    Or, well, sometimes you are, because firmware engineers come from the pool of candidates who couldn't quite master Visual Basic.

    Manufacturers usually post a warning like 'don't install a firmware update if you're not having any problems', and this is usually good advice, because sometimes they _do_ screw up. The case where you have a problem but the firmware update changelog doesn't claim to do anything about it is pretty much a 50/50 toss-up.

    It doesn't sound like the problem you have is NVRAM exhaustion, but on the offchance it is, there's a better strategy for dealing with NVRAM exhaustion going into the kernel at present: mjg59 has all the details at . The change should be in F19 Final TC2, I don't know when other distros plan to merge it.
    • Changelogs are frequently "lacking"

      Hi Adam,

      Thanks for your comments, as always.

      There is a huge swamp surrounding the state of UEFI firmware at the moment. One of the nicest ways to phrase it is that most UEFI implementations are still "in flux". That means there are generally not bug reports which say "our UEFI BIOS suck", nor are there changelog entries which say "fixed our UEFI BIOS so it isn't quite so insane". But the fact is that both of those statements are true to varying degrees about most UEFI systems today; my Aspire One 725 is a good example, as I have said in previous posts it was doing strange things with the UEFI boot list, and the latest firmware upgrade made it a lot more stable and predictable - but the only text file included with it says "Execute ZGH212.EXE". (I am NOT making that up)

      So my position generally differs from yours a bit on this. I consider UEFI BIOS implementations to still be in active development right now, so for my UEFI systems I generally install firmware updates whenever I see they are available. For my non-UEFI systems I absolutely agree with you, I don't install firmware updates unless I have a specific issue, and I know from some reliable source that a firmware update is likely to help with that problem.

      Thanks for reading and commenting.

  • Watch the UEFI version

    Machines that had a version of UEFI less than 2.3.1 are a real pain. I consider UEFI 2.3.1 to be the first truly usable version; for prior versions stick to the BIOS emulation (CSM module).

    Of course you'll see the "Windows 8 certified" stickers on most UEFI 2.3.1 systems (as that's the minimum UEFI version required for Windows 8 logo certification), but I'm sure that won't cause any seizures :-)
    • Shouldn't have to do that

      I bought the machine with my own money. I should have the freedom to put on there whatever I want to without these encumbrances.

      Let's hope the courts decide this. AGAIN.
      • What?

        This post has nothing to do with 'freedom' or 'encumbrances'. It's about _bugs_. Every day, garden variety bugs, of the kind which each firmware engineer is required to write a minimum of ten daily. Please, remove the short circuit in your brain that goes from UEFI to MICROSOFT IS TEH EVILS and actually learn something.
        • Easy fix.

          Just use Linux (only). Why would I want to go back to AV, infections, and de-fragging my hard drive and dealing with proprietary COA's, WGA's and the like. To any Linux user, Windows is pure nonsense and a black hole of wasted time and effort.

          Disable it completely and install Linux Mint 15 Cinnamon, preferably 64-bit on a 2 or 4 core machine. Aggravation is now gone.
          • Why do you have to be an engineer to install an OS?

            It's silly, Linux Mint installs in about 12 minutes with a password and a couple of clicks. All drivers are connected and it's ready to use. Updates handle OS and software updates by just entering your system password.
          • No argument -- Windows orchestrated UEFI...

            .... to thwart Linux promulgation.

            Windows and MS was never interested in true security. Apparently there are hacks to their boot system already, bringing botnets and rootkits to the forefront again, even with all this fuss.

            Linux does not need UEFI, It's useless on an intrinsically secure OS. I've never needed it. I have been running Linux for 12 years without ever using any AV.
          • It's a pure joy to eliminate all AV and it's maintenance.

            It really allows the computer to do what it was designed to do.

            I recently scanned a friends laptop hard drive with CLAMAV and the CLAMTK GUI and found 3,094 Windows infections.

  • Firmware Updates May Reset to Defaults

    One other word of caution is in order here, in addition to Adam's good observations above. Keep in mind that updating the BIOS firmware might also cause a "reset to default" of the BIOS configuration setting. In my case, while researching an answer above I found that Acer had released another BIOS update for the AO725. When I installed that, it reset the "F12 Boot Select" setting and rewrote the UEFI boot target list to put Windows 8 first. That wasn't too hard to fix, and on the positive side it also added a new options which appears to allow me to manually designate Secure Boot compatible EFI files. I haven't tried that yet, though.