Hi all;
we've just ordered a new server (http://www.spectrumservers.com/ssproducts/pc/viewPrd.asp?idcategory=26&i...)
Originally I tried to simply upgrade an older server with more drive space, I installed 6 4TB drives and did a new OS install but the OS would not allow me to configure more than 2TB per drive.
Subsequent research leads me to conclude that if the bios supports UEFI and the installer boots as such then the installer should see 4TB drives without any issues. I'm also assuming that any server I order today (i.e. a more modern server) should ship with UEFI support in the bios.
Are my conclusions above per UEFI correct?
Thanks in advance
On 2014-05-06 18:18, CS_DBA wrote:
Hi all;
we've just ordered a new server (http://www.spectrumservers.com/ssproducts/pc/viewPrd.asp?idcategory=26&i...)
Originally I tried to simply upgrade an older server with more drive space, I installed 6 4TB drives and did a new OS install but the OS would not allow me to configure more than 2TB per drive.
Subsequent research leads me to conclude that if the bios supports UEFI and the installer boots as such then the installer should see 4TB drives without any issues. I'm also assuming that any server I order today (i.e. a more modern server) should ship with UEFI support in the bios.
Are my conclusions above per UEFI correct?
Thanks in advance
I purchased a 3TB drive last year and it was partitioned in firmware to 1.5TB partitions. I just purchased two 4TB drives and they are firmware partitioned into a 1.8TB and 2.2TB partitions as I just checked.
Putting the drive into a USB drive holder, I see two drives appear in dmesg with the new 4TB drives.
[520426.457278] sdf: unknown partition table [520426.465781] sde: unknown partition table
I had to use a firmware tool from the manufacturer to convert the drives to a single partition with the 3TB drive. I have not tried the 4TB drive yet.
As my drives were from seagate, I just downloaded their tool and used it. I had to put the drives onto a SATA buss to do the conversion as the software wouldn't work through the USB port.
This may be your problem.
On May 6, 2014, at 6:18 PM, CS_DBA cs_dba@consistentstate.com wrote:
Hi all;
we've just ordered a new server (http://www.spectrumservers.com/ssproducts/pc/viewPrd.asp?idcategory=26&i...)
Originally I tried to simply upgrade an older server with more drive space, I installed 6 4TB drives and did a new OS install but the OS would not allow me to configure more than 2TB per drive.
I don't know what this is referring to when you say "the OS would not allow". The kernel has no problem with 2.2+TB drives. Do you mean the installer? Or some utility? What utility?
If the drives do not have a partition map at all, anaconda (the installer) will use GPT on 2.2+TB drives. So long as the BIOS doesn't puke on GPT (some of them do), and can at least load GRUB2 from that point on it will work as GRUB2 supports GPT, so does the kernel, and thus you can use big drives as boot drives.
If the BIOS pukes on GPT, the alternatives to buying a new computer is to use a smaller drive for booting, but then use the big drives as data drives, using either GPT to partition them, or no partition map at all. You can directly use mdadm or lvm (pvcreate) or Btrfs on an unpartitioned drive.
Subsequent research leads me to conclude that if the bios supports UEFI and the installer boots as such then the installer should see 4TB drives without any issues. I'm also assuming that any server I order today (i.e. a more modern server) should ship with UEFI support in the bios.
Not necessarily, although they are now a lot more common than they were even a year ago.
Are my conclusions above per UEFI correct?
Yes although I'm not sure you need a new computer to fix this problem.
Chris Murphy
On 05/08/2014 12:28 PM, Chris Murphy wrote:
On May 6, 2014, at 6:18 PM, CS_DBA cs_dba@consistentstate.com wrote:
Hi all;
we've just ordered a new server (http://www.spectrumservers.com/ssproducts/pc/viewPrd.asp?idcategory=26&i...)
Originally I tried to simply upgrade an older server with more drive space, I installed 6 4TB drives and did a new OS install but the OS would not allow me to configure more than 2TB per drive.
I don't know what this is referring to when you say "the OS would not allow". The kernel has no problem with 2.2+TB drives. Do you mean the installer? Or some utility? What utility?
If the drives do not have a partition map at all, anaconda (the installer) will use GPT on 2.2+TB drives. So long as the BIOS doesn't puke on GPT (some of them do), and can at least load GRUB2 from that point on it will work as GRUB2 supports GPT, so does the kernel, and thus you can use big drives as boot drives.
If the BIOS pukes on GPT, the alternatives to buying a new computer is to use a smaller drive for booting, but then use the big drives as data drives, using either GPT to partition them, or no partition map at all. You can directly use mdadm or lvm (pvcreate) or Btrfs on an unpartitioned drive.
Subsequent research leads me to conclude that if the bios supports UEFI and the installer boots as such then the installer should see 4TB drives without any issues. I'm also assuming that any server I order today (i.e. a more modern server) should ship with UEFI support in the bios.
Not necessarily, although they are now a lot more common than they were even a year ago.
Are my conclusions above per UEFI correct?
Yes although I'm not sure you need a new computer to fix this problem.
Agreed, we didn't order the new server to fix this issue, we ordered the server to upgrade another older server. However I wanted to address this issue at the same time...
Chris Murphy
Hi, As I understand hard disk processes in order to use hard disks bigger than 2TB in a single partition you must format those hard disks using a GPT partition table. From what I have read the traditional DOS partition table is only capable of addressing up to 2TB, and GPT was developed to overcome this limitation. 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. 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.
regards, steve
On 05/09/2014 06:39 AM, CS_DBA wrote:
On 05/08/2014 12:28 PM, Chris Murphy wrote:
On May 6, 2014, at 6:18 PM, CS_DBA cs_dba@consistentstate.com wrote:
Hi all;
we've just ordered a new server (http://www.spectrumservers.com/ssproducts/pc/viewPrd.asp?idcategory=26&i...)
Originally I tried to simply upgrade an older server with more drive space, I installed 6 4TB drives and did a new OS install but the OS would not allow me to configure more than 2TB per drive.
I don't know what this is referring to when you say "the OS would not allow". The kernel has no problem with 2.2+TB drives. Do you mean the installer? Or some utility? What utility?
If the drives do not have a partition map at all, anaconda (the installer) will use GPT on 2.2+TB drives. So long as the BIOS doesn't puke on GPT (some of them do), and can at least load GRUB2 from that point on it will work as GRUB2 supports GPT, so does the kernel, and thus you can use big drives as boot drives.
If the BIOS pukes on GPT, the alternatives to buying a new computer is to use a smaller drive for booting, but then use the big drives as data drives, using either GPT to partition them, or no partition map at all. You can directly use mdadm or lvm (pvcreate) or Btrfs on an unpartitioned drive.
Subsequent research leads me to conclude that if the bios supports UEFI and the installer boots as such then the installer should see 4TB drives without any issues. I'm also assuming that any server I order today (i.e. a more modern server) should ship with UEFI support in the bios.
Not necessarily, although they are now a lot more common than they were even a year ago.
Are my conclusions above per UEFI correct?
Yes although I'm not sure you need a new computer to fix this problem.
Agreed, we didn't order the new server to fix this issue, we ordered the server to upgrade another older server. However I wanted to address this issue at the same time...
Chris Murphy
Stephen Morris writes:
<snip>
From experience I have also found that you can't install thewindows system partition on a GPT device and I thought I read somewhere that you also can't put Linux /boot on GPT either.
I don't know about the rest of it, but *this* sure doesn't match my experience. Windows systems most definitely *do* install on GPT partitions, and in fact the Windows installer will complain if you try to install on a DOS-style partition with a GPT-capable BIOS. Further, Linux /boot most definitely can be on a GPT partition--the notebook I'm writing this on has just this set-up.
On 05/10/2014 10:16 AM, benfell@parts-unknown.org wrote:
Stephen Morris writes:
<snip>
From experience I have also found that you can't install thewindows system partition on a GPT device and I thought I read somewhere that you also can't put Linux /boot on GPT either.
I don't know about the rest of it, but *this* sure doesn't match my experience. Windows systems most definitely *do* install on GPT partitions, and in fact the Windows installer will complain if you try to install on a DOS-style partition with a GPT-capable BIOS. Further, Linux /boot most definitely can be on a GPT partition--the notebook I'm writing this on has just this set-up.
I could be wrong about Linux as I haven't tried it, it was just the impression I got from net articles, but when I upgraded my system to a 256GB SSD and 2 2TB hard disks, I tried formatting one of the 2TB hard disks to GPT and tried to install Win 8 onto that device, and had the installer explicitly tell me it could not install to a GPT device.
regards, Steve
Stephen Morris samorris@netspace.net.au writes:
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.
I use GPT on all my single-boot Fedora machines. All but one has the traditional BIOS. The traditional BIOS works just fine with GPT formatted disks.
Furthermore, I use just two partitions. Linux swap and ext4 / fs. It works just fine that way. There is no need to make your life more difficult with juggling a bunch of partitions that will need re-sizing down the road.
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.
This is true. My laptop's MS Windows XP doesn't seem to like GPT. Not sure about anything more recent. I only use the XP partition to load updated firmware on consumer devices, so I'm not about to spend money to upgrade an OS I use perhaps once a year.
-wolfgang
Wolfgang S. Rupprecht writes:
This is true. My laptop's MS Windows XP doesn't seem to like GPT. Not sure about anything more recent. I only use the XP partition to load updated firmware on consumer devices, so I'm not about to spend money to upgrade an OS I use perhaps once a year.
My experience would be with Windows 7, which absolutely has to install on GPT.
On 11 May 2014 01:50, benfell@parts-unknown.org wrote:
My experience would be with Windows 7, which absolutely has to install on GPT.
This is not true; I have multiple machines with Win7 and not a single one of them has any GPT disks at all.
It will only install on NTFS, not FAT32 (& is too big to fit onto a FAT16 volume) but that's an entirely different issue.
Liam Proven writes:
It will only install on NTFS, not FAT32 (& is too big to fit onto a FAT16 volume) but that's an entirely different issue.
A Fedora list is the last place I'd expect to get into an argument over what Windows would install on.
But you are confusing partition schemes with file system types. NTFS is not a partition scheme and GPT is not a file system type.
On 05/10/2014 06:50 PM, benfell@parts-unknown.org wrote:
My experience would be with Windows 7, which absolutely has to install on GPT.
Perhaps you mean that Windows 7 has to be _able_ to install on GPT, not that GPT is a requirement. Windows 7 installs just fine on a disk with only a legacy MBR partition table.
On Sat, May 10, 2014 at 09:21:38PM -0500, Robert Nichols wrote:
On 05/10/2014 06:50 PM, benfell@parts-unknown.org wrote:
My experience would be with Windows 7, which absolutely has to install on GPT.
Perhaps you mean that Windows 7 has to be _able_ to install on GPT, not that GPT is a requirement. Windows 7 installs just fine on a disk with only a legacy MBR partition table.
Yes, that's right. I was responding to a claim that Windows couldn't be installed on GPT. Out of context, however, the statement appears entirely wrong.
On 11 May 2014 02:23, benfell@parts-unknown.org wrote:
Liam Proven writes:
It will only install on NTFS, not FAT32 (& is too big to fit onto a FAT16 volume) but that's an entirely different issue.
A Fedora list is the last place I'd expect to get into an argument over what Windows would install on.
But you are confusing partition schemes with file system types. NTFS is not a partition scheme and GPT is not a file system type.
No I most certainly am not!
However, with your comment about Windows 7 requiring GPT, you are, unless you can provide some other explanation. The only software-changeable disk requirement Win7 makes that I could think of was NTFS. WinXP could still be installed on FAT32 or even FAT16 if you wanted; that only changed with Vista/7.
On May 9, 2014, at 6:05 PM, Stephen Morris samorris@netspace.net.au 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. Neither Linux nor GRUB nor any other bootloader I'm aware of, cares if your BIOS computer uses GPT partitioning. It's just a matter of whether the firmware is fussy about it or not.
Quite a few BIOS firmwares don't like the standard GPT because its protective MBR 0xEE entry doesn't have the active bit (boot flag) set. So via parted, anaconda will set this flag even on GPT disks, and this tricks many BIOS firmwares into cooperating. But it causes problems with others, usually UEFI firmware, because strictly speaking 0xEE shouldn't be set as bootable. Anyway it takes testing to know whether it'll work or not.
Chris Murphy
On May 10, 2014, at 5:50 PM, benfell@parts-unknown.org wrote:
Wolfgang S. Rupprecht writes:
This is true. My laptop's MS Windows XP doesn't seem to like GPT. Not sure about anything more recent. I only use the XP partition to load updated firmware on consumer devices, so I'm not about to spend money to upgrade an OS I use perhaps once a year.
My experience would be with Windows 7, which absolutely has to install on GPT.
Not exactly correct. Windows Vista/7/8 will require GPT on UEFI computers, and will require MBR on BIOS computers. And this requirement is only for boot drives. Data drives can use GPT (or MBR) regardless of the firmware type.
Chris Murphy
On 05/12/2014 09:36 AM, Chris Murphy wrote:
On May 9, 2014, at 6:05 PM, Stephen Morris samorris@netspace.net.au 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.
regards, Steve
Neither Linux nor GRUB nor any other bootloader I'm aware of, cares if your BIOS computer uses GPT partitioning. It's just a matter of whether the firmware is fussy about it or not.
Quite a few BIOS firmwares don't like the standard GPT because its protective MBR 0xEE entry doesn't have the active bit (boot flag) set. So via parted, anaconda will set this flag even on GPT disks, and this tricks many BIOS firmwares into cooperating. But it causes problems with others, usually UEFI firmware, because strictly speaking 0xEE shouldn't be set as bootable. Anyway it takes testing to know whether it'll work or not.
Chris Murphy
On May 12, 2014, at 3:05 PM, Stephen Morris samorris@netspace.net.au wrote:
On 05/12/2014 09:36 AM, Chris Murphy wrote:
On May 9, 2014, at 6:05 PM, Stephen Morris samorris@netspace.net.au 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.
Chris Murphy
On 05/13/2014 01:58 PM, Chris Murphy wrote:
On May 12, 2014, at 3:05 PM, Stephen Morris samorris@netspace.net.au wrote:
On 05/12/2014 09:36 AM, Chris Murphy wrote:
On May 9, 2014, at 6:05 PM, Stephen Morris samorris@netspace.net.au 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. 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). 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. 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.
regards, Steve
Chris Murphy
On May 13, 2014, at 3:27 PM, Stephen Morris samorris@netspace.net.au wrote:
On 05/13/2014 01:58 PM, Chris Murphy wrote:
On May 12, 2014, at 3:05 PM, Stephen Morris samorris@netspace.net.au wrote:
On 05/12/2014 09:36 AM, Chris Murphy wrote:
On May 9, 2014, at 6:05 PM, Stephen Morris samorris@netspace.net.au 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.
Chris Murphy
On 05/16/2014 11:06 AM, Chris Murphy wrote:
On May 13, 2014, at 3:27 PM, Stephen Morris samorris@netspace.net.au wrote:
On 05/13/2014 01:58 PM, Chris Murphy wrote:
On May 12, 2014, at 3:05 PM, Stephen Morris samorris@netspace.net.au wrote:
On 05/12/2014 09:36 AM, Chris Murphy wrote:
On May 9, 2014, at 6:05 PM, Stephen Morris samorris@netspace.net.au 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.
Hi Chris, I read an article in a computer magazine that actually said that Fedora was buying a certificate from Microsoft but Canonical were going down the path is self signing rather than purchase the certificate from Microsoft. The same article also said that under UEFI all drivers would have the be signed in order for devices to be used, and quoted the most critical device impacted by this requirement as the graphics card. The article also said that in order to implement the verification UEFI used a database of signatures that were embedded into the firmware. Given your information it appears as though the writer of the article potentially had no idea what they were talking about. The issue I had with my graphics card was, having installed windows, Fedora and Ubuntu from legacy mode in the firmware, I turned UEFI on to test functionality and had booting fail before even getting to the Fedora grub2 boot menu with a message that my graphics card was not supported, so I had to switch back to legacy mode to be able to use my pc.
regards, Steve
Chris Murphy
On May 18, 2014, at 3:50 PM, Stephen Morris samorris@netspace.net.au wrote:
Hi Chris, I read an article in a computer magazine that actually said that Fedora was buying a certificate from Microsoft but Canonical were going down the path is self signing rather than purchase the certificate from Microsoft. The same article also said that under UEFI all drivers would have the be signed in order for devices to be used, and quoted the most critical device impacted by this requirement as the graphics card. The article also said that in order to implement the verification UEFI used a database of signatures that were embedded into the firmware. Given your information it appears as though the writer of the article potentially had no idea what they were talking about.
Unsurprising.
The issue I had with my graphics card was, having installed windows, Fedora and Ubuntu from legacy mode in the firmware, I turned UEFI on to test functionality and had booting fail before even getting to the Fedora grub2 boot menu with a message that my graphics card was not supported, so I had to switch back to legacy mode to be able to use my pc.
OS installs are either UEFI or BIOS based. They aren't interchangeable, so they break if you change the firmware mode setting after installation. But, there are some UEFI implementation where the boot mode is store in NVRAM along with the boot entry. So, we're really deep in the weeds where everyone's going to have different experiences because of highly variable firmware behavior, and even UI.
Windows
-
Chris Murphy -
CS DBA -
David Benfell -
Liam Proven -
Robert Nichols -
Robin Laing -
Stephen Morris -
Wolfgang S. Rupprecht