Disclaimer: This worked for me, with my hardware (Lenovo G580) and my setup. It doesn't mean it'll work for you, but if it does, great! I've written this from memory, so let me know if I've missed any steps.

Credit where it's due, some of these instructions come from the Ubuntu community and help pages.

Step 1: Prepare hard drive. For me, this was just a case of shrinking my windows partition from within Windows disk management to ensure I had some space to install Mint.

Step 2: Download the latest Mint iso. Note that it has to be a 64bit version to work with EFI.

Step 3: Burn the iso to a USB stick. There are loads of tools to do it, but the one I used when it worked for me was PenDriveLinux. Choose to format during the process, this ensures it goes on as Fat32.

Step 4: Reboot the PC and go into the BIOS/setup. The button to do this varies between manufacturers, for me it was F2. Once in the setup, find the BIOS option which should currently say UEFI, and change it to BIOS/Legacy Support. Not all motherboards support this, if yours doesn't, the rest of this how-to won't work for you, sorry.

While you're in the setup, disable Secure Boot if you can. For me, and other Lenovo owners, you may find you have to set an Admin password before the option becomes available.

Change the boot order in your setup to ensure it boots from USB before Hard Drive.

Save and exit the BIOS/setup.

Step 5: If you're still with me, and it's worked so far, you should find your computer booting into Mint from the USB stick. Choose to boot into Mint from the main menu.

Step 6: Once Mint loads to the desktop, double click the 'Install Mint' link on the desktop. There are loads of guides out there (and on here) for installing Mint, so I won't go into too much detail here, but for reference, I chose the following options.

From the install options, choose 'something else'.

I chose the Free space from the list of partitions, then 'Add'ed a 4GB Swap partition, and finally used the rest of the free space as a / partition.

Completed the rest of the install as normal.

Step 7: Reboot. Remove the USB stick and the Grub menu should load, choose to boot into Mint.

Providing this works up to this point, you now have a working install (in BIOS mode), and a working Windows 8 install (EFI mode). Now we need to convert the BIOS install to an EFI one so we can just keep the computer in EFI mode and not have to swap between them.

Step 8: We need to install boot-repair now. Ensure you're connected to the internet and then open a terminal and type the following commands:

Step 11: Click 'Apply' in boot-repair. It takes a while to complete the process, and partway through will give you some commands to remove and re-install GRUB. Follow the instructions to the letter until the process completes.

Step 12: Reboot, go back into the bios and change the bios mode back to UEFI. Save and exit and you should now find yourself with a GRUB menu within EFI. Both the Mint and Windows options should work.

Well, if you made it this far, and were as lucky as me, you should now have a working Mint EFI install to go along with the Windows one. No need to go changing the bios mode every time you want to boot into a different OS.

If you have any questions, please ask away, but bear in mind that I'm new to EFI and new to Mint. I'll answer as best I can

All I've got left to do now is install something like rEFInd to hopefully replace the very plain grub menu.

rickierich wrote:Ok you do not say if you switch secureboot back on or whether you keep it off and only offer legacy mode. thanks.

Step 12: Reboot, go back into the bios and change the bios mode back to UEFI. Save and exit and you should now find yourself with a GRUB menu within EFI. Both the Mint and Windows options should work.

It's important to distinguish between EFI and Secure Boot, which both of you seem to be conflating. Secure Boot is just one EFI feature, and an optional one at that. To sum up some of the terminology:

Legacy mode or BIOS mode refers to a boot using the old BIOS-style boot methods rather than the new EFI methods.

EFI or UEFI refers to the new firmware and its boot methods, with or without Secure Boot.

Secure Boot refers to the optional UEFI feature in which boot loaders will only launch if they're cryptographically authenticated. Secure Boot can be disabled while the computer continues to boot in EFI mode.

Thus, you can boot in either BIOS/legacy mode or in EFI mode. If you boot in EFI mode, you can boot with or without Secure Boot.

Mint doesn't yet support Secure Boot "out of the box," but it's possible to add it after the fact. See the Dealing with Secure Boot page of my EFI boot loaders Web site for details. This is a bit of a pain to configure, but it can be done.

Thanks for the instructions. I have a question, though. I had already installed Mint from DVD in BIOS mode prior to reading your post, and I'm wondering if I'm already at step 7 in the process, or whether I have to redo my install.

Providing this works up to this point, you now have a working install (in BIOS mode), and a working Windows 8 install (EFI mode). Now we need to convert the BIOS install to an EFI one so we can just keep the computer in EFI mode and not have to swap between them.

This quote implies that I can somehow boot Mint by simply switching to BIOS mode and booting from drive 0 (i.e., that Mint has installed grub in the MBR of my GPT drive). I specifically told Mint not to do that, so grub is only in my root partition, and the only way I can boot into Mint is via a supergrub2 boot CD. So, when you say 'Completed the rest of the install as normal', did you tell Mint to install grub in the MBR? And if so, does that have no effect on EFI windows booting?

Also, I tried copying the Mint install .iso to a flash drive (with unetbootin), and when I did, I was given the option to boot it in EFI mode. I was hoping that booting this way would get Mint to install in EFI mode right away. But booting the flash drive fails - in EFI mode and BIOS mode. In both cases Mint says it can't find a ramdisk on any device and breaks out into an initramfs> menu. Come to think of it, rEFInd (also running from a flash drive) also breaks into an initramfs> menu when I ask it to boot my Mint partition. I assume that means that I have an incomplete 'bootable' EFI setup with missing drivers or something - i.e., I still need to convert from BIOS to EFI. Anyway, does it sound like I'm ready to proceed with the BIOS-to-EFI conversion, or do I have redo my BIOS Mint install prior to converting?

I'm not nearly proficient enough to tell you exactly what you're after there, but I can tell you what worked for me.

I did a bog-standard Mint install, and while I can't remember exactly which options I picked at the point of installing grub, I can tell you I'd have picked whatever the default option was. as EFI mode doesn't use 'normal' bios bootloaders (to the best of my knowledge) then in theory it would make no difference anyway.

Part of the boot-repair process is to install the EFI-capable version of grub anyway, so it being present or not shouldn't make too much difference when it comes to it. The only problem for you by the sounds of it is booting into Mint at all, which is necessary in order to even install and run boot-repair in the first place. I tried installing and running it from the USB live stick I had at first, but it didn't allow me access to make the changes to the HDD, so I had to boot the version installed on the HDD. Someone more knowledgeable than me might know a way to do it from a live dvd/usb, but that's beyond me unfortunately.

Maybe someone out there can help you boot into your Mint install from the initramfs> menu? If so then it's just a case of running the boot-repair process.

littlenoodles wrote:Also, I tried copying the Mint install .iso to a flash drive (with unetbootin), and when I did, I was given the option to boot it in EFI mode. I was hoping that booting this way would get Mint to install in EFI mode right away. But booting the flash drive fails - in EFI mode and BIOS mode. In both cases Mint says it can't find a ramdisk on any device and breaks out into an initramfs> menu. Come to think of it, rEFInd (also running from a flash drive) also breaks into an initramfs> menu when I ask it to boot my Mint partition. I assume that means that I have an incomplete 'bootable' EFI setup with missing drivers or something - i.e., I still need to convert from BIOS to EFI. Anyway, does it sound like I'm ready to proceed with the BIOS-to-EFI conversion, or do I have redo my BIOS Mint install prior to converting?

The initramfs> prompt sounds like you've probably got a missing or improper root= specification on your kernel command line, which is generated by your boot loader and/or boot manager (ELILO, GRUB, or rEFInd). Without knowing precisely how your EFI-mode boot is configured, it's hard to advise about precisely how to fix this; however, many boot managers and boot loaders offer options to edit kernel parameters on a per-boot basis. You can do this in rEFInd by highlighting a boot menu and pressing either F2 or Insert twice, but this will be helpful only if you boot a Linux kernel directly (not booting via GRUB). If you use GRUB, pressing the E key should bring up a similar editor. Of course, you'll need to know what your kernel options should look like. A minimal set of options is something like this:

The partition specifier (/dev/sda5 in this example) needs to be adjusted for your system; it's the identity of your main Mint installation. Depending on the boot loader, you may also need to specify your initial RAM disk file, as in "initrd=initrd.img-3.5.0-17-generic", but my suspicion is that's already present and correct.

If you get the system booted once using this workaround, you can fix your boot loader's or boot manager's configuration to do so on a regular basis, but the details depend on what you're using to launch your kernel. For GRUB, the update-grub script will probably do it. For rEFInd, the mkrlconf.sh script should do it. If those scripts fail, you may need to resort to manual configuration.

I am able to boot my Mint installation - just not from the hard drive or the DVD when copied to flash. I can boot into it by booting the supergrub2 boot CD and letting that grub boot it. Big pain, but it works.

I was surprised that booting the installer from flash would not be able to locate its own ram disk, but hey - my system's firmware is really weird.

But I'm gathering that it doesn't matter how I got my BIOS-booted system installed and booted. The same 'convert from BIOS to EFI booting' instructions would apply. That's a relief. Okay, here goes...

worked - thanks. Now need to dig up the entry on how to bring back the windows boot loader as an option in the EFI boot menu. Or load rEFInd. Or both. In any case, I now have a /sys/firmware/efi entry and /boot/efi mounted, so all the other procedures should be workable. Yay!!!

Oh... one more question. Now that I have an EFI-bootable grub installation, can I add other distros to the grub menu and have grub chainload them without having to go through a similar process to add them to EFI? How about if I were to replace my Linux Mint installation? Is the EFI grub bootloader incomplete without the Mint's /boot/grub directory present?

For what it's worth, rEFInd installed and is working fine too (I had to do the trick of undoing ubuntu's renaming of the windows boot loader, but Rod's instructions on that were easy to follow).

Anyway, it turns out that the Mint grub installer had already recognized and included another distro I had previously loaded (Mageia 2 - 32 bit BIOS mode), and added it to its menu. And yes, the EFI grub loader is able to load it. But the grub menu seems to still live in the Mint partition, so I guess Mint has to stay... (I'm new to Mint, used to run PCLinuxOS, and so far, I like PCLOS better - but i guess I should give mint a chance to win my heart).

littlenoodles wrote:Anyway, it turns out that the Mint grub installer had already recognized and included another distro I had previously loaded (Mageia 2 - 32 bit BIOS mode), and added it to its menu.

It's a little surprising to me that an EFI-mode GRUB can boot a BIOS-mode OS -- I was under the impression that GRUB couldn't do that. Perhaps it's a new feature.

And yes, the EFI grub loader is able to load it. But the grub menu seems to still live in the Mint partition, so I guess Mint has to stay...

You're right; the way Mint configures GRUB ties it to Mint's /boot/grub directory. That's a bug, IMO. You might want to consider setting something else, such as rEFInd, rEFIt, or gummiboot, as the default boot loader for this reason -- it reduces the risk of problems in case the Mint root (/) or /boot partition is damaged or removed. FWIW, rEFInd can both boot Linux 3.3.0 and later kernels directly, without the help of GRUB, so using them can obviate the need to use GRUB. It actually becomes a much simpler setup that way. rEFInd can also boot BIOS-mode boot loaders, but that support is still a bit shaky, so if you've got BIOS-mode OSes, be sure to test that functionality thoroughly.

You're right; the way Mint configures GRUB ties it to Mint's /boot/grub directory. That's a bug, IMO. You might want to consider setting something else, such as rEFInd, rEFIt, or gummiboot, as the default boot loader for this reason -- it reduces the risk of problems in case the Mint root (/) or /boot partition is damaged or removed. FWIW, rEFInd can both boot Linux 3.3.0 and later kernels directly, without the help of GRUB, so using them can obviate the need to use GRUB. It actually becomes a much simpler setup that way. rEFInd can also boot BIOS-mode boot loaders, but that support is still a bit shaky, so if you've got BIOS-mode OSes, be sure to test that functionality thoroughly.

Interesting. I have set up rEFInd as my default boot loader, so I guess maybe I'm halfway there. To boot Mint directly from rEFInd, would I have to copy its kernel (and other files?) into the EFI partition? I guess I could try that under a different name and rEFInd would find it and offer to boot it. That might work better for booting, but I assume if Mint ever upgraded its kernel, I'd have to manually copy the new kernel in too. Maybe better to wait for distros to handle direct EFI booting themselves...

I'm wondering, though. It looks like the EFI/linuxmint directory just contains the grub bootloader. How does it know which partition to get the grub menu from? Or did I just miss a hidden file in there somewhere (I'm not in front of the system to check). Bottom line - do you think I can now boot any BIOS bootable grub-based distro by simply creating a new EFI/<distro> directory and copying the grub bootloader there (along with appropriate info to point to the correct partition)? Or is grub's partition info in VRAM and tricky to set up manually?

littlenoodles wrote:I have set up rEFInd as my default boot loader, so I guess maybe I'm halfway there. To boot Mint directly from rEFInd, would I have to copy its kernel (and other files?) into the EFI partition?

That's one way to do it. Another is to install an EFI filesystem driver for whatever filesystem holds your kernels (normally your root filesystem in Mint, but if you've got a separate /boot partition, it would be the filesystem for that). With that set up, rEFInd can read the Linux kernel from the Linux /boot directory. Then you need a refind_linux.conf file in /boot to hold kernel options. The mkrlconf.sh script that comes with rEFInd can create this file automatically. Thereafter, rEFInd will auto-detect kernel upgrades, so no further reconfiguration is necessary. This is all described in much more detail in the rEFInd documentation, on the page on booting Linux.

I'm wondering, though. It looks like the EFI/linuxmint directory just contains the grub bootloader. How does it know which partition to get the grub menu from?

I think that the information is tucked away inside the grubx64.efi binary, but I'm not 100% positive of that.

Bottom line - do you think I can now boot any BIOS bootable grub-based distro by simply creating a new EFI/<distro> directory and copying the grub bootloader there (along with appropriate info to point to the correct partition)? Or is grub's partition info in VRAM and tricky to set up manually?

Upon further reflection, I think that your EFI-mode GRUB actually is booting your 32-bit distribution in EFI mode. This is one of the capabilities of EFI-mode GRUB -- it can boot Linux cross-bit-depth in a way that most EFI boot loaders can't do. I might be able to tell more if you were to post the grub.cfg file for whatever GRUB is doing this. (Post it as a link or between code tags for legibility, please.) If I'm right, you could have that same GRUB launch additional Linux distributions by creating appropriate boot stanzas and placing them in /etc/grub.d/40_custom. Setting up separate GRUB installations for each distribution would also be possible, but it would require more effort. Note that Linux itself is pretty un-fussy about its boot mode (BIOS or EFI), so you can switch modes just by changing the boot loader, which is what I think has happened to you.

rEFInd can redirect the boot process to BIOS mode, but it requires that that the boot loader have an entry in the NVRAM. This is often the case for the MBR-based boot loader, so if you uncomment rEFInd's "scanfor" line (in refind.conf) and add "hdbios" to the list of options, you should see a new icon for booting a BIOS-based boot loader, which would be installed in the disk's MBR. You'd then configure that boot loader, whatever it is, to boot as many BIOS-based OSes as you like. At the moment this is all a little less direct and reliable than I'd like it to be, but it does work on at least some installations.

I might be able to tell more if you were to post the grub.cfg file for whatever GRUB is doing this

The Upload attachment tool won't let me upload grub.cfg - it complains about the .cfg extension. Tried changing it to grub_cfg.txt and plain grub_cfg, and it still won't let me include it. Any particular section you're interested in seeing? I can copy that in as Code...

By the way, rEFInd put an refind_linux.conf file in Mint's /boot directory. Was that done by the install.sh script or by rEFInd itself when scanning for systems to boot?

I might be able to tell more if you were to post the grub.cfg file for whatever GRUB is doing this

The Upload attachment tool won't let me upload grub.cfg - it complains about the .cfg extension. Tried changing it to grub_cfg.txt and plain grub_cfg, and it still won't let me include it. Any particular section you're interested in seeing? I can copy that in as Code...

It would be whatever section boots the 32-bit Linux you mention.

By the way, rEFInd put an refind_linux.conf file in Mint's /boot directory. Was that done by the install.sh script or by rEFInd itself when scanning for systems to boot?

That's set up by the install.sh script. If it's present, you should be able to boot Linux directly by selecting your distribution's kernel in rEFInd, without involving GRUB. This will only work, though, if you've got a suitable EFI filesystem driver for whatever partition holds your kernel. With a default Mint installation and recent (0.6.0 or later) version of rEFInd, this should be the case, since Mint defaults to ext4fs, for which an EFI driver is available and should be installed by install.sh. If you're not sure if you've got such an option, try using the arrow keys to highlight each of the rEFInd boot options in turn. A direct-boot option will read something like "Boot vmlinuz-3.5.0-17-generic from 200GiB ext4fs volume." The key is the kernel filename -- vmlinuz-3.5.0-17-generic in this example. A boot via GRUB will specify a GRUB filename, such as "Boot EFI\linuxmint\grubx64.efi from 200MiB FAT volume." If you don't see anything that looks like a direct-boot entry, it could be that you're missing the filesystem driver, or perhaps you're using an unusual filesystem, or maybe you've inadvertently set refind.conf options that are hiding your kernels.

That's set up by the install.sh script. If it's present, you should be able to boot Linux directly by selecting your distribution's kernel in rEFInd, without involving GRUB. This will only work, though, if you've got a suitable EFI filesystem driver for whatever partition holds your kernel. With a default Mint installation and recent (0.6.0 or later) version of rEFInd, this should be the case, since Mint defaults to ext4fs, for which an EFI driver is available and should be installed by install.sh. If you're not sure if you've got such an option, try using the arrow keys to highlight each of the rEFInd boot options in turn. A direct-boot option will read something like "Boot vmlinuz-3.5.0-17-generic from 200GiB ext4fs volume." The key is the kernel filename -- vmlinuz-3.5.0-17-generic in this example. A boot via GRUB will specify a GRUB filename, such as "Boot EFI\linuxmint\grubx64.efi from 200MiB FAT volume." If you don't see anything that looks like a direct-boot entry, it could be that you're missing the filesystem driver, or perhaps you're using an unusual filesystem, or maybe you've inadvertently set refind.conf options that are hiding your kernels.

My Mint filesystem is ext4, and I see an ext4_x64.efi driver in EFI/refind/drivers_x64, so I guess that can work. But I thought you had said that I wouldn't need to be specific about the filename. i.e., when Mint decides to issue a new kernel, so the kernel filename changes, rEFInd would still be able to boot it without my having to doctor it's config file up. Or are you saying refind will automatically detect the kernel and present me with an option to boot it directly (maybe it's there if I scroll to the right...)? There's currently no reference to my vmlinuz-3.5.0-17-generic kernel in refind.conf, but there is a scan_all_linux_kernels instruction in there...