GDisk Hex Codes
During the use of gdisk, there an option to specify the hex code. I want to know what it is and why it's needed, see below. So for example, if I am creating a software RAID on my drive, I assume I need code fd00. But why? What is it, and do I have to use it? Why can I not create my raid array using 8300 (whatever that means)?
Command (? for help): n
Partition number (1-128, default 1):
First sector (34-5860533134, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-5860533134, default = 5860533134) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): L
0700 Microsoft basic data 0c01 Microsoft reserved 2700 Windows RE
4100 PowerPC PReP boot 4200 Windows LDM data 4201 Windows LDM metadata
7501 IBM GPFS 7f00 ChromeOS kernel 7f01 ChromeOS root
7f02 ChromeOS reserved 8200 Linux swap 8300 Linux filesystem
8301 Linux reserved 8302 Linux /home 8400 Intel Rapid Start
8e00 Linux LVM a500 FreeBSD disklabel a501 FreeBSD boot
a502 FreeBSD swap a503 FreeBSD UFS a504 FreeBSD ZFS
a505 FreeBSD Vinum/RAID a580 Midnight BSD data a581 Midnight BSD boot
a582 Midnight BSD swap a583 Midnight BSD UFS a584 Midnight BSD ZFS
a585 Midnight BSD Vinum a800 Apple UFS a901 NetBSD swap
a902 NetBSD FFS a903 NetBSD LFS a904 NetBSD concatenated
a905 NetBSD encrypted a906 NetBSD RAID ab00 Apple boot
af00 Apple HFS/HFS+ af01 Apple RAID af02 Apple RAID offline
af03 Apple label af04 AppleTV recovery af05 Apple Core Storage
be00 Solaris boot bf00 Solaris root bf01 Solaris /usr & Mac Z
bf02 Solaris swap bf03 Solaris backup bf04 Solaris /var
bf05 Solaris /home bf06 Solaris alternate se bf07 Solaris Reserved 1
bf08 Solaris Reserved 2 bf09 Solaris Reserved 3 bf0a Solaris Reserved 4
bf0b Solaris Reserved 5 c001 HP-UX data c002 HP-UX service
ea00 Freedesktop $BOOT eb00 Haiku BFS ed00 Sony system partitio
ef00 EFI System ef01 MBR partition scheme ef02 BIOS boot partition
Press the key to see more codes:
fb00 VMWare VMFS fb01 VMWare reserved fc00 VMWare kcore crash p
fd00 Linux RAID
kyodake's answer is correct, but it's also rather MBR-centric. Under GPT, the same principles apply -- that is, a partition type code identifies the intended purpose of a partition. The difference is that GPT type codes are 128-bit GUIDs, vs. the 8-bit codes used under MBR. The nature of GUIDs means that it's not necessary to register codes with a central authority to avoid collisions; two GUIDs are statistically very unlikely to be identical by accident.
AFAIK, there is no official repository of GPT type codes, but they are documented on the Wikipedia page about GPT. One disadvantage of GPT type codes is that, as GUIDs, they're long and awkward -- for instance, 0FC63DAF-8483-4772-8E79-3D69D8477DE4 for Linux filesystem data, vs. 0x83 for the MBR equivalent. Thus, most tools for partitioning GPT disks use some form of "shorthand" or "natural-language translation" in their user interfaces. I'm the author of GPT fdisk, and as my goal in writing it was to create something that was as similar to (MBR) fdisk as possible, I took the approach of using MBR codes as a base; however, because the correspondence between GPT and MBR type codes isn't 1:1, I multiplied the MBR type codes by 0x100 to get the GPT equivalents. Thus, MBR's 0x83 became 8300. This also enables related follow-on codes that don't exist in MBR, such as 8301, 8302, etc. These codes are easy to use for people who are already familiar with the MBR equivalents, but they're admittedly arbitrary for people who don't know the MBR codes. Internally, GPT fdisk translates these codes to GUIDs. You can see the actual GUIDs by viewing detailed partition information (via the i option in gdisk, for instance). You can also enter an arbitrary GUID rather than use the GPT fdisk four-character codes, if you like or if you need to use a code that GPT fdisk doesn't support.
Other tools use other approaches. The libparted library (and thus parted, GParted, and other tools based upon libparted) translates some type codes to "flags" and completely hides other codes. This helps simplify things for some users, but it renders some tasks impossible -- for instance, you can't set an arbitrary type code with anything based on libparted. OS X's Disk Utility translates known GUIDs to plain-text descriptions. (IIRC, when you create a partition it sets an appropriate type code based on the filesystem created in a partition, similar to what GParted does.)
For the most part, Linux doesn't use type codes, for either MBR or GPT. That is, you can put your standard Linux filesystem on a (GPT fdisk) 8300 partition, or use 0700 (as was common in the past), or assign your own random GUID. Similar comments apply to RAID, LVM, swap, and other partition types. There are a few exceptions to this rule, though. For one, distribution installers often look at and set type codes, so you may need the right type code on a partition before it will be used properly. Another exception is that systemd is starting to make use of type codes as a fallback if /etc/fstab isn't properly configured. (That's where most of GPT fdisk's 830x codes originate -- they're part of the Discoverable Partitions Specification, which is a Freedesktop/systemd initiative.) Currently, Ubuntu is just using the main Linux filesystem type code (8300 in GPT fdisk) for filesystems, plus the appropriate codes for LVM, RAID, swap, etc. One big exception to the "Linux doesn't use type codes" rules is the BIOS Boot Partition code (21686148-6449-6E6F-744E-656564454649; ef02 in GPT fdisk or the bios_grub flag in libparted). This type code identifies a partition used by GRUB, and when you run grub-install, GRUB will install part of itself to that partition. If you install GRUB on a BIOS-booting system with a GPT disk, a BIOS Boot Partition must normally be present. (There are ways around this rule, though.) More importantly, if you mistakenly set this type code on the wrong partition, that partition will be damaged when you install GRUB! I've seen quite a few people make that mistake in various online forums.
Where type codes become more important is when dealing with other OSes. Windows and OS X, for instance, tend not to touch partitions with type codes they don't recognize. Their list of type codes excludes common Linux-specific type codes, so using a Linux-specific type code helps reduce the risk that Windows or OS X will trash your Ubuntu installation. These OSes don't care if you use the GPT fdisk 8300 or fd00 code, though. Problems can arise if you use codes that are recognized by these other OSes. For instance, at one time the Linux filesystem type GUID (0FC63DAF-8483-4772-8E79-3D69D8477DE4) did not exist. I created it and pushed it into both my own GPT fdisk and libparted because the common practice of using the "Microsoft Basic Data" type code (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) was causing problems in dual-boot setups. Specifically, certain Windows tools would think the Linux partition was a damaged or un-initialized Windows partition and offer to prepare it. User error at this prompt would be disastrous. See this page of mine for more on this subject.
Lists of assigned partition types to be used in the partition table were originally maintained by IBM and Microsoft internally.
When the market of PC operating systems and disk tools grew and liberated, other vendors had a need to assign special partition types to their products as well.
Several industry experts in the 1990s started to research partition types and published partition type lists in order to help document the industry de facto standard and thereby reduce the risk of further conflicts.
It is up to an operating system's boot loader and/or kernel how to interpret the value. So the table specifies which operating systems or disk-related products originally introduced an ID and what file system or special partition type they mapped it to.
Partition ID: 83h. Type: file system. Origin: GNU/Linux. Description: any native Linux file system.
Partition ID: FDh. Origin: GNU/Linux. Supported: Linux. Description: Linux RAID superblock with auto-detect.