Installation workaround for read-only BIOS - GRUB2 ISO boot

Updated: May 4, 2018

Several months ago, I finally managed to resolve the read-only saga on my Lenovo G50 laptop. You can read about the original problem and then my first workaround attempt, and then finally, once the problem really became popular due to the Ubuntu 17.10 drivers fiasco, the real solution came about in the form of a kernel update, and henceforth, I had my UEFI working properly again. The funny thing is, this is a much bigger issue, and not restricted to Ubuntu, but it was casually ignored for a long while.

Now, while I was waiting for the fix to be created - not knowing if there ever was going to be one, I tried to find ways to get new operating systems to boot on the Lenovo machine. As I mentioned, raw disk access via VirtualBox is one. Another method, somewhat less risky but also somewhat less effective is: GRUB2 ISOBoot. We shall discuss that now, for there could come a day when you might face (or still are) the BIOS/UEFI NVRAM read-only issue, and need a way to work around that, and no kernel updates and such available. Let us proceed.

Boot up

The ability to boot directly from ISO files is a new feature of the GRUB2 bootloader, and we will now exploit it to get around the fact we cannot actually use removable media on the laptop. The documentation on the use of this capability is somewhat scarce, and as always and rather rightly, biased toward Ubuntu, which makes sense, as it is the most prevalent Linux distribution out there. Still.

Anyway, first, please read my GRUB2 tutorial to get familiar with the bootloader and how it works. Without that knowledge, you will not be able to implement the suggestions written in this article.

Manual menu entry

I believe in testing things first before automating or using helper tools, because this way, you will be able to understand what's happening. behind the scenes. The basic idea is as follows - you need to create a custom GRUB2 script - or you can use a pre-existing template, point it to the relevant ISO file on one of the partitions on the disk, mount the ISO as a loopback device, and then boot the available kernel and initrd/initramfs file.

We will use the 40_custom script, which is available under /etc/grub.d. By default, the file is empty and only lists the following:

exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.

Let's now create an entry and see what gives:

exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.
# Simply type the menu entries you want to add after this
# comment. Be careful not to change the 'exec tail' line above.

menuentry "<title>" {
set root=(<disk>,<partition>)
set isoname="<iso file name>"
set isofile="<path>${isoname}.iso"
loopback loop $isofile
linux (loop)<vmlinuz> <boot options>
initrd (loop)<initrd>

What do we have here?

Let's take a look at our script, shall we?

The problem ...

The issue with this approach is that pretty much every distro out there uses its own method to boot into the live session, including overlay filesystem, boot options, and more. There isn't a single and simple way to just boot any which generic entry. Again, if you look at the available examples, you will see the huge amount of differences and fragmentation in this space - like any other aspect of the Linux desktop.

Fedora test

I decided to test with Fedora, because the Ubuntu example is really trivial. Reading online, I found at least a dozen references across the F18-F27 family, each one listed ever so slightly differently. The common convention narrows down to, more or less:

menuentry "Fedora Live" --class fedora {
set root='hd0,msdos8'
set isofile="/home/roger/Downloads/
loopback loop $isofile
linux (loop)/isolinux/vmlinuz0 iso-scan/filename=${isofile}
root=live:CDLABEL=Fedora-Live rootfstype=auto ro
quiet rhgb rd.luks=0
initrd (loop)/isolinux/initrd0.img

I used the latest Fedora 27 example and a dual-boot system with the ISO file located on the eighth partition (sda8). Once you add this to the custom script, the next step is to update the GRUB menu. Then check and verify that the created GRUB configuration file indeed contains your entry.

Testing this did not work - nor any dozen other variations. I also used UUID instead of the disk and partition notation, tried inserting various modules, and none of these allowed for a simple and seamless boot of a non-Ubuntu ISO file.

Non-manual method: grml

A much easier approach is to use a helper tool that will automatically add an entry for any ISO file found under /boot/grml. Install the program - sudo apt-get install grml, copy the relevant ISO files, and then run the GRUB update command.

Grml tool

With this method, I had mixed results - some distributions would boot, others would not. Looking at the generated grub.cfg file, again, there does not seem to be a common, simple convention on what the output should look like. Arguably, while safer than using the raw disk access in VirtualBox, as I've shown you in my first article on this topic, the ISOBoot method is less likely to work in all cases.

Other workarounds

Not strictly related to GRUB2 ISOBoot, but there are a few other tools that you may want to consider. Some of these tools are suggestions from my readers, and I want to thank them for their genuine help and contributions, as they tried to assist me in fixing my laptop.

The official Lenovo recommendation is to have the motherboard replaced. This will work, and you might want to attempt that - but only after depleting all software-based solutions. They are cheaper, and you can always fall back to hardware. And as we have seen, a kernel update did help, so it would have been a waste of money going for a motherboard replacement just yet (that's always an option, and so should be the last).

Another (somewhat highly expert) hardware suggestion is to try to flash a clean UEFI image directly onto the laptop's chip, using a USB SPI programmer supported by a flashrom tool. I have not tried this, but this is something you may want to consider, if you're ultra-bold and savvy.

A sub-lesson of this story is that it is good to wait. In my case, I patiently waited for about four months. I did not rush out spending money on hardware repairs, or buying a new laptop. However, I do understand that in some situations, you might be without a choice.

Other options, in descending order of priority ought to be: 1) BIOS/UEFI firmware flash if available 2) The use of the rEFInd boot manager, as a replacement to GRUB; with a little bit of hacking (something that we may explore one day in greater detail), you might be able to successfully work around the existing limitations imposed by the read-only BIOS/UEFI 3) Several other UEFI management programs like EasyUEFI 4) a prayer book, which for most geeks will be a Python manual.

Let's discuss the second-to-last point in a bit more detail. This is a Windows-based program, and it can be used to manage the EFI bootloader, including enabling/disabling entries, changing the order of listed entries, and cleaning up disabled items.

EasyUEFI, main menu

EasyUEFI cleanup

This cleanup command is what might help you get your NVRAM to cooperate (maybe). In the main menu, try to disable one of the entries, or if you already have some in the disabled state, then you can try the cleanup option. In my case, this did not work. The tool threw a system API error, which is probably not that different from the interrupted system call issue we saw in my initial report on the problem. Don't get your hopes too high, but it might work for you better than it did for me.

EasyUEFI, system API error

I would like to thank aigle, Ivan, L., Neal, Marcin, Richard, Nik, Floris, zloster, Georg, and Matthew for their suggestions, ideas, encouragement through the adventure. Since the problem has been resolved, I won't be able to continue any additional tools or ways to resolve the issue, and with what you have above, plus the kernel update, plus the VirtualBox raw disk access, you should be okay.


When you're facing an odd hardware situation, like we have here, there are no guarantees. In the first workaround article, I mentioned VirtualBox and raw disk access. This is bound to work, but the risks are quite high. A less intrusive method is to try to boot from ISO files using GRUB2, our topic today. My testing shows this is a much less successful and effective way, but it also carries less risk of damaging the data on the hard disk. Lastly, you could try some other tools, and we will explore some of those more in the future.

For the time being, my suggestion is - if the kernel update does not work for you AND you do not really have to change the current setup AND it works for you well - let it be. For me, this was the matter of using eight operating systems, more than plenty for a test box, and I could still perform in-vivo upgrades, so it was all right waiting for the kernel fix. If you do want to try to be able to use additional operating systems without making any hardware repairs, then you have several workaround solutions and semi-solutions to consider. I wish I could give you a 100% foolproof 100% applicable recipe, but that is never the case in a war between software and hardware. Take care.