Updated: October 11, 2017
If there's one person who will push their hardware to the limit, it's me. In early 2015, I purchased a Lenovo Ideapad G50-70 machine, which I've wholly dedicated to software testing, including many a Linux distro. Fast forward two and a half years, things have changed.
So what happened? The way I always do, I downloaded a fresh distro ISO, wrote it onto a thumb drive and then cycled the laptop, so it would boot from the external device. Only this did not happen. The device wasn't recognized. What. Me no likely. Thinking there was a problem with a particular version of Etcher, the software of choice for the data writing task, I tried an older version of the program, with the same result. Tried a different thumb drive. Nope. Tried three different distributions, two of which are actually installed on the box, nothing.
The plot thickens. I cannot recall the full sequence of thoughts and ideas that transpired, but I decided to focus on the software side of things first, before doing any further hardware-related troubleshooting.
At the moment, the distro in control of the complex multi-boot setup that I have on the machine is openSUSE Leap 42.3. I recalled that, during the installation, it actually asked me if I wanted to enable Secure Boot support, and if this could perhaps be the reason why the system is refusing any new boot devices. That does not really sound like it, because there are other distros with valid, signed images, but still. I changed the setting, rebooted, nothing.
All right, well, I decided to actually set up Kubuntu Zesty as the distro in charge of the laptop's multi-boot environment, just to make sure it is not openSUSE that is wonking the whole deal. I already had a feeling it would not help, but you must work slowly and patiently, so that you do not miss anything. Right. Now, as I've already shown you in my GRUB & EFI recovery tutorial, there are many ways you can go about restoring the bootloader, and then, while doing it, I saw this:
Installing for x86_64-efi platform.
Could not delete variable: Interrupted system call
Could not add entry to BootOrder: Interrupted system call
Installation finished. No error reported.
Not good. I also tried using the efibootmgr directly, and got the same error message. At this point, I went online, and found a few references to this issue. Strangely, or not, a bunch of openSUSE users were complaining about this very same thing, and how they were unable to make changes to their UEFI setup, resulting in similar frustration to mine. But not exclusively. Arch, Debian, Fedora, you name it.
I decided to troubleshoot and tried to make changes to the boot manager in a variety of different ways. I tried efibootmgr, I tried bcdedit through Windows 10. Even there, I got a similar error:
bcdedit.exe /import newbcd /clean
The store import operation has failed.
The request was aborted.
I then tried to make any which change in the UEFI menu, to see if that would make any difference. Predictably, no matter what I did, the change would not stick after the reboot. It looked like the NVRAM had gone read only.
Next steps ... and nope
Well, I tried a few minor hardware tricks - remove the battery, hold the power button pressed, those types of innocent games. I also tried to re-flash UEFI, unfortunately the BIOS versions matched, and the Lenovo utility would not let me do that. I even contacted their support, asking for additional diagnostic tools that I might use, but all they did was provide KB articles that are already public and download links to stuff you can get yourself.
I managed to find an older version of the BIOS tool - even though it was tricky business searching for that, but again, the utility refused to flash a version that's older than the current one. I haven't found a way to force the process. It's a no go.
So at the moment, I have a fully functional laptop with a fixed configuration. This means that I cannot use it for new distro testing - I can use it for in-vivo upgrade tests, and of course, a range of software-related tutorials and topics. Actually, I can, but this is a topic for a separate article, and it's quite dangerous. More about that later. Anyway, the setup remains as it currently is, and it includes, in the partition order:
- Windows 10 Home (/dev/sda5)
- Xubuntu 17.04 Zesty Zorba (/dev/sda6)
- Ubuntu 16.04 Xenial Xerus (/dev/sda7)
- CentOS 7.2 KDE (/dev/sda8)
- Manjaro 17.0.1 Gellivara Xfce (/dev/sda9)
- OpenSUSE Leap 42.3 Plasma (/dev/sda13)
- Kubuntu 17.04 Zesty Zeus (/dev/sda14)
- Fedora 25 Workstation Gnome (/dev/sda15)
So I have a very interesting eight-boot setup. Not something most people will ever do or configure. And I've probably installed about 200-300 distro instances over the past two and a half years. Add to that occasional bootloader updates, bootloader order changes, plus the fact data is flashed into NVRAM in multiple chunks, each of which introduces tear to the little strip of memory. We're talking roughly a thousand flashes or more. So I've probably worn the semi-conductor band naked, and there are no more electrons left.
Most techies (ordinary folk just use whatever is there) will probably submit their laptops, over their typical lifetime of about three to five years, to a tiny handful of installations. Not more than ten. I have exceeded this number by about two orders of magnitude. We're talking 300-500 laptop years of UEFI abuse, and that's the likely reason for this little fiasco.
This also means - for the time being - until I decide whether to buy a fresh new test machine, I will be performing new distro testing on my older LG RD510 machine, as you've already seen with Antergos and some others. It's only going to be dual boot with an aging processor, but maybe slightly more interesting due to the performance constraints and the presence of an Nvidia card. I will still do all the cool bits and pieces. No UEFI and probably no hardware problems with the network. But I shall endeavor to give you thorough, detailed and honest reviews. Also I am sure going to buy some new hardware, and then we will be back to pain and bugs and drama.
One other thing - my writing queue is very long. We're talking about three months worth of articles already written. Some of them have been completed while the little G50 was working well, so bear that in mind. It should be interesting. And fun.
While writing this article, I had a thought. Maybe, if one is conducting a copious amount of testing with lots of firmware flashing, using the Legacy mode might be helpful. It means no UEFI mode, but perhaps that's not that bad. In general, the whole flashy thingie also applies to routers. Every time you change a config, a cell dies. Remember that. Anyway, G50 becomes a special test case, and the oldster LG returns with a bang. Until a worthy successor to the throne is found. Tux Vivat!
Now, on a very serious note, I am asking YOU if you have any ideas what to do next. I am not keen on dismembering the laptop. There might not even be a CMOS battery. And any vigorous laptop change could lead to a bricked device. So, if you have any suggestions, and please do not search online, I've done that piece, if you really have proper personal technical savvy and expertise, do email me, and let me know your thoughts and tricks, preferably non-destructive. The idea is to try to revive the NVRAM without killing the laptop. Express yourselves.