I'd like to know or know where I can find a good explanation of GPT. With MBR there was partition types. Not with GPT. There is fs-type and flags (anything else?), which seem to over lap. Can I mark a partition as raid and then set fs-type to fat32? Can all flags only be set one at a time? Or can more than one flag be set?

Using parted, one cannot set boot and raid flags on the same partition - perhaps for a good reason. I know basically how to use GPT. I'd like to know why it works that way.


GPT has partition type codes just like MBR; the difference is that they're 128-bit GUIDs instead of 8-bit integers. But they serve the same purpose.

GNU Parted hides them from you, though. Those flags you see, like "boot" and "raid", are specific to Parted. When you set the "boot" flag, it actually sets the partition's type code to the GUID for an EFI System partition. When you set the "raid" flag, it sets the partition's type code to a different GUID that indicates a Linux software RAID component device. That's why those flags (and a number of others that control the partition type) are mutually exclusive.

I don't really like Parted, both for its strange way of exposing GPT type codes and because it lacks some conveniences compared to fdisk (like being able to type "+10G" to specify a partition's end relative to its start). For GPT partitioning, I use "gdisk", which is a lot like the conventional fdisk, but for GPT. In gdisk, you can set a partiton's type either by specifying the GUID itself, or by choosing from a table of shorthand numbers that's similar to the one you get by typing 'L' in fdisk.

  • Very useful info. So I suppose it is really GRUBs fault for coming up with the funky system where by you cannot mark a partition bootable and RAID. I recently understood why biosgrub exists in the first. It's to let non-EFI bioses boot GPT. – d-_-b Oct 20 '11 at 7:18
  • @sims: It doesn't really make sense to set the bootable flag on a RAID partition, even on an MBR disk where it's possible. The bootable flag means that the partition's first sector contains executable boot code that the MBR's boot code should load and run. That's how (non-EFI) Windows booting works, but it's not true of a Linux installation unless you've installed GRUB to a partition instead of to the MBR, which is uncommon. (And partitions never contain boot code on an EFI disk, which is why Parted's "bootable" flag means something completely different for those.) – Wyzard Oct 20 '11 at 16:31
  • It makes sense and works well with an MBR partition - partition type is set to raid, and when it's marked as bootable, you can boot off of it. This way you can have a bootable mirrored disk. This is what I also achieved with GPT by using one small partition on each disk set as bios_grub and installing grub on each partition. It's not well documented or clear that this is how it should be done. I think that is pretty lame. – d-_-b Oct 21 '11 at 5:08
  • @sims: The ability to boot from a RAID partition has nothing to with the bootable flag; the only thing that cares about that flag is the Microsoft MBR code that you overwrote when you installed GRUB. What makes it possible to boot from a RAID partition on an MBR disk is that GRUB's core.img gets installed in the "hidden sectors" in the first track, and it contains a driver for reading Linux RAID arrays. On a GPT disk, there are no hidden sectors, so core.img goes in the bios_grub partition instead. (You don't need it on both disks, just the one the BIOS is set to boot from.) – Wyzard Oct 21 '11 at 6:34
  • If you want fail over, it's a good idea to have it on all members of the mirror. – d-_-b Oct 23 '11 at 13:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.