ElectricRider wrote:I just learned about my new PC having UEFI with it's Windows 8 installed. Trying to load from USB , i could never see the usb from the boot options so i researched to find it's the UEFI causing the problems.
As I understand it, a Mint image file written to a USB flash drive is not bootable in EFI mode. This isn't an EFI problem per se; it's a problem with the way the Mint image file was created. (Fedora 18's image file is
bootable when written to a USB flash drive.) The same Mint file, burned to an optical disc, is
bootable. I've seen reports that writing the image file to a USB flash drive using UNetbootin is
bootable, so if your computer lacks an optical drive, I recommend using UNetbootin to prepare your USB flash drive.
My Bios does give me the option to disable Secure Boot and it also tells me that I will not be able to load windows.
Then it's giving you a paranoid FUD warning. I've seen several reports (including yours in a subsequent post in this thread) of pre-installed Windows 8 booting just fine when Secure Boot is disabled. I have yet to see a report of Windows 8 failing to boot because of disabling Secure Boot.
That said, there are legitimate security reasons for leaving Secure Boot enabled. Getting Mint to boot in that way will require a different approach than you're contemplating, though -- see below....
Also, i have read the thread above on the modified EFI bootloader and i would try that But that thread is kinda complicated for me
I have no idea what the "thread above" is. There have been numerous threads that touch on Secure Boot on this forum. If you mean to refer to a specific thread, be sure to include a link.
i tried it and windows still booted. I can always get back into Bios to change it back - and I'll need to because manually switching like this is not good for everyday use.
The easiest approach is to leave Secure Boot disabled. Windows will continue to boot, and at the moment the risk is low -- Secure Boot is intended to protect against EFI-specific boot-time malware, and to the best of my knowledge, no such malware yet exists in the wild. (I have heard of a couple of "proof of concept" attacks created by security researchers, but AFAIK those aren't being used for actual attacks against real-world computers.) Of course, if you leave Secure Boot disabled, there's always a chance that you'll get hit in the first wave of an actual EFI boot-time malware attack, but the chances of that are lower than the chances of getting hit by existing BIOS boot-time malware.
If you do want to enable Secure Boot for both OSes, read on....
I'm lucky in that I do have an option to use legacy bios because many new PC's do not have this option at all.
I haven't heard of any new x86-64 PCs that lack legacy BIOS support, although many do ship with that support disabled via a firmware option. For the moment, the ability to boot legacy/BIOS OSes is still too important for manufacturers to risk shipping computers that can't handle it. No doubt that will change in time, and it's entirely possible that some obscure product today lacks legacy/BIOS support, but such systems are extremely rare, at least in the x86-64 world.
I understand Ubuntu has it's own bootloader for UEFI (as does fedora)( this is one way around the problem) and The Linux Foundation is working on getting a secure boot key from Microsoft to to incorporate into Linux which is another way around the problem
It's both more and less complicated than this. Secure Boot works by examining the signatures (if present) on EFI boot loader programs and comparing them with public keys held in the firmware. This is conceptually similar to signing an e-mail with GPG; if the signature matches a public key that's on file, the program/message is reasonably certain to come from the claimed source. If not, it could be forged or simply unsigned.
Microsoft has at least two keys that are being included in most or all x86-64 UEFI PCs. It uses one to sign its own binaries and it uses the other to sign third-party binaries. Competing OS vendors, as well as the vendors of emergency recovery utilities, drivers, etc., can then have their EFI binaries signed so that they work on standard PCs. Red Hat/Fedora, Canonical/Ubuntu, and Matthew Garrett have all signed up with Verisign to have Microsoft sign their binaries. For various reasons, the approach used by all of these parties (and probably more in the future) is to sign a relatively simple boot loader (called shim) that has the effect of adding checks for its own key to the keys held in the firmware. This means that follow-on boot loaders (like GRUB) can be signed using keys that the Linux vendor controls, rather than with Microsoft's keys. In most cases, a chain of trust is maintained up through the kernel, meaning that GRUB requires that the kernel (and sometimes kernel modules) must be signed with the Linux vendor's keys. RH/Fedora, Canonical/Ubuntu, and Garrett have all already released signed versions of shim, but each one includes a different built-in key, and so will launch only the programs and kernels released by that vendor. (See below for extensions, though.)
The Linux Foundation's approach is a little different, in that its PreBootloader program doesn't require signing of the EFI binaries; instead, it requires that the user who's physically present when the computer boots authorize launching a given binary. Although the LF was aiming for a release some time ago, they ran into some technical difficulties, and since then they seem to have made significant changes to their program. So far they haven't released a signed version of PreBootloader, although its source code is available.
The upshot of all this is that simply replacing Mint's GRUB with Ubuntu's or Fedora's GRUB won't do you a bit of good, even if you include Ubuntu's or Fedora's shim. The reason is that Ubuntu's or Fedora's signed GRUB will refuse to launch Mint's unsigned kernels. In principle, you could use Ubuntu's or Fedora's signed kernels instead of Mint's kernels, but then you've got the question of how to deal with kernel upgrades, how to create an initial RAM disk, etc. IMHO, this is not a viable long-term solution.
There is another approach, though: Fedora's and Garrett's versions of shim include the ability to load arbitrary keys, known as machine owner keys (MOKs), and store them in NVRAM. Thus, you can create your own MOK (with both public and private components), add it to shim's MOK list, and sign whatever binaries and kernels you like. In theory, signing Mint's GRUB (which doesn't check Secure Boot signatures) should get any kernel to boot -- but of course that slighly increases the risk, should pre-boot malware begin to target Linux. Alternatively, you could use a boot loader that verifies signatures via shim and sign your own kernels.
Currently, setting this up for Mint is a bit complex. See my Web page on the topic
for details; or my page on using rEFInd with Secure Boot
if you're interested in using rEFInd as your boot manager. If you want to use this approach, I strongly recommend installing Mint with Secure Boot disabled and then setting it up in your working Mint. Trying to retrofit Secure Boot into the Mint installer just adds layers of complexity to the problem.