On May 13, 2014, at 3:27 PM, Stephen Morris <samorris@xxxxxxxxxxxxxxx> wrote:
On 05/13/2014 01:58 PM, Chris Murphy wrote:
On May 12, 2014, at 3:05 PM, Stephen Morris <samorris@xxxxxxxxxxxxxxx> wrote:
On 05/12/2014 09:36 AM, Chris Murphy wrote:
On May 9, 2014, at 6:05 PM, Stephen Morris <samorris@xxxxxxxxxxxxxxx> wrote:
The one limitation with GPT as I understand it is that in order to use GPT you must also have UEFI active in the Bios.
No. First, BIOS ≠ UEFI they are not the same thing and it's easy to remember because there's nothing basic about UEFI. Second, while it's true GPT is defined in the UEFI spec, it's entirely up to the BIOS firmware implementation whether it'll work. There's no blanket proscription using GPT on BIOS computers, I have an old Dell Latitude laptop that permits booting with GPT partitioned drives.
But there are enough firmwares out there that crater when encountering some aspect of GPT partitions, that on BIOS computers, the Fedora installer doesn't use GPT by default unless the drive is larger than ~2.2TB.
From experience I have also found that you can't install the windows system partition on a GPT device and I thought I read somewhere that you also can't put Linux /boot on GPT either.
The first part is true, the second part is not true. Windows' installer will only install and boot from GPT drives on UEFI computers, and boot from MBR drives on BIOS computers.
I'm probably a bit off topic here but Win 8 would not install on my machine onto a GPT device with UEFI enabled in the bios. I had to finish up configuring the partition on the 2TB hard disk with a DOS partition and also turn off UEFI because I could not boot my system because UEFI did not support my Nvidia GTX 650 graphics card.
It's not off topic but the vernacular is incorrect, no doubt due to manufacturers who have been using it incorrectly. Many of them continue to refer to firmware updates for UEFI based firmwares as BIOS updates.
If you have UEFI firmware you do not have a BIOS firmware. If you have BIOS firmware you don't have UEFI firmware. If you have UEFI firmware you can't enable or disable it, although some manufacturers have used this UI convention to indicate whether a UEFI Compatibility Support Module is to be used. The CSM presents an (emulated) BIOS interface to an OS, and it's there for legacy OS support for OS's like Windows XP which have no idea what UEFI is or how to talk to it.
The fact your firmware with UEFI "enabled" (CSM disabled) caused Windows 8 install failure with a GPT is a bug either in the Windows 8 installer, or with the firmware. If you have already confirmed that you have the latest firmware applied to your hardware, I'd take my case to their support service because there's no good reason why you should have to install Windows 8 with a compatibility module enabled.
I'm leaning towards the bug being in the windows installer, as when I looked at the details for the error returned by the installer, the installer's explanation of the error was that it could not install on a GPT device, so given that it was the installer itself that was saying it couldn't do it I'd be leaning towards it as being the culprit.
Something isn't right because if the CSM/legacy mode is not activated, then the Windows install can only have a conversation with the firmware using UEFI protocol, so it'd definitely know it was UEFI firmware. And it would disallow installation to an MBR device.
The only time I've ever gotten the message from the Windows installer that it could not install to a GPT device is when it was booting from BIOS hardware, or UEFI hardware with CSM/BIOS mode enabled.
You could boot from any Fedora media and issue the command efibootmgr -v and see what it says. You should either burn to a disk, or use dd to create a USB stick. Either of those methods will create EFI and BIOS bootable media. Other methods, this gets tricky. If you get some sensible result then the computer is UEFI booted. If you get an error message, then it's not UEFI booted.
The firmware in my motherboard did not support disabling UEFI out of the box, I had to get an update to provide that functionality. The update provided the ability to only use UEFI, only use Legacy Bios, to use UEFI first then legacy, or use Legacy first then use UEFI (this option doesn't really make a lot of sense).
*sigh* what a clusterfuck. Well, if you have it set to use only UEFI then that certainly should compel Windows to install to a GPT disk. Or there are still firmware bugs.
The ability to turn UEFI off was critical for my system as I could not use my graphics card with UEFI as it was not supported by the built in signature database, and being a relatively new purchase I was not prepared to buy another one, also from what I have read, if using multiple Linux distros its potentially critical to turn UEFI off.
I don't know what signature database you mean, but so long as you're not depending on Secure Boot, signed binaries don't matter on either Windows or Linux. The better alternative is to just not use Secure Boot if there are unsigned (possibly proprietary) 3rd party drivers for your graphics card. But if it's the case that the proprietary driver doesn't work with UEFI booting, then to use it yes you'd need to CSM-BIOS boot in which case you'll need to have an MBR partitioned drive in order to install Windows.
From what I have read Fedora was going to purchase the signature files from Microsoft (as I understand it the owner of UEFI, I have seen it stated explicitly to this effect) to enable UEFI support, whereas Ubuntu is going to go down the path of self signing rather than purchase the necessary licenses from Microsoft. I use both of these distributions as well as Win 8 on the one machine.
That's not correct. Microsoft does not own UEFI. You can find the member list here:
http://uefi.org/members
Again, the signing issues relate only to UEFI Secure Boot. The only key that's reliably already installed on x86_64 UEFI hardware is the Microsoft key, since in order to use the Windows logo that hardware must carry the Microsoft key. The Microsoft Windows hardware certification requirements require that there's both a firmware option to disable Secure Boot as well as enabling other keys to be enrolled with the firmware. But getting the hardware vendors to pre-include a Fedora key was considered a.) difficult and b.) unfair to other smaller distributions who almost certainly wouldn't convince manufacturers to include their key.
To make things easier for users, Fedora Project is registered with a Microsoft hardware dev account which offers a binary signing service. While there is a fee, it actually goes to Verisign, who is ultimately the certificate issuer, not Microsoft. The single thing Fedora gets signed through this service with the Microsoft key is shim.efi which is the first thing the firmware loads. Everything else, including grub, the kernel, and kernel modules, are signed with the Fedora key.
If you read this:
https://wiki.ubuntu.com/SecurityTeam/SecureBoot
It looks like Canonical does the same thing. They have Microsoft sign Canonical's shim with the Microsoft key, and then shim.efi verifies grubx64.efi which is signed with Canonical's key. And so on, everything else being signed with Canonical's key. It's the same method as Fedora.
