Dual boot Windows7 & Mint on EFI System

[arealvel]

There are a lot of things on this on the net but I ask for advice because I’m a little confused. I'm not a computer technician.

I bought recently a laptop Asus with Windows 7 preinstalled (64 bits). As most laptops with preinstalled Windows in these days they came with a EFI System Partition, OS partition, Data Partition and Recovery Partition.

I don’t want to touch the Windows Bootloader in the Efi System Part. as I know that loosing the GPT I won’t be able to run the Recovery Disks, if needed. So I planned to relay on the Windows bootloader and use EASYBCD 2.2 (this version has EFI support, I red), adding there a voice for Mint.

So, I run Mint installation with the option third “Something else”. It allows me to create three new partitions for Mint.

The new partitions were:
• Boot partition (Ext2- 500MB – assigning here the installation Grub, and formatting as “Boot Partition”)
• Swap (4GB)
• Root partition (Ext4 - 100GB)

When the install finish I enter Windows and I add a voice for Mint in EASYBCD. For this voice I select Grub2 as bootloader, and the Boot Partition. I have red that Easybcd works as the stage 1 of the bootloader, in order to transfer control to the Grub and boot Mint.

Now the problem is that when I start the Asus and I select the Mint voice in the Menu it gives me this: “File: \NST\AutoNeoGrub0.mbr
Status: 0xc000000f
Info: The selected entry could not be loaded because the application is missing or corrupt”.

My question: Does anybody knows how to fix this or what to change to have Mint working?

[mintybits]

I am not an expert but I have some hints that may help. The problem may be that the Mint installer does not install an EFI bootable system. I don't think this is supported. Instead, I believe it does a work-around by making Mint "BIOS" mode bootable instead of EFI mode bootable. So I suspect that if you set your system to "BIOS" mode it will boot Mint, although it will no longer boot Windows. There is a program called REFIT and one called REFIND that makes Mint EFI bootable but I am not familiar with them. See: http://forums.linuxmint.com/viewtopic.php?f=46&t=97221

[srs5694]

I'm not familiar with EasyBCD, so I'm not sure precisely what its filenames mean or what it does; however, the filename \NST\AutoNeoGrub0.mbr suggests a backup of a Master Boot Record (MBR), which is used in BIOS-mode booting rather than in EFI-mode booting. Thus, my suspicion is that EasyBCD has attempted to set up a BIOS-bootable image for Linux, but if you've done an EFI-mode install, that won't work.

OTOH, it's possible that mintybits is on the right track and that Mint has installed in BIOS mode and the filename reported by EasyBCD is a red herring. In that case, the trick will be to find a way to make Linux boot in EFI mode. Although rEFIt and rEFInd can help in this, neither is a simple drop-in tool to fix all problems. (That said, I'm rEFInd's maintainer, and I'm making changes to its installation script that will help get rEFInd working more easily from more systems.)

Overall, I'd say we need more information. For that, try running the Boot Info Script from an emergency disc. This will produce a file called RESULTS.txt. Post it here, either between code tags or as a link. It will help us to understand what's going on with your installation.

[arealvel]

Thanks, Mintybits and srs5694 for your answers.

I try to create an EFI partition for Mint booting following https://help.ubuntu.com/community/UEFI but I ran into an independent problem (my Windows update starts often on his own, despite my settings about it, don't know why). To say it short I found myself facing a Windows boot damage. Fortunately, Windows 7 Recovery Disk repaired it.

Perhaps, I'm going to read some more before any other try (I suspect that it's possible to boot Windows on EFI and non-EFI mode). What I can say is that these preinstalled Windows are really stiff. Not good at all for dual-booting. The recovery tools works only if them found the four original partitions (and no more). Think of it. If I could come back in time I'd rather bought something with mbr or with the system disk, otherwise (if you're not a pro) you're blocked.

[arealvel]

Ok, I find a good solution at last.

My main goal was install Mint 14 without risking a Windows boot failure, as I use Windows to work and Mint for all the rest. I don't want touch Windows and I want be able to use all the recovery Windows tools if needed.

The key for the solution was this: installing from a USB bootable pendrive allows a UEFI install, while I couldn't do this with a live-DVD install.

Now for people in my situation I resume the steps that worked for me (Asus with W7 preinstalled in UEFI mode):

1. Download Mint iso.

2. Download Universal USB Installer (last version holds Mint 14).

3. Obtein a bootable USB pendrive wih Mint14. It's quite easy. You Tube holds a lot of visual tutorials.

4. Restart and Enter Bios. In “Boot Option Priorities” choose the UEFI option for your bootable USB pendrive (there will be a UEFI option and a normal option. Use the first).

5. Start installation creating Linux partitions as you like (for ex: boot partition [ext2, 300MB], swap partition [6MB] root partition [ext4, free space you want GB]. Assign the booting device to the boot partition you have create (for me it was sda6). You can choose other ways to format with different filesystems and mount points.
What I learn here is that you're not allowed to allocate the boot partition nor to /boot/efi (because Windows use that mount point) neither to root (/) or to any other mount point you have chosen during partition process. Keeping this in mind assign some other mount point for the boot partition (I used /boot/efi/grub).

6. The installation goes on smoothly. When it finished you are asked to restart. Restarting you can do either:
- enter in Bios: now in "Boot Priority" you see both options: boot from “linuxmint” or boot from “Windows Boot Manager” (so it's now possible to boot the system you want from here).
- let restart: if you, instead of entering the Bios, let the restart proceed (or anyway once you leave the Bios), you face the classical menu display for selecting the OS. Mint starts from here. Note that the Windows options in this menu are not going to work, not being able the grub to chainloader the Windows bootloader (Perhaps there is a repair for this; or if it bothers you, you can cancel those Windows voices from the grub menu). This is all.

This solution is not perfect but is quite satisfactory for me. As I usually work with Windows, assigning the priority to Windows in the Bios allows it start without any other intermediate screen. Also if the priority is settle to Mint and you don’t want a Mint starting, you can escape from the grub menu and automatically starts Windows (as it is the second priority settled in the Bios).

[Orbmiser]

I don’t want to touch the Windows Bootloader in the Efi System Part., as I know that loosing the GPT, I won’t be able to run the Recovery Disks, if needed. So I planned to relay on the Windows bootloader and use EASYBCD 2.2 (this version has EFI support, I red), adding there a voice for Mint.

So, I run the installation with the option third “Something else”. It allows me to create three new partitions for Mint.

The new partitions were:
• Boot partition (Ext2- 500MB – assigning here the installation Grub, and formatting as “Boot Partition”) Wrong
• Swap (4GB)
• Root partition (Ext4 - 100GB)


My question: Does anybody knows how to fix this or what to change to have Mint working?

• Boot partition (Ext2- 500MB – assigning here the installation Grub, and formatting as “Boot Partition”) Wrong

You do not need to create a boot partition.
When in something else partitions config and you want to chain load grub bootloader. Then you change bootloader to install on root partition. And then boot up Win7 and add entry using easyBCD.

At least that is what I did without issue works great. And is there some reason you think you need a /boot partition?

[mintybits]

The whole GPT/EFI support by linux seems to me to be a mess. So the last suggestion to avoid the issue by booting Mint from Windows using EasyBCD is attractive.

My understanding is that GPT/BIOS installation works ok. Although Grub demands a special boot partition which is naff.
My understanding is that GPT/EFI installation is hit and miss and moreso when Windows is present.

EasyBCD sounds like a convenient alternative for GPT/EFI if you have Windows already installed. There is still a gotcha, tho. The Grub installer seems to be a mess too. It is not properly designed to work when installed to a partition because its location-critical files are not made immutable. It will work most of the time, perhaps always for some, but occasionally it will break and need reinstalling. I dont know whether Easy BCD now gets around this by using its own Grub kernel or not.

Someone needs to get a grip on the whole linux installer/boot thing because it is still a mess. Works well enough for MBR/BIOS systems...mostly.

[Orbmiser]

"The whole GPT/EFI support by linux seems to me to be a mess."

+1 to that greed pushing human tolerances to the Max!

"I dont know whether Easy BCD now gets around this by using its own Grub kernel or not."

Nope just modifies the Win loader adding an entry to it. In fact just points to the / root where the grub is installed.
But don't have a complete understanding and zero experience with the new EFI Tron-Level Master Control Devils inside
So could have it wrong or misinformed?
.

[arealvel]

Thanks for replaying.

• Boot partition (Ext2- 500MB – assigning here the installation Grub, and formatting as “Boot Partition”) Wrong

You do not need to create a boot partition.

Ok. But I tried five or six times with different filesystems (Fat32, Ext 2: not just formatting as "Boot Partition") and never see a menu for Linux Mint after installation. Placing an entry voice in EasyBCD gave always error.

The only option I didn't try was selecting sda1 (or leave without selection) the partition under "Device for Boot Loader installation". Perhaps this works, I don't know, but I feared that doing this could mess the Windows Boot Manager placed there. As I said I didn't want to risk that.

Anyway my point is: using the live-DVD you don't have option for a UEFI installation and you don't see after installation a OS boot Menu, nor in the Bios neither in first screen. Instead: from a bootable USB you have the option for a UEFI USB boot and from that you have your dual-boot. You can also ignore completely EasyBCD.

[Perhaps a conclusion could be that with Windows installed in UEFI mode, you need the other OS also installed UEFI mode for dual-booting].

Added for information: My Bios

Aptio is AMI's next-generation BIOS firmware based on the UEFI Specifications and the Intel® Platform Innovation Framework for EFI. Aptio is specifically designed to address firmware portability and extensibility to future platforms.

PS: It occurs now to me that probably the problem was I was using a DVD reader a little dated. So this could be the reason I wasn't able to install from DVD in UEFI mode.

[tsdadam]

I've just done something similar to this on my laptop to dual-boot Windows 8 and Mint 14, both in EFI.

viewtopic.php?f=42&t=121912

For me, the trick was to install Mint in BIOS mode rather than EFI, and to later use the boot-repair tool to convert the install to an EFI one. Installing Mint in bios mode is as easy as it's ever been.

However, i was happy installing GRUB, and then later rEFInd

[arealvel]

I've just done something similar to this on my laptop to dual-boot Windows 8 and Mint 14, both in EFI.

viewtopic.php?f=42&t=121912

I've red your post before my installation but didn't find anything on Bios settings to change to non-EFi or Legacy mode. So I couldn't do it.

[srs5694]

5. Start installation creating Linux partitions as you like (for ex: boot partition [ext2, 300MB], swap partition [6MB] root partition [ext4, free space you want GB]. Assign the booting device to the boot partition you have create (for me it was sda6). You can choose other ways to format with different filesystems and mount points.
What I learn here is that you're not allowed to allocate the boot partition nor to /boot/efi (because Windows use that mount point) neither to root (/) or to any other mount point you have chosen during partition process. Keeping this in mind assign some other mount point for the boot partition (I used /boot/efi/grub).

First, Linux partitions are generally referred to by their mount points; for instance the /home partition or the /boot partition. Note the leading "/", which denotes the start of an absolute Linux path. The main installation partition is mounted at "/", which is pronounced "root", so it's sometimes called the "root partition" -- but note the lack of a leading slash in "root" in this case. Another exception is the swap partition; swap space isn't mounted, so it's just called the "swap partition" (again, no leading slash). There are some other exceptions, like LVM partitions and non-Linux partitions. Among the latter, the EFI System Partition (ESP) is important and is generally referred to as such, but it will also have a Linux mount point -- typically /boot/efi. Unfortunately, the Mint installer uses a somewhat non-standard term for the ESP; IIRC, it calls it the "EFI boot partition." This is a deviation from standard terminology, and given the newness of all of this for many users, such deviations just cause more confusion.

Given all of this, your mounting a "boot partition" at /boot/efi/grub is peculiar at best. The usual configuration for an EFI system includes:

- A Linux root (/) partition
- An optional /boot partition
- An ESP mounted at /boot/efi
- Additional partitions, as you see fit (/home, swap, and so on).

Mounting an ext2fs partition at /boot/efi/grub is unlikely to have any effect at all in a stock Mint installation, since Mint puts nothing in that directory. You might end up putting some GRUB files there if you install GRUB by hand, though. The result would likely be unbootable, since the files that would most likely reside in /boot/efi/grub would be EFI boot loader files that the EFI must be able to read, and the EFI can't read ext2fs without extra drivers.

The whole GPT/EFI support by linux seems to me to be a mess. So the last suggestion to avoid the issue by booting Mint from Windows using EasyBCD is attractive.

The trouble that many people have today is that new computers ship with Windows installed in EFI mode, and configuring a computer to boot one OS in EFI mode and another in BIOS mode is awkward -- most firmwares make it hard to switch boot modes at boot time.

My understanding is that GPT/BIOS installation works ok. Although Grub demands a special boot partition which is naff.

Actually, the BIOS Boot Partition for BIOS-mode booting on GPT is far from "naff." In a traditional BIOS/MBR setup, GRUB installs a chunk of code in officially unpartitioned space between the MBR (sector 0) and the start of the first partition. Because this space is officially unpartitioned, it can't be marked out as belonging to GRUB, and in fact some other tools will blindly try to use the same space. That is naff; creating a partition for GRUB's code is the proper way to do it!

EasyBCD sounds like a convenient alternative for GPT/EFI if you have Windows already installed. There is still a gotcha, tho. The Grub installer seems to be a mess too. It is not properly designed to work when installed to a partition because its location-critical files are not made immutable. It will work most of the time, perhaps always for some, but occasionally it will break and need reinstalling. I dont know whether Easy BCD now gets around this by using its own Grub kernel or not.

If that entire paragraph is meant to apply to EFI-mode booting, then you've got something wrong, or I'm misinterpreting something, because in the EFI scheme, there's no need to mark files as "immutable" (meaning that their locations on the disk cannot be changed); EFI-mode booting is done via file-level access. It's true that some boot loaders require some files to be immutable on BIOS-mode installations, though. Even then, my understanding is that GRUB requires no immutable files when it uses a BIOS Boot Partition, since the contents of that partition include filesystem drivers with which GRUB reads files from the /boot/grub directory. The BIOS Boot Partition (or its equivalent unprotected code on MBR disks) can't be moved without re-installing GRUB; and if you lack a BIOS Boot Partition, certain files must be immutable. This is all relevant for BIOS-mode booting, though, not for EFI-mode booting.

The whole GPT/EFI support by linux seems to me to be a mess.

+1 to that greed pushing human tolerances to the Max!

It's not really greed, except perhaps to the extent that it's contributed to the real problem: Sloppy and variable implementations. The EFI spec is over 2,000 pages long, plus thousands more pages of documentation on system calls and whatnot. Despite this size, the spec leaves out a lot of critical details, and there are features that clearly weren't very well thought-out. (The phrase "designed by committee" comes to mind.) The reference EFI implementation (from which all production EFI implementations are derived) includes bugs, and firmware authors have introduced their own unique bugs. The firmware companies don't seem to have tested with Linux, at least not as a general rule, and by and large the Linux distribution developers have been insufficiently pro-active in developing EFI support. An added problem is the fact that computer manufacturers are installing Windows in ways that are somewhat inconsistent from one manufacturer to another -- they sometimes add their own ESP-like partitions or add their own manufacturer-specific boot loaders to the mix. A feature designed to help with the transition (the Compatibility Support Module, or CSM, which provides BIOS/legacy support) actually complicates matters because a program author can't really know ahead of time whether the computer will boot in BIOS/legacy mode or in EFI mode, or even which modes the computer supports. Distributions haven't been making the boot mode clear to users, and users don't understand the difference. Add Secure Boot to this and it gets even more complex.

Speaking as an author of an EFI tool (rEFInd), this has all come together to create a mess of implementations that work inconsistently. I've been trying to disentangle this in rEFInd, but the current state of rEFInd and its installation script is admittedly imperfect. There's really nothing I can do about some problems, since they're caused by firmware bugs that can't be worked around. Other problems I have already worked around or plan to work around as best as I can in the future. Similar comments apply to GRUB and to Linux distributions generally.

This will settle down in time; however, some improvements will simply come as firmware bugs get squashed, leaving older systems out in the cold. (Manufacturers seem to lose interest in updating their firmware a few months after releasing the hardware.)

Perhaps a conclusion could be that with Windows installed in UEFI mode, you need the other OS also installed UEFI mode for dual-booting]

This is rule #1 for installing on EFI-capable computers. I've said as much many times in this and other forums.

Unfortunately, it's not always easy to do this -- as you've said, boot options are sometimes limited, depending on the media you're using and how they were prepared. Fortunately, it is possible to switch Linux from a BIOS-mode to an EFI-mode installation. In fact, it's fairly easy on a Linux-only computer. It gets harder with Windows (or any other OS) installed in EFI mode, though. I've provided a workaround in the latest rEFInd (0.6.3): The install.sh script will install rEFInd in a way that should get rEFInd to launch when you next boot in EFI mode, and from there you should be able to boot either Windows or Linux in EFI mode. That said, this feature has seen minimal testing; it could contain bugs.

PS: It occurs now to me that probably the problem was I was using a DVD reader a little dated. So this could be the reason I wasn't able to install from DVD in UEFI mode.

An old DVD drive shouldn't cause problems -- at least, not from a software perspective. (If the DVD drive couldn't read your disc because it was old, that's another matter, of course.) Whether you're using BIOS or EFI, DVD hardware is fairly standardized from a software perspective, and it just serves as a means to get bits from the CD or DVD into memory.

[arealvel]

Thank you, srs5694 for your long and interesting reply.

[srs5694
Mounting an ext2fs partition at /boot/efi/grub is unlikely to have any effect at all in a stock Mint installation, since Mint puts nothing in that directory.

Indeed, I just see in that partition a "lost + found" folder. I mounted that partition at /boot/efi/grub because the installation did not allow /boot/efi/ as mounting point, saying it was already used on sda1 (ESP partition). I suppose this was due to the Windows Boot Manager being there.

srs5694
The result would likely be unbootable, since the files that would most likely reside in /boot/efi/grub would be EFI boot loader files that the EFI must be able to read, and the EFI can't read ext2fs without extra drivers.

Well, I can see EFI and Grub folders in my root partition (/). Installation placed them there perhaps because the chosen mount point (on /boot/efi/grub: sda6) was useless. Anyway the result was bootable: I can boot both systems Mint and Windows7 with minor problems.

My questions are: Suppose I reinstall Mint in UEFI mode and with the option "Something Else":
@ May I create a partition for the boot or not?
And if the answer is yes:
@ What filesystem and mount point should I use? (note that there is a warning from the installation that ESP partition at /boot/efi is already present and used). If I overwrite it: should after be able to boot Windows?

[srs5694]

Mounting an ext2fs partition at /boot/efi/grub is unlikely to have any effect at all in a stock Mint installation, since Mint puts nothing in that directory.

Indeed, I just see in that partition a "lost + found" folder. I mounted that partition at /boot/efi/grub because the installation did not allow /boot/efi/ as mounting point, saying it was already used on sda1 (ESP partition). I suppose this was due to the Windows Boot Manager being there.

The ESP is a cross-platform partition that's supposed to hold all OSes' boot loaders. In Linux, it's typically mounted at /boot/efi. The installer knows this, and it will automatically configure the ESP to be mounted at /boot/efi, so attempting to mount another partition at that mount point is an error. This has nothing to do with the presence or absence of any particular boot program, including the Windows boot loader. Also, part of the definition of the ESP is that it must use the FAT filesystem (technically FAT32, although you can often get away with using FAT16 on it).

The result would likely be unbootable, since the files that would most likely reside in /boot/efi/grub would be EFI boot loader files that the EFI must be able to read, and the EFI can't read ext2fs without extra drivers.

Well, I can see EFI and Grub folders in my root partition (/). Installation placed them there perhaps because the chosen mount point (on /boot/efi/grub: sda6) was useless. Anyway the result was bootable: I can boot both systems Mint and Windows7 with minor problems.

The root (/) partition doesn't normally hold EFI or GRUB directories; but you should see /boot/efi and /boot/grub directories. Those are the standard places for these directories, and their placement has nothing to do with your creating a partition that you mounted at /boot/efi/grub. That partition is essentially useless, and removing it from your configuration would have no effect except to clear up a bit of disk space for other uses.

My questions are: Suppose I reinstall Mint in UEFI mode and with the option "Something Else":
@ May I create a partition for the boot or not?

Greater precision is required in your question. Please review what I wrote about the uses of slashes in mount points. You might be referring to the /boot partition (if it's present) or the ESP (which Mint confusingly calls the "EFI boot partition"). A separate /boot partition is desirable in many cases but usually not required. An ESP is required, but depending on how you do the installation, it may already exist, so you might just need to point it out to the installer.

And if the answer is yes:
@ What filesystem and mount point should I use? (note that there is a warning from the installation that ESP partition at /boot/efi is already present and used). If I overwrite it: should after be able to boot Windows?

As I said, the ESP is required to use FAT. If it's already present, you should not erase it, since it may hold boot loaders for other OSes. It's normally mounted at /boot/efi, but IIRC, the Mint installer hides this fact. You're permitted to create multiple ESPs on one disk, but this can be confusing, so I advise against it unless you have a good reason for doing so (like if the current one is too small for your needs).

A separate /boot partition can theoretically use just about any filesystem. The best choices for an EFI system are FAT, HFS+, ReiserFS, ext2fs, ext3fs, or ext4fs, since those are the filesystems that EFI can read. IIRC, the Mint installer won't permit use of FAT or HFS+, though, so you'll have to use one of the others. Using a separate /boot partition has less value if you use one of those filesystems on your root (/) partition, since the main advantage of separating /boot from root (/) on EFI is to enable the EFI to read your kernel file if you're using a filesystem that the EFI can't handle.

[Orbmiser]

Good Suff here srs5694 thanks for sharing as always like to learn and increase my knowledge.
.

[mintybits]

The length of responses needed to try to clarify what is going on sort of makes my point. The EFI/GPT ought to be easy to describe: there is now a dedicated boot partition for all OS's boot loaders called the EFI System Partition. I like the ESP acronym...as if ESP is needed to understand it...something not quite achieved by the Mint/Ubuntu installer/Grub yet.

Unfortunately, the Grub people added a bios-grub partition into the equation which is naff and confusing. It is unecessary. Admitedly, it is slightly less naff than the MBR hack but hardly a proper way to do the thing. So now the poor user who is faced with having to use a GPT scheme or being forced to by a prior Windows EFI installation may have to negotiate the difference between a GPT-BIOS partition and an ESP partition; and the Mint-EFI installation doesn't seem to work reliably. Does Windows 8 have these problems?

Fortunately, I have no need to use either GPT nor EFI and have not yet had the pleasure of this challenge. So far, I am struggling to see any advantages to either (except for GPT which is necessary for >2TiB disks), and am cynical about the motives behind the EFI system. Particularly when I heard about the EFI anti-boot feature: the so-called security feature that tries to stop owners from booting a non-Microsoft approved OS. Keeps people busy, I suppose. Linux has to ride the wagging tail of the commercial dog.

[srs5694]

The length of responses needed to try to clarify what is going on sort of makes my point.

Explanations of how BIOS booting work are also quite lengthy. The difference is that the BIOS boot process is well-understood, both by moderately well-versed users and especially by programmers, who have invested decades of effort into making it work smoothly. The EFI boot process, by contrast, is poorly understood, so users need more education about it; and the tools for handling it are not yet very mature.

That said, there are certainly some cringeworthy mistakes in the EFI design, not to mention buggy implementations that just make matters worse. The bugs say more about the lack of maturity of the design than they do about its merits, though.

Unfortunately, the Grub people added a bios-grub partition into the equation which is naff and confusing. It is unnecessary.

A BIOS Boot Partition is unnecessary -- but without it, there are drawbacks to which you'd almost certainly also object. Since you're the one criticizing the design, here's the challenge: Write a BIOS boot loader that fits within 440 bytes (note that's bytes, not kilobytes, much less megabytes) and that can do what GRUB can do, or even do whatever smaller subset of functions you deem desirable. The fact is that 440 bytes is such a tiny amount of space that it's about anybody can do in that space just to locate another chunk of code and redirect the boot process to it. This means you need somewhere to store that code, and all of the options have drawbacks -- for instance, without a dedicated partition, you must store it in unpartitioned space (which is dangerous) or store it in a file (which means that the boot loader will stop working if the file is moved). I suspect you don't fully understand the design compromises involved.

Admitedly, it is slightly less naff than the MBR hack but hardly a proper way to do the thing.

I look forward to seeing your code that gets around the problems of booting from a GPT disk on a BIOS-based computer.

So now the poor user who is faced with having to use a GPT scheme or being forced to by a prior Windows EFI installation may have to negotiate the difference between a GPT-BIOS partition and an ESP partition; and the Mint-EFI installation doesn't seem to work reliably. Does Windows 8 have these problems?

The unreliability of Mint's EFI installation is as much a matter of the fact that the Mint (and Ubuntu and Debian) developers were not very forward-thinking about the matter two, three, or five years ago. This change has been brewing for years, but bugs and limitations in installers went unaddressed for a long time. For instance, Ubuntu took nearly a year to fix this critical bug. Is that EFI's fault? No; it's Ubuntu's. (It's Debian's, too, since the same bug existed in Debian -- but Debian didn't officially support EFI installation at the time.)

Fortunately, I have no need to use either GPT nor EFI and have not yet had the pleasure of this challenge. So far, I am struggling to see any advantages to either (except for GPT which is necessary for >2TiB disks),

Advantages of GPT include:

• >2TiB disk support, as you say.
• No need for extended or logical partitions, which confuse newbies at least as much as BIOS Boot Partitions and ESPs do.
• Backups of critical data structures make disks more resistant to certain types of accidental damage, such as an error with "dd". This was once important for me, and I've seen reports of it being used by others, so this isn't just a theoretical advantage; it's real.
• CRCs of critical data structures enable detection of corruption and automatic switch to use of the backups. Again, I've seen reports of this helping users.
• No CHS geometry issues.
• Partitions can have names, which simplifies their identification in partitioning software.
• Partition type codes are 16 bytes in size, so collisions are much more easily avoided than with the 1-byte type codes used in MBR.
• GPT is defined in a standards document, vs. MBR's ad hoc and somewhat ambiguous/inconsistent definition.

Advantages of EFI include:

• Faster boot times on properly done implementations.
• Support for storing as many boot loaders as you like and selecting which one you want to launch from the firmware. This advantage isn't yet fully realized on most EFI implementations because of bugs, limitations, or an attempt to make the firmware feel more like the familiar BIOS.
• Boot code is stored as files in a filesystem, which makes it possible to create larger boot loaders without engaging in contortions to get it all loaded.
• Boot code is written in C, which is well-understood by countless programmers and can be cross-platform. (BIOS effectively requires the earliest stages of a boot loader to be written in assembly, which is tedious and platform-specific.)
• EFI is a complete pre-boot environment that can support a wide range of utilities -- disk partitioning software, shells, network stacks, etc. This has significant potential to help with emergency recovery, system installation, system management, etc., although the available tools are still fairly limited today.
• Although Secure Boot can be abused and can make things more complex, it can also be a great boon -- you can configure it to prevent unwanted utilities or OSes (even including Windows) from running on your hardware.
• EFI usually runs in the CPU's native best bit width -- normally 64 bits on modern hardware. This is part of why it's faster, but this also removes the need for 16-bit code support, which could one day free up Intel and AMD to simplify their CPU designs, saving money and/or improving performance.
• EFI enables ditching certain legacy hardware features that were required by BIOS. This has little effect today but will eventually impact hardware performance, leading to improvements that you probably won't associate with EFI, but that will be enabled by it.

Of course, many of these advantages don't directly affect your experience as a user, but they do (or might one day) impact it indirectly. For instance, I'm maintaining rEFInd, which is written in C. I don't know assembly, so if I had to maintain anything that was written even partially in assembly, I couldn't do it. Thus, users have more EFI boot manager choices today because EFI code is written in C.

Be aware that I'm not trying to say that EFI is perfect; it's got some serious problems. Those problems come with a positive flip side, though. Most of EFI's problems right now relate to its immaturity -- EFI implementations tend to be buggy and quirky, and support on the OS side is still limited. These problems will fade in time.

and am cynical about the motives behind the EFI system. Particularly when I heard about the EFI anti-boot feature: the so-called security feature that tries to stop owners from booting a non-Microsoft approved OS.

Secure Boot does have the potential to be abused; but as I said earlier, it can also be used to give you better control of your computer. Reconfigure your firmware and it's Windows that can be locked out, if that's what you want. The problem right now is that the Linux world was surprised by Microsoft's announcement of its certification requirements for Windows 8, which effectively require that Microsoft's key be installed in new hardware, and that new computers ship with Secure Boot active. The failure to see this coming was a strategic mis-step on the Linux community's part, but it's looking like it won't be fatal, or even more than an annoyance. The Mint developers have yet to even publicly announce a strategy for dealing with Secure Boot, AFAIK -- but again, that says more about the Mint developers' lack of attention to the issue than it says about anything else.

Incidentally, Secure Boot is a relatively recent addition to EFI. EFI originated about a decade ago and the original Intel specification did not mention Secure Boot. Even half a year ago, very few computers supported Secure Boot. Perhaps Microsoft is pushing EFI for reasons you can be cynical about, but as for EFI as a whole, there's little reason for cynicism about the motives behind it. My own biggest criticism of EFI boils down to the fact that it's an overly-complex standard that appears to have been designed by committee. I have no reason to question the underlying motives of its developers.

Keeps people busy, I suppose. Linux has to ride the wagging tail of the commercial dog.

It's kept me busy -- both incorporating Secure Boot code into rEFInd and answering a lot of posts on Web forums. And yes, Linux is built as a follow-on product for a massive commercial juggernaut (meaning the PC industry as a whole, not just Microsoft). As such, Linux is at a disadvantage in some ways, and the transition from BIOS to EFI is highlighting that fact.

[arealvel]

OK, after reading your reply (srs5694) I reinstall, with no action by myself, I mean, I leave the installator decide where to place the boot manager. I just create a swap and a root partitions. No selection for a boot partition, neither for boot device, no other meaningful action.

The result was as before: a fully functional dual-boot accessible from bios and "negotiable" from the grub menu (Windows entries from the Grub menu are useless though). For me it's all ok.

In my opinion EFI is a very good thing (I've changed my opinion about it), as each OS seems to boot “parallel”, using the same partition, having its own space and without interferences between the bootloaders. This provides a psychological feeling of security, because if your new system installation fails it is not going to compromise others OS installed.

Some people bothers about entering in the UEFI capable Bios to change options, but this has also a good side: for ex: if you use 80% a system and 20% another, you place the main-used-system as first boot option and this boots directly without intermediate screens. Just enter in the Bios when you want to use the second system.

What would be useful is offer a Mint installation for systems installed in EFI mode where the Grub manager just install Mint, and do not scan for other OS installed (or do not incorporated them into the Menu). If I don’t miss the point (which I probably do) scanning OS systems is not so necessary by the way EFI works. People who want a non-BIOS menu can install on their own a Boot Manager with that functionality (as I think rEFInd or another BootM has).

Instead, what perhaps would be welcome is just a first screen with a menu containing the boot option priorities.

Thank you srs5694, mintybits, Orbmiser, etc. for you help with this.
____________________
A question: In a new computer without any OS loaded, I install Mint in EFI mode and after I install Windows 7 in EFI mode, what is going to happen? I guess that Windows is going to behave different as in a usual MBR installation, and is not going to upset Mint's boot.

[mintybits]

It's kept me busy -- both incorporating Secure Boot code into rEFInd and answering a lot of posts on Web forums. And yes, Linux is built as a follow-on product for a massive commercial juggernaut (meaning the PC industry as a whole, not just Microsoft). As such, Linux is at a disadvantage in some ways, and the transition from BIOS to EFI is highlighting that fact.

I would encourage you to put your efforts into understanding the details of booting linux and how to write the code necessary to do it. This way you might be able to develop an EFI booter for Ubuntu/Mint that can be incorporated into the official installer. By gaining a more detailed understanding you would also recognize the means to avoid the grub-bios partition.
If you want to learn more a new thread would be appropriate.

PS: Your statement that Refind is written in C horrifies me. I suggest you learn about modern languages. C is really old-fashioned and a hacker's delight. New code should not be based on C, IMO, but on properly structured languages. The linux kernel is written in C because it is very old and there is a fear of changing it and there are arguments about the efficiency of other compilers for particularly speed-critical code. A bootloader should have no such concerns.

[mintybits]

In my opinion EFI is a very good thing (I've changed my opinion about it), as each OS seems to boot “parallel”, using the same partition, having its own space and without interferences between the bootloaders. This provides a psychological feeling of security, because if your new system installation fails it is not going to compromise others OS installed.

The irony of what you say is that the MBR system does keep the bootloaders independent, by design. However, the linux corruption of it causes the inter-dependency which you are praising EFI for solving. EFI is a better system, in principle, but today the Mint support is really poor.

What would be useful is offer a Mint installation for systems installed in EFI mode where the Grub manager just install Mint, and do not scan for other OS installed (or do not incorporated them into the Menu). If I don’t miss the point (which I probably do) scanning OS systems is not so necessary by the way EFI works. People who want a non-BIOS menu can install on their own a Boot Manager with that functionality (as I think rEFInd or another BootM has).

Yes, EFI ought to simplify Grub. There should be, I presume, a unique EFI boot file for each linux installation made. Simplifying Grub has got to be a good idea.

A question: In a new computer without any OS loaded, I install Mint in EFI mode and after I install Windows 7 in EFI mode, what is going to happen? I guess that Windows is going to behave different as in a usual MBR installation, and is not going to upset Mint's boot.

I don't know. I would hope that you'd end up with two EFI boot menu items and the OS 's will each boot fine. But Mint's EFI support is "IFI"