Four days before my wedding, I spent some time researching booting a PC from a large hard disk, where large means "larger than two Terabytes". These days, single disks are approaching this size, so we are near the state where this issue pops up for your run-of-the-mill computer rather than the data store RAID. Today, the per-gigabyte price is however still significantly cheaper if you go for a 1 T or an 1.5 T disk.
The old blog article shows that I spent considerable time in finding out today's limitations below the 2 T limit by using conventional partitioning schemes to boot a 2 T disk. Since I don't have this much storage available at the moment, I had to use virtualization and to take advantage of nearly empty virtual disks taking up much less space than their raw capacity suggests. This works fine as long as you don't start actually using the disk.
Back then, the only combination that worked for a raw disk larger than 2 T (only using the first 2 T) was Virtualbox and grub 0 (now grub-legacy). I regret to admit that the results of my experiments from June are not any more reproducible (most probably due to changes in Virtualbox since then) and that I was not able to boot any disk larger than 2 T any more, even if the partitions were well below the 2 T limit. I chose to ignore these results and to finally start the GPT research.
Four months later, I have again found the time to finish the research on the GPT. But first a little flashback to June outlining why the classic PC-style partition table has finally reached its end. Its 32 bit sector numbers preclude us from having partitions that reach beyond the 2 TB barrier.
The GUID partition table (GPT), has been invented to cope with disks that are larger than 2 TB. Unfortunately, legacy PCs (nearly every box sold today) cannot boot a "pure GPT", since they lack the EFI firmware which can be used to boot from a pure GPT. EFI firmware has been developed to ultimately replace the PC BIOS and is already in use on Apple hardware. But most PCs sold today still have a "classic BIOS" and therefore need a workaround to boot from a disk partitioned with GPT.
On Linux, the tool to create a GPT and to partition the disk within the GPT is GNU parted. It is available with a text console front end which reminds of the classic Linux fdisk found in util-linux, and with a GTK and a QT front end. A curses-like front end as we know from util-linux' cfdisk is unfortunately missing, which makes parted somewhat awkward to use at installation time when one doesn't have a GUI yet (or did never plan to actually install a GUI on the machine). This article gives a nice introduction about how to use parted to create a GPT.
A disk having a GPT looks to a classic partitioning tool like this:
this is a big primary partition of 2 TB size with partition ID 0xee. util-linux' fdisk will also print prominent warnings that it won't be able to partition that disk. Other partitioning tools probably won't.Device Boot Start End Blocks Id System /dev/sda1 1 267350 2147483647+ ee GPT
You need to cater for two caveats before the system can actually boot: grub 2 strongly suggests that you use a "BIOS Boot Partition " for grub 2's later stages. That partition needs to be at last 32 KB large. Additionally, I wasn't able to boot from a partition filling the entire 5.7 TB disk, so I suspect that the boot file system needs to be inside the first two TB. This is how my test disk was finally partitioned:
It is kind of a challenge to coax parted into creating partitions that are directly adjacent to each other. I didn't find a way to do this short of setting parted's unit to sectors and manually typing the exact sector number.# parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 5243GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 1000kB 983kB bios_grub bios_grub 2 1000kB 1000GB 1000GB ext3 boot 3 1000GB 5243GB 4243GB ext3 data #
After the disk was partitioned, I created the ext3 file systems on the two big partitions. mke2fs takes quite some memory (256 MB memory were not enough for the virtual machine, resulting into a not very helpful "killed" message on mke2fs) and time (like two hours for the larger of the two file systems), but generates the file systems just fine. They are mounted just as any other file system:
and grub 2 can be installed just fine by using grub-install /dev/sda after temporarily mounting /dev/sda2 as /boot.# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 917G 317M 870G 1% /mnt/sda2 /dev/sda3 3.8T 195M 3.7T 1% /mnt/sda3 #
This setup boots grml just fine, and I suspect that any Linux OS can be booted like this as well. I guess that it will be kind of a challenge do dual-boot a disk this large with any other OS.