grub-efi problems when installing Mint 13

[Ellisimpark]

I'm installing Mint 13 (64 bit) on a new system from USB and keep getting told that "the 'grub-efi' package failed to install into /target/".

I've googled about but most advice seems to be for dual booting, which I'm not doing.

[chessmaster942]

I just got this error as well... BUMP

[srs5694]

A message that the package failed to install is pretty vague, so it's hard to know precisely what went wrong. The grub-efi package, however, provides the Extensible Firmware Interface (EFI) build of the GRUB 2 boot loader. In other words, this is the software responsible for handing control of the computer over from the EFI firmware to the Linux kernel. EFI (or UEFI) firmware is the replacement for the 30-year-old BIOS firmware. Most new computers use UEFI, although most of these include a BIOS compatibility mode so that they can boot using either an EFI boot loader or a BIOS boot loader. A failure to install grub-efi means that the computer most likely won't boot (at least not into Linux), but it's possible that the rest of the system did install.

Without knowing the details of what went wrong, it's impossible to be specific about possible solutions. The best advice I can offer is to continue with the installation as best as you can and then manually install a boot loader of your choice. Several are available, as detailed on this Web page I wrote about the topic. I'm not a fan of GRUB 2, though; it's finicky and unreliable, in my experience, at least on EFI systems. With a system using a pre-3.3.0 kernel, my suggestion would be to use ELILO or Fedora's patched GRUB Legacy. (If dual-booting with ELILO, you'll need to use a separate boot manager, too. Some EFI implementations provide acceptable boot managers as part of the firmware, but some don't, so you'll need to use something like rEFInd.) With a 3.3.0 or later kernel, a better option (IMHO) is to use the kernel's EFI stub loader in conjunction with rEFInd or gummiboot. My Web page on EFI boot loaders provides synopses on all of these except gummiboot, as well as general installation instructions.

If you need more specific advice, you'll have to get more detail about what's not working and post that information here. That pretty much means that you'll need to attempt a manual boot loader installation to get the error messages, although it's possible there's a boot log from your Mint installation attempt with some relevant messages. (I'm not sure of that or what it would be, although installation logs are sometimes stored in the /root directory of the installed system.)

[powerhouse]

In addition to what srs5694 wrote above, if you can't get it work and you don't have a compelling reason for using UEFI boot - format your drive with MBR and boot in legacy mode (enable it in BIOS - most computers/boards will have this option). I managed to get Linux Mint boot in UEFI, but getting Xen boot using UEFI was more difficult and though I once managed to make it work, I wasn't able to repeat the process. I agree with srs..., grub can be a real pain when it comes to UEFI.

Good luck.

[chessmaster942]

My real reason for wanting UEFI was the partition limit, and the ability to have many bootloaders.
My workaround for not having UEFI was using GPT and a bootmanager. Simple, but effective.

[kvorg]

Incidentally, at least the 64-bit Mint 14 RC1 version installer also fails with EFI install. However, the problem is only missing Grub-EFI package. You can mount the target, bindmount /proc, /sys and /dev, chroot into the target and then install the package with apt-get.

The easiest way to then deploy grub and EFI boot was simply to upgrade the kernel.

Cheers,
-kvorg

[powerhouse]

Incidentally, at least the 64-bit Mint 14 RC1 version installer also fails with EFI install. However, the problem is only missing Grub-EFI package. You can mount the target, bindmount /proc, /sys and /dev, chroot into the target and then install the package with apt-get.

The easiest way to then deploy grub and EFI boot was simply to upgrade the kernel.

Cheers,
-kvorg

Thanks for the ups on Mint 14.

It's a pity it doesn't have UEFI support out of the box, at least that is what I understand from your post.

UEFI is becoming more and more popular from the hardware side. It also has a number of advantages (it should have since MBR is stone age). It is also really important for Linux to grab UEFI because Microsoft is going to hijack it for "security" and other reasons. One way Microsoft intents to use UEFI is to have mobile device manufacturers to lock down their devices for Microsoft. In other words, you buy a mobile device with MS Windows or whatever on it, and it will be locked down so that you cannot install Linux (or anything else). Remember the Windows Mobile disaster? Microsoft needs to get back to conquer the mobile market - they had lost it but want (must?) regain it. Linux will fall easy pray if it isn't ready for UEFI.

Sorry to use such militant language, but that is what it's all about in business.

[srs5694]

It's a pity it doesn't have UEFI support out of the box, at least that is what I understand from your post.

I haven't yet tried Mint 14, but if it's based off of Ubuntu 12.10, chances are it at least includes a kernel with EFI stub loader support. This can help a lot, since it means you can easily use rEFInd or gummiboot as a boot manager, or even reference the kernel as a boot loader directly from your firmware's own boot manager. If you know what you're doing, this is a big plus. The trouble is that few people know what they're doing around UEFI just yet, which makes it harder to get help or find documentation.

UEFI is becoming more and more popular from the hardware side. It also has a number of advantages (it should have since MBR is stone age). It is also really important for Linux to grab UEFI because Microsoft is going to hijack it for "security" and other reasons.

I presume you're referring to Secure Boot. There was a big public storm about this about a year ago, but it turns out to be not nearly as much of a threat as was once believed. See Matthew Garrett's blog post about Shim, which is the tool that Red Hat/Fedora is developing (apparently with significant input from SUSE) to get those distributions booted. The Shim approach essentially changes the Secure Boot "track" from one that's tightly controlled by Microsoft to one that's much friendlier to open source. It would have been better for the UEFI spec to create it that way to begin with, but Shim looks like a workable solution. Right now Shim isn't yet completely functional, though, so some workarounds may be necessary. Disabling Secure Boot is pretty simple on x86/x86-64 PCs, if you're used to adjusting firmware options. Creating your own keys is also possible, but is too awkward for anything but experts at this point.

One way Microsoft intents to use UEFI is to have mobile device manufacturers to lock down their devices for Microsoft. In other words, you buy a mobile device with MS Windows or whatever on it, and it will be locked down so that you cannot install Linux (or anything else).

ARM devices have the disadvantage that Microsoft's Windows 8 certification requirements specify that Secure Boot can not be disabled on ARM, whereas the same document says that users must have the ability to disable it on x86/x86-64. (Of course, ARM devices that don't ship with Windows 8 can ignore Microsoft's requirements.) That said, the same approach that Red Hat is using on x86/x86-64 should work on ARM -- namely, signing Shim with Microsoft's key through the signing service that Verisign administers. Matthew Garrett says that Red Hat/Fedora won't be doing so itself, but some other interested party could certainly do so. OTOH, this does mean that your ability to boot Linux will be held hostage to Microsoft's willingness to continue supporting key signing by third parties. Personally, I hope to never buy any Secure Boot device on which the feature can't be disabled, just in case future developments block Shim or similar tools.

[tsh]

Incidentally, at least the 64-bit Mint 14 RC1 version installer also fails with EFI install. However, the problem is only missing Grub-EFI package. You can mount the target, bindmount /proc, /sys and /dev, chroot into the target and then install the package with apt-get.

The easiest way to then deploy grub and EFI boot was simply to upgrade the kernel.

Cheers,
-kvorg

Any chance of a sligntly more explicit set of instructions for those of us who are not intimatly familiar with the installer? I can fork out my partition names etc fine, chroot is known, bindmount is new...

Would prefer to get this right now since it is a new build, but the quickest workaround seems to be either enable legacy mode, or install ubuntu 12.10 first and rely on it's bootloader (succeeded there, but forgot the whole unity disaster).

[powerhouse]

...

UEFI is becoming more and more popular from the hardware side. It also has a number of advantages (it should have since MBR is stone age). It is also really important for Linux to grab UEFI because Microsoft is going to hijack it for "security" and other reasons.

I presume you're referring to Secure Boot. There was a big public storm about this about a year ago, but it turns out to be not nearly as much of a threat as was once believed. See Matthew Garrett's blog post about Shim, which is the tool that Red Hat/Fedora is developing (apparently with significant input from SUSE) to get those distributions booted. The Shim approach essentially changes the Secure Boot "track" from one that's tightly controlled by Microsoft to one that's much friendlier to open source. It would have been better for the UEFI spec to create it that way to begin with, but Shim looks like a workable solution. Right now Shim isn't yet completely functional, though, so some workarounds may be necessary. Disabling Secure Boot is pretty simple on x86/x86-64 PCs, if you're used to adjusting firmware options. Creating your own keys is also possible, but is too awkward for anything but experts at this point.

One way Microsoft intents to use UEFI is to have mobile device manufacturers to lock down their devices for Microsoft. In other words, you buy a mobile device with MS Windows or whatever on it, and it will be locked down so that you cannot install Linux (or anything else).

ARM devices have the disadvantage that Microsoft's Windows 8 certification requirements specify that Secure Boot can not be disabled on ARM, whereas the same document says that users must have the ability to disable it on x86/x86-64. (Of course, ARM devices that don't ship with Windows 8 can ignore Microsoft's requirements.) That said, the same approach that Red Hat is using on x86/x86-64 should work on ARM -- namely, signing Shim with Microsoft's key through the signing service that Verisign administers. Matthew Garrett says that Red Hat/Fedora won't be doing so itself, but some other interested party could certainly do so. OTOH, this does mean that your ability to boot Linux will be held hostage to Microsoft's willingness to continue supporting key signing by third parties. Personally, I hope to never buy any Secure Boot device on which the feature can't be disabled, just in case future developments block Shim or similar tools.

Thanks for making things more clear on the UEFI / Microsoft front. From what I understand, Microsoft wants to grab the handheld/mobile devices market, where they've been a total looser so far. On the x86 platform Linux is hardly a competitor to Microsoft, who holds - what - 90%+ of the market?
But in the handheld / mobile market Microsoft holds next to 0% of the market (are there still any Windows Mobile devices in use?). Unlike with x86 hardware, the Windows 8 certification requirements essentially mean that someone who buys an ARM-based device will be stuck with Microsoft.

[powerhouse]

Incidentally, at least the 64-bit Mint 14 RC1 version installer also fails with EFI install. However, the problem is only missing Grub-EFI package. You can mount the target, bindmount /proc, /sys and /dev, chroot into the target and then install the package with apt-get.

The easiest way to then deploy grub and EFI boot was simply to upgrade the kernel.

Cheers,
-kvorg

Any chance of a sligntly more explicit set of instructions for those of us who are not intimatly familiar with the installer? I can fork out my partition names etc fine, chroot is known, bindmount is new...

Would prefer to get this right now since it is a new build, but the quickest workaround seems to be either enable legacy mode, or install ubuntu 12.10 first and rely on it's bootloader (succeeded there, but forgot the whole unity disaster).

See here: http://forums.linuxmint.com/viewtopic.php?f=42&t=108442, steps 8 and 11 for binding / mounting. In step 9 you will need to install grub-efi instead of lvm2. Hope this helps.

P.S.: It may be necessary to create some folders under /mnt - use "sudo mkdir /mnt/name".

[srs5694]

Unlike with x86 hardware, the Windows 8 certification requirements essentially mean that someone who buys an ARM-based device will be stuck with Microsoft.

Not entirely. First, any ARM-based device that doesn't ship with Windows 8 will be unaffected by Microsoft's certification requirements. For that matter, if the manufacturer was willing to forego slapping a Windows 8 logo on the device could ignore those requirements, too.

Second, as I wrote in my previous post, it's easy enough for a Linux distribution vendor to get around the Secure Boot issue by having their own boot loader signed. AFAIK, even an individual could do this, although it would cost $99 (for the right to sign as many binaries as you wanted). I don't know of any distributions that are planning to officially support Secure Boot on ARM, but I suspect it's just a matter of time before such support materializes from somebody. Even somebody other than a distribution's vendor could do it -- you or I could obtain a key, use it to sign a boot loader for whatever distribution we want (or a generic boot loader), and distribute it.

[powerhouse]

Unlike with x86 hardware, the Windows 8 certification requirements essentially mean that someone who buys an ARM-based device will be stuck with Microsoft.

Not entirely. First, any ARM-based device that doesn't ship with Windows 8 will be unaffected by Microsoft's certification requirements. For that matter, if the manufacturer was willing to forego slapping a Windows 8 logo on the device could ignore those requirements, too.

Second, as I wrote in my previous post, it's easy enough for a Linux distribution vendor to get around the Secure Boot issue by having their own boot loader signed. AFAIK, even an individual could do this, although it would cost $99 (for the right to sign as many binaries as you wanted). I don't know of any distributions that are planning to officially support Secure Boot on ARM, but I suspect it's just a matter of time before such support materializes from somebody. Even somebody other than a distribution's vendor could do it -- you or I could obtain a key, use it to sign a boot loader for whatever distribution we want (or a generic boot loader), and distribute it.

Thanks for the insight! Of course, any non-Microsoft Windows ARM device is not effected. But let's look at it in a practical way: there'll be iPads (Apple), Android/Linux ARM devices, and Windows ARM devices. If you buy a Windows device, you're screwed. Of course, the same goes for Apple.

I understand from you that you can unscrew Windows ARM devices if you use a Linux distribution that has its boot loader signed, which I could do for $99 if I want to.

From a practical point of view: If I see Windows tablets, Apple tablets, and Android tablets, which one(s) should I consider?

Apple - my experience is that Apple products are some (light) years ahead in hardware technology (the software is Linux/Unix/BSD?-based and not too bad), but unfortunately very problematic with regard to Linux.

Windows tablets - though I haven't seen them so far (and we all know the disaster of Windows mobile), they will be Windows only, according to their license agreement with the tablet manufacturers. I'm not sure if anyone else has obtained a boot loader signature for Windows devices, but unless I see this, I have doubts.

Android - some hardware products are copy/paste stolen products of Apple (Samsung paid for it), perhaps others are also legitimate. Why I'm so critical about it? I've seen enough IP theft (intellectual property theft) and how it effects companies (how they loose millions of dollars development expenses when some cheap copy/paste vendor copies the software or hardware product). Back to Android - that is probably the best or most Linux-friendly option to choose.