Phil Meyer wrote:
There is a lot of confusion available from articles on the Internet
about whether or not a greater than 2TB disk can be made bootable in Linux.
In order to go that large, the disk must be labelled, via partd, as type
Ok so far.
Not really. x86 BIOSes don't know what to do with GPT-labeled disks. You need
an EFI system (rather than BIOS) to boot from a GPT disk. At the moment that's
mostly Itanium and certain niche x86 boards.
Now, is it possible to use fdisk to cut off 100MB or so for a normal
It seems that labelling a disk as GPT does not stomp the MBR, but does
affect the partition table. Is this correct?
GPT reserves the first sector for a "Legacy MBR", which is basically intended to
keep legacy disk utilities from doing stupid things to GPT disks. It isn't
really used for booting. EFI uses a FAT partition to hold the bootloader.
If I create a 100MB partition using fdisk, and then label the disk as
GPT, can I start the large partition with the first cylinder > than what
I cut off for /boot and expect it to be seen?
Anaconda complains that GPT is not bootable. Is that system specific,
BIOS specific, anaconda error reading the BIOS, ???
You need a GPT-aware firmware such as EFI for it to be bootable. If your system
has a BIOS, it won't work. The exception is that on some x86 systems, EFI will
emulate a BIOS for compatibility with OSes that expect a BIOS, so if you can get
it to actually act like EFI rather than a BIOS, you could make this work. I'm
told this is true with some Intel Macs, but I've never played with it myself.
Here is the specific scenario:
An intel based server, with 10 1TB drives attached to a SATA RAID
device. The RAID is level 5 with 9 drives and a hot spare.
What the system sees, is one device of ~8TB.
Is it possible to boot from the device, AND have all but /boot as one
Probably not. You have two choices:
a) Partition off a small chunk of the array in the RAID firmware.
b) Add a boot disk.
For a server that does anything important, (a) is probably the safe way to go.
If I had this problem on a personal system, I'd dig up my old 64 MB USB key and
choose (b). I've done it before, and it's just fine for /boot as long as
not hotplugging it or suspending and resuming the system.