First let me explain my current set up. I recently scrubbed my two main drives and converted them to GUID. On the primary drive (sdb in my case) I have created an EFI boot partition (ESP) on /dev/sdb1. I have other partitions in which I have done a fresh install of mint17.1 which nicely sets itself up to boot via EFI and then GRUB2. So no problem any new installs take care of registering themselves with the efi bootloader in the ESP.

Now only if I clearly understood that process! Several hours of UEFI reading later and I still don't have a simple clear picture of the procedure and how to do that manually on my own and what are the best tools to use?? I've been inspired by posts with titles like "UEFI/Grub2: Story of my Nightmare".

So Question:

On my second drive's first partition (sda1) I have restored a copy of a mint17(ubuntu14.04) install before I started down this path. It was set up to boot legacy. How do I convert it to boot via EFI and register it with the boot loader (folder in ESP with .efi)?

Having a working install on another partition means I can make whatever changes I need to without need of booting from a USB stick.

Here is what I think is about the most helpful posts I could find to what I want to do


How to reinstall GRUB2 EFI?

The best help would be a step by step procedure. My best general notion of how to do this is to edit fstab to load the efi partition, copy a(the) kernal file over, chroot? to the partition(OS) in question and run grub2 to get it to do it's thing with the EFI folder? It will be fun to hear how lost I am. :).

A good complete answer will be VERY useful to the community because although I now know a lot about UEFI booting the "secret" still seems to be how to use tools to manipulate it. I can't be the only unsure one can I?

Secondly while I am asking, how does one change the entry names in the EFI boot menu. I thought maybe it would be as easy as changing the directory name wihin the EFI directory in the ESP but...no. So there must be some tool to manipulate those .efi files which I assume contain the name of the OS to boot that is used in the EFI menu?

BTW I did make a small partition (1gb) for use as a Grub chainloader. Is that a better solution? I don't mind the EFI for multiboot and I have already loaded refind for a menu if I want one. Here was post that made me consider this and build in a partition in case I wanted to try it. http://devil-detail.blogspot.com/2013/07/install-grub2-on-gpt-disk-dedicated-partition.html

Yup the Devil is in the Details (some help with that please)

  • don't know who down voted my question but this is a good question not clearly answered with practical details anywhere even by Rod. Below I have answered my own question with those details after much pain and time so if you find this post useful please upvote my question and answer. – DKebler Nov 13 '15 at 17:33

First, some basics....

There are two critical classes of programs involved in booting a computer, under either BIOS or EFI:

  • The boot manager -- This program presents a menu or otherwise enables the user to select which OS to boot.
  • The boot loader -- This program loads an OS kernel into memory and starts it running.

Some programs, including GRUB and most other Linux boot loaders you may have heard of under BIOS, actually perform both functions. Thus, Linux users tend to be a little linguistically sloppy and use "boot loader" when referring to either type of program. Understanding the distinction, though, is important for EFI because some EFI programs fulfill just one function but not the other. Furthermore, EFI provides a built-in boot manager. Unfortunately, the EFI specification is mute on the subject of what sort of user interface the built-in boot manager should provide. The result is that it's almost useless on some machines, awkward on others, and barely tolerable on the best of them.

The built-in EFI boot manager can be controlled from an OS by editing EFI variables. In Linux, this task is handled by the efibootmgr utility, which is a typical bare-bones Linux command-line tool. As such, it's not really very user-friendly. When you boot the computer, you typically access the boot manager by pressing Esc or a function key, but details vary from one machine to another.

Shifting gears a bit, GRUB is designed to work in much the same way for both BIOS and EFI systems. Under BIOS, GRUB installs part of itself to the Master Boot Record (MBR), which is the first sector on the hard disk. BIOS is hard-coded to execute code in the MBR, so GRUB takes control of the computer when it boots, presents a menu, and loads a kernel or redirects the boot process to another boot loader stored elsewhere. Under EFI, the process is a bit different: GRUB registers itself with the EFI's NVRAM (at install time via efibootmgr, even if you didn't type the command yourself). The EFI's boot manager then launches GRUB, which presents a menu and launches a kernel or redirects to another boot loader.

Another key difference between BIOS and EFI is that BIOS boot loaders are stored, in whole or in part, in the MBR and other "hidden" parts of the disk. EFI boot loaders and boot managers (aside from the built-in boot manager) are stored as ordinary files on the ESP. This makes EFI a little easier to manage -- at least in theory and once you understand it.

Now, all this theory out of the way, I can more directly address your question: The bulk of Linux doesn't care about the boot mode, so converting an existing BIOS-mode install to boot in EFI mode requires installing an EFI boot loader for Linux. There are in fact several such programs available. You've alluded, directly or indirectly, to two of them, but there are others:

  • GRUB 2 -- This is the default of most distributions and so is usually easy to get working on a fresh installation. OTOH, it's rather arcane and difficult to get working manually. Under both BIOS and EFI, it can read kernels from just about anywhere.
  • GRUB Legacy -- This boot loader doesn't officially work under EFI, but Fedora released a heavily-patched version that did. This variant is no longer being maintained. Like GRUB 2, it can load kernels from most Linux filesystems.
  • ELILO -- This boot loader is modeled after the LILO boot loader for BIOS. It's easy to configure if you're used to LILO. It requires that your kernels be stored on the ESP. It's no longer being actively developed, but it still gets the job done.
  • SYSLINUX -- This boot loader is similar in broad strokes to ELILO, and is related to a BIOS boot loader of the same name. Like ELILO, it requires your kernel be stored on the ESP.
  • The EFI stub loader -- The Linux kernel itself includes an EFI boot loader, so you can boot your system using nothing but the EFI's built-in boot manager and a kernel registered directly to it. Launching the kernel directly from the EFI's boot manager in this way therefore requires that the kernel be stored on the ESP (or at least on a FAT partition, or sometimes HFS+ on Macs). One of the posts to which you linked was about such a configuration, but that type of setup is uncommon and is not something I recommend because it's inflexible.

In addition to these boot loaders, there are a few dedicated EFI boot managers that can help expand your options:

  • gummiboot -- This program is a simple text-mode boot manager that can launch any of the preceding boot loaders, including a Linux kernel; however, it can only redirect the boot process to a program stored on its own partition, which is normally the ESP. Thus, to use gummiboot to launch a kernel directly (via the EFI stub support) requires your kernel to be stored on the ESP.
  • rEFIt -- This program originated on the Mac, and remains popular on that platform, although rEFIt has been abandoned for years. It can redirect the boot process to any partition that the EFI can read, and rEFIt includes a couple of EFI drivers enabling the EFI to read ext2/3fs or ReiserFS volumes. Unusually, rEFIt actively scans for boot loaders when it starts, which makes it very adaptable in a multi-boot environment. It's not very good at launching Linux kernels, though, because rEFIt can't pass the kernels the custom options that they usually require to work well.
  • rEFInd -- This is my own fork of rEFIt. It adds drivers for ext4fs, Btrfs, NTFS, HFS+, and ISO-9660; and it enables passing options to Linux kernels. Therefore, the combination of rEFInd with the EFI stub loader provides most of the flexibility of GRUB in terms of kernel locations. rEFInd also retains rEFIt's active scanning for boot options, which can greatly reduce the hair-pulling involved in maintaining a system with multiple Linux distributions installed; when you install (or delete) a new kernel in any distribution, rEFInd picks up the change the next time you boot.

It's a little unclear to me what your current setup is, but the impression I get is that you've got at least two Linux installations, including at least one that formerly booted in BIOS mode. If so, you might want to consider using rEFInd. If it's installed as your default boot program, it will actively scan your system for kernels and create a menu at every boot. You'll need to install EFI filesystem drivers for the filesystem(s) that hold your kernels, but the install script may take care of this detail for you. You may also need to create configuration files called /boot/refind_linux.conf for each distribution; this file holds static boot options. (This is sometimes unnecessary, though; it depends on your partition layout and distribution-specific needs.) If you install rEFInd using its installation script under Linux, refind_linux.conf will be created automatically for that distribution, but you may need to create its equivalent for your other distribution(s). The rEFInd documentation includes a page on booting Linux that can help you do all of this.

If you don't want to use rEFInd, you should be able to get one distribution's GRUB to pick up the other installations' kernels. If you can boot one distribution via GRUB, running update-grub (on Ubuntu or similar distributions) or grub-mkconfig -o /boot/grub/grub.cfg should do the job. (You may need to change that output path, though; grub.cfg may be stored elsewhere on some distributions.) The trouble is that if and when you update the kernel on this second distribution, you'll need to boot into the first and rebuild the GRUB configuration file to get GRUB to recognize the new kernel. The alternative is to install GRUB twice, once for each distribution. You could then use the EFI's boot manager to pick which GRUB to launch, or configure each GRUB with an entry to the other one.

As you can see, you have a lot of options. For yet more information on this topic, see my Web page on EFI boot loaders for Linux.

I realize this isn't the step-by-step procedure you wanted, but the combination of an understanding of how things work and knowledge of your own precise setup usually works better than any sort of "cookbook" procedure, especially when the procedures are so dependent upon the details of the configuration going into the process.

  • Rod, your site is one I had already spent a few hours reading. Thx. I had already installed rEFInd! So I am please your chose to help me out. Ok so now I understand it will automatically find kernals and add them to the menu. Now to the nightmare. I see the copy – DKebler Mar 21 '15 at 18:36

After a little more persistence I have come up a step by step workable solution for migrating from BIOS-Legacy to EFI bboting so I'll answer my own question now.

This applies only to booting multiple copies of unbuntu (or some flavour) and assumes you are starting from scratch with a new or repurposed drive and that your motherboard is fairly new (mine is 2014 vintage). If you are moving your current bios/mbr install rather than doing a new install I suggest making a partition image with fsarchiver using qt-fsarchiver. This assumes your current install of linux is UEFI capable. The latests releases of ubunutu (and flavors) are UEFI capable.

With my step by step I now have mirrored and testing copies of my primary os installed on the same machine all loadable from refind!

Step by Step

  • Create a persistent UEFI USB stick with some flavor of linux (see notes below)

  • Boot that stick as UEFI which involves entering your cmos settings and being sure your settings will boot UEFI. You should see your USB listed there usually by manufacturer name. It's best to just to turn off any legacy booting option(s) so you are sure. When it boots the first time it will move most of OS files to the casper-rw partition and mount that as the filesystem. If you put anything there before you'll have to look in the /media folder to find it.

  • From the booted stick Using Gparted

    a. Make a new GPT partition table on what will be your primary drive (scrubs the drive!)

    b. Now make partition for ESP, 256mb or more, formatted Fat32, label it ESP. Mark it bootable (it will be marked EFI bootable since it is a GPT drive now)

  • Install rEFInd. http://www.rodsbooks.com/refind/ There are three methods (deb package, script or manual) I suggest downloading the latest bin.zip archive. Unpack that and run the install script from inside the unarchived refind directory.

sudo ./install.sh

It will find and mount your new ESP/EFI parition. If it complains about not running efibootmgr properly you probably need to install it. I did. Then just rerun install script.

sudo apt-get install efibootmgr

Finally ESP/EFI will be still mounted at boot/efi and you'll need to copy the drivers_x64 directory (mine is 64bit machine) found inside zip archive in the refind directory (same relative location).

  • Now remove your stick and try rebooting. Enter the Cmos and see if refind is now one of the available UEFI devices to boot. I made it 2nd after my stick. That way when the stick is in I boot from the stick otherwise from refind on the harddrive ESP.

  • Now you can install an (efi) os on another partition like maybe Mint on the stick you just made. In the /boot directory of this install might contain a refind_linux.conf file which can be customized. I choose just to rename (delete it). It's not necessarily needed and it can cause boot problems if misconfigured. I recommend you choose clear partition labels as refind picks up on those and uses them in the menu. It will avoid having to customize the main refind.conf file which is found in the EFI/refind directory. I chose to only uncomment/change these lines. See Rod's excellent documentation for all things rEFIfind.

    • scan_delay 5
    • timeout 10
    • default_selection "your partition label"


Making a USB Stick

  • Use a 4gb min stick

  • Use gparted to set a GPT table on the stick, make a 2gb partition and format it fat32, label it "boot", set the boot flag (it will be EFI)

  • Partition/format the rest ext4 with a label of "casper-rw".

  • Mount an efi capable iso (I used linux mint 17.1) and the "boot" partition and copy the contents of the iso.

  • edit boot/grub/grub.cfg on the USB stick, edit the first boot stanza and add the option "persistent" like this:

linux /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=${iso_path} quiet splash persistent -- http://shallowsky.com/blog/linux/install/ubuntu-persistent-live-cd.html

While you have that mounted I would probably cut and paste this text along with the url of this post into a text file and save it there as well.

One irritating thing about Mint is that if not on a laptop it will still load the laptop display and thus you can't "see" anything. To Fix this right click a terminal open or use cntrl-alt-t. Then run "cinnamon-settings" go to display settings and turn off the laptop display and make your primary display the default.

Later, once the USB is booted I also install qtfsarchiver so I can restore my fsarchiver archives with a GUI.

If restoring a fsarchiver archive to a partition you will need to ask for a new uuid after restore (in gparted) and to edit the fstab accordingly as well as delete/fix any refind_linux.conf in the /boot directory.

UPDATE: Recovering from missing refind menu

I have come up with an quick restore (assuming you have a good to go USB flash EFI bootable stick at the ready.)

N.B. If you decide to use the refind ppa to keep current I have found every time it updates you'll lose your configuration and thus booting. Thus I suggest only manual upgrades to refind when you are prepared to go through the procedure below.

Fixing lost motherboard NVRAM setting (firmware no longer lists REFIND as bootable choice)

<user> == your current login user

Boot to your USB stick. Make a recovery directory (on the desktop) and open a terminal in it.

  1. mount your efi(esp) partiton (sdxx) at /media//EFI/boot/efi and make a backup copy of efi/esp partition

sudo mount /dev/sdxx /media/<user>/EFI/boot/efi cp -R /media/<user>/EFI/boot/efi efi-copy-xx-xx-201x

  1. Check to see if you have the latest refind bin.zip. If not download (from sourceforge and extract to your refind boot recovery folder

  2. CD into latest refind extracted directory and install (version previous to .10 use just install.sh)

sudo ./refind-install --root /media/<user>/EFI/boot/efi

If it complains about not running efibootmgr properly you probably need to install it. I did. Then just rerun install script.

sudo apt-get install efibootmgr

That should be it. you should now remove the usb flash stick and reboot and your refind boot menu should be back.

  • Hi DKebler, since you seem to have found your answer (which you might accept), could you remove your other "answer" (which looks like a comment/supplement) since the answer section is intended for answers only. – bummi Apr 20 '15 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.