Linux 主分区代码 8302 的目的是什么？

Question

我正在格式化一个 SSD 以在 Linux 系统中使用，我看到/home分区有一个不同的gdisk代码 (8302)，如果创建了一个。我想另一种选择是“Linux 文件系统”（8300）代码。

/home分区的不同代码的目的是什么？

Answer 1

没有目的，只是方便，您可以使用任何您喜欢的代码。

我在下面引用GPT fdisk 的作者Rod Smith 的一个很好的 回答，它解释了整个主题：

kyodake 的答案是正确的，但它也相当以 MBR 为中心。在 GPT 下，同样的原则适用——也就是说，分区类型代码标识分区的预期用途。不同之处在于 GPT 类型代码是 128 位 GUID，而 MBR 下使用的是 8 位代码。GUID 的性质意味着不需要向中央机构注册代码以避免冲突；两个 GUID 在统计上不太可能偶然相同。

AFAIK，没有 GPT 类型代码的官方存储库，但它们记录在关于 GPT 的维基百科页面上。 GPT 类型代码的一个缺点是，作为 GUID，它们又长又笨拙——例如，0FC63DAF-8483-4772-8E79-3D69D8477DE4 用于 Linux 文件系统数据，而 0x83 用于等效的 MBR。因此，大多数 GPT 磁盘分区工具在其用户界面中使用某种形式的“速记”或“自然语言翻译”。我是 GPT fdisk 的作者，作为我写作的目标，它是创建类似于 (MBR) 的东西fdisk尽可能地，我采取了以MBR代码为基础的方法；但是，由于 GPT 和 MBR 类型代码之间的对应关系不是 1:1，我将 MBR 类型代码乘以 0x100 以获得 GPT 等效项。这样，MBR的0x83就变成了8300。这也使得MBR中不存在的相关后续代码，如8301、8302等，这些代码对于已经熟悉MBR等价物的人来说很容易使用，但是他们对于不知道 MBR 代码的人来说，这无疑是任意的。在内部，GPT fdisk 将这些代码转换为 GUID。您可以通过查看详细的分区信息（例如，通过 中的i 选项gdisk）来查看实际的 GUID 。您还可以输入任意 GUID 而不是使用 GPT fdisk 四字符代码，

其他工具使用其他方法。libparted 库（以及 partedGParted 和其他基于 libparted 的工具）将某些类型代码转换 为“标志”并完全隐藏其他代码。这有助于为某些用户简化事情，但它使某些任务变得不可能——例如，您不能使用基于 libparted 的任何内容设置任意类型的代码。OS X 的磁盘工具将已知的 GUID 转换为纯文本描述。（IIRC，当您创建分区时，它会根据分区中创建的文件系统设置适当的类型代码，类似于 GParted 所做的。）

大多数情况下，Linux 不使用 MBR 或 GPT 的类型代码。也就是说，您可以将标准 Linux 文件系统放在 (GPT fdisk) 8300 分区上，或者使用 0700（过去很常见），或者分配您自己的随机 GUID。类似的注释适用于 RAID、LVM、交换和其他分区类型。不过，这条规则也有一些例外。一方面，发行版安装人员经常查看和设置类型代码，因此您可能需要在分区上正确使用类型代码才能正确使用它。另一个例外是 systemd 开始使用类型代码作为后备，如果/etc/fstab没有正确配置。（这就是大部分 GPT fdisk 830x 代码的来源——它们是可发现分区规范的一部分， 这是 Freedesktop/systemd 的一项倡议。）目前，Ubuntu 只是使用主要的 Linux 文件系统类型代码（GPT fdisk 中的 8300）作为文件系统，加上适当的 LVM、RAID、交换等代码。“Linux不使用类型代码”规则是 BIOS 引导分区代码（21686148-6449-6E6F-744E-656564454649；ef02 在 GPT fdisk 或bios_grublibparted 中的标志）。此类型代码标识 GRUB 使用的分区，当您运行 时grub-install，GRUB 会将自身的一部分安装到该分区。如果在带有 GPT 磁盘的 BIOS 引导系统上安装 GRUB，则通常必须存在 BIOS 引导分区。（不过，有一些方法可以绕过这条规则。）更重要的是，如果您错误地将此类型代码设置在错误的分区上，那么在安装 GRUB 时该分区将被损坏！ 我在各种在线论坛上看到不少人犯了这个错误。

类型代码在处理其他操作系统时变得更加重要。例如，Windows 和 OS X 往往不会接触带有它们不认识的类型代码的分区。他们的类型代码列表不包括常见的 Linux 特定类型代码，因此使用 Linux 特定类型代码有助于降低 Windows 或 OS X 将您的 Ubuntu 安装破坏的风险。不过，这些操作系统并不关心您是使用 GPT fdisk 8300 还是 fd00 代码。如果您使用这些其他操作系统可识别的代码，则可能会出现问题。例如，曾经不存在 Linux 文件系统类型 GUID (0FC63DAF-8483-4772-8E79-3D69D8477DE4)。我创建了它并将它推送到我自己的 GPT fdisk 和 libparted 中，因为使用“Microsoft 基本数据”类型代码 (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) 的常见做法在双引导设置中导致问题。具体来说，某些 Windows 工具会认为 Linux 分区是损坏或未初始化的 Windows 分区，并提供准备它。在此提示下的用户错误将是灾难性的。看关于这个主题的更多信息，我的这个页面。

Answer 2

可发现分区规范中定义的 Linux 分区类型代码的目的是使/etc/fstab大多数系统的写入过时。这是约定优于配置的情况。

Systemdsystemd-gpt-auto-generator于 2014 年在 211 版中添加。此生成器.mount从引导驱动器上的 GPT 分区创建单元。

因此，您现在可以在 GPT 分区的驱动器上使用这些代码，根本不接触/etc/fstab（它可以完全为空），并且仍然有单独的分区用于/home, /srv, /var,/var/tmp将被自动发现和挂​​载。这些分区可以有任何受支持的文件系统。它们也可以是 LUKS 加密的。交换分区也会被自动发现。

为了进一步方便，/boot在大多数情况下，生成器还会安装 EFI 系统分区。

理论上你也可以让它发现/（根）分区，但这有点复杂。我想在大多数情况下它仍然需要一个 initramfs。否则，root=/dev/whatever仍然需要内核参数。

Answer 3

Rod Smith在此/home声明了对和其他分区的代码的需求，他创建了 gpt fdisk 的代码并且直到现在（2020 年）他都为 gpt fdisk 的代码做出了贡献。这是他在 2011 年写的：

我最近发现，当 Windows 读取带有 Linux 分区的 GPT 磁盘时，这些分区会被赋予驱动器号并显示为未格式化。这种情况可能发生在可移动磁盘上，或者在基于 UEFI 的计算机上进行 Linux 和 Windows 双引导时。由于 UEFI 越来越普遍，这种情况也越来越普遍。这让我觉得是一场等待发生的灾难；迟早会有人通过选择在 Windows 中格式化 Linux 分区来破坏 Linux 安装。

出现此问题是因为 Linux 分区工具（libparted 和我自己的 GPT fdisk）为 Linux 分区提供了 Windows 用于其文件系统分区的相同分区类型代码 GUID (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7)。Linux 有自己的 GUID 类型代码用于其他分区类型，例如 RAID、LVM 和交换空间。

因此，在我看来，Linux 需要自己的分区类型代码 GUID 用于 GPT 磁盘上的文件系统分区，就像它有自己的文件系统 MBR 分区类型代码（MBR 上的 0x83）。我想在我自己的程序中实现这样的改变，但我不想单方面这样做。假设没有用于创建分区类型代码 GUID 的异常协议，我建议使用以下内容：

0FC63DAF-8483-4772-8E79-3D69D8477DE4

这只是我使用 GNU Parted 3.0 在测试磁盘上创建的分区的分区唯一 GUID。

如果您查看parttypes.cc的代码，您会注意到 Linux 和其他版本的所有代码。

Linux 分区代码列表

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)