I am formatting an SSD for use in a Linux system and I see that there is a distinct gdisk code (8302) for the /home partition if one is created. The alternative I suppose would be the "Linux filesystem" (8300) code.
What is the purpose of the distinct code for the /home partition?
There is no purpose, just convenience, and you may use any code you like.
I quote below a great answer by Rod Smith, the author of GPT fdisk, which explains the whole subject:
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)
fdiskas 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 theioption ingdisk, 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/fstabisn'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 thebios_grubflag in libparted). This type code identifies a partition used by GRUB, and when you rungrub-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.
The need for a code for /home and other partitions is stated here by Rod Smith who created and up to now (2020) contribute to the code of gpt fdisk. This is from him in 2011:
I've recently discovered that when Windows reads a GPT disk with Linux partitions on it, those partitions are given drive letters and show up as unformatted. This situation can happen with removable disks or when Linux and Windows dual-boot on a UEFI-based computer. Because UEFI is becoming more common, this situation is also becoming more common. This strikes me as a disaster waiting to happen; sooner or later, somebody is going to trash a Linux installation by opting to format a Linux partition in Windows.
This problem occurs because Linux partitioning tools (libparted and my own GPT fdisk) give Linux partitions the same partition type code GUID used by Windows for its filesystem partitions (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7). Linux has its own GUID type codes for other partition types, such as RAID, LVM, and swap space.
Thus, it seems to me that Linux needs its own partition type code GUID for filesystem partitions on GPT disks, much as it has its own MBR partition type code for filesystems (0x83 on MBR). I'd like to implement such a change in my own program, but I don't want to do this unilaterally. Assuming there's no unusual protocol for creating partition type code GUIDs, I suggest the following be used:
0FC63DAF-8483-4772-8E79-3D69D8477DE4
That's just a partition-unique GUID for a partition I created on a test disk using GNU Parted 3.0.
If you have a look at the code of parttypes.cc, you will notice all the codes for Linux and others.
List of Linux partitions codes
0x8200, "0657FD6D-A4AB-43C4-84E5-0933C84B4F4F", "Linux swap"); // Linux swap (or Solaris on MBR) 0x8300, "0FC63DAF-8483-4772-8E79-3D69D8477DE4", "Linux filesystem"; // Linux native 0x8301, "8DA63339-0007-60C0-C436-083AC8230908", "Linux reserved"; 0x8302, "933AC7E1-2EB4-4F13-B844-0E14E2AEF915", "Linux /home"; // Linux /home (auto-mounted by systemd) 0x8303, "44479540-F297-41B2-9AF7-D131D5F0458A", "Linux x86 root (/)"; // Linux / on x86 (auto-mounted by systemd) 0x8304, "4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709", "Linux x86-64 root (/)"; // Linux / on x86-64 (auto-mounted by systemd) 0x8305, "B921B045-1DF0-41C3-AF44-4C6F280D3FAE", "Linux ARM64 root (/)"; // Linux / on 64-bit ARM (auto-mounted by systemd) 0x8306, "3B8F8425-20E0-4F3B-907F-1A25A76F98E8", "Linux /srv"; // Linux /srv (auto-mounted by systemd) 0x8307, "69DAD710-2CE4-4E3C-B16C-21A1D49ABED3", "Linux ARM32 root (/)"; // Linux / on 32-bit ARM (auto-mounted by systemd) 0x8308, "7FFEC5C9-2D00-49B7-8941-3EA10A5586B7", "Linux dm-crypt"; 0x8309, "CA7D7CCB-63ED-4C53-861C-1742536059CC", "Linux LUKS"; 0x830A, "993D8D3D-F80E-4225-855A-9DAF8ED7EA97", "Linux IA-64 root (/)"; // Linux / on Itanium (auto-mounted by systemd) 0x830B, "D13C5D3B-B5D1-422A-B29F-9454FDC89D76", "Linux x86 root verity"; 0x830C, "2C7357ED-EBD2-46D9-AEC1-23D437EC2BF5", "Linux x86-64 root verity"; 0x830D, "7386CDF2-203C-47A9-A498-F2ECCE45A2D6", "Linux ARM32 root verity"; 0x830E, "DF3300CE-D69F-4C92-978C-9BFB0F38D820", "Linux ARM64 root verity"; 0x830F, "86ED10D5-B607-45BB-8957-D350F23D0571", "Linux IA-64 root verity"; 0x8310, "4D21B016-B534-45C2-A9FB-5C16E091FD2D", "Linux /var"; // Linux /var (auto-mounted by systemd) 0x8311, "7EC6F557-3BC5-4ACA-B293-16EF5DF639D1", "Linux /var/tmp"; // Linux /var/tmp (auto-mounted by systemd)
The purpose of Linux partition type codes defined in the Discoverable Partitions Specification is to make writing /etc/fstab obsolete for most systems. It’s a case of convention over configuration.
Systemd added systemd-gpt-auto-generator back in 2014 in version 211. This generator creates .mount units from GPT partitions on the boot drive.
So you can use these codes on your GPT-partitioned drive today, not touch /etc/fstab at all (it can be totally empty), and still have separate partitions for /home, /srv, /var, /var/tmp that will be discovered and mounted automatically. These partitions can have any supported filesystem. They can also be LUKS-encrypted. Swap partitions are also discovered automatically.
For further convenience, the generator also mounts the EFI System Partition at /boot in most cases.
Theoretically you can also have it discover the / (root) partition, but that’s a little more complicated. I’d guess it still requires an initramfs in most situations. Otherwise, the root=/dev/whatever kernel parameter is still required.
