☰

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

tag-icon • tag-icon linux partitioning gdisk
Linux 主分区代码 8302 的用途是什么？

我正在格式化 SSD 以用于 Linux 系统，我发现有一个明显的磁盘分区代码（8302）/家如果创建了分区，则使用 8300 代码。我认为替代方案是“Linux 文件系统”(8300) 代码。

不同代码的目的是什么/家分割？

答案1

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

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

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

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

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

在大多数情况下，Linux 不使用类型代码，无论是 MBR 还是 GPT。也就是说，您可以将标准 Linux 文件系统放在 (GPT fdisk) 8300 分区上，或者使用 0700（过去很常见），或者分配您自己的随机 GUID。类似的注释适用于 RAID、LVM、交换和其他分区类型。不过，这条规则也有一些例外。首先，分发安装程序通常会查看和设置类型代码，因此您可能需要在分区上设置正确的类型代码，然后才能正确使用它。另一个例外是，如果/etc/fstab配置不正确，systemd 开始使用类型代码作为后备。（这就是 GPT fdisk 的大多数 830x 代码的来源——它们是可发现分区规范， 这是 Freedesktop/systemd 的一项举措。）目前，Ubuntu 仅使用主 Linux 文件系统类型代码（GPT fdisk 中的 8300）作为文件系统，以及 LVM、RAID、交换等的相应代码。“Linux 不使用类型代码”规则的一个大例外是 BIOS 启动分区代码（21686148-6449-6E6F-744E-656564454649；GPT fdisk 中的 ef02 或 libpartedbios_grub中的标志）。此类型代码标识 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 Basic Data”类型代码 (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) 的常见做法会导致双启动设置出现问题。具体来说，某些 Windows 工具会认为 Linux 分区是损坏或未初始化的 Windows 分区并建议准备它。此提示中的用户错误将是灾难性的。请参阅我的这个页面了解有关此主题的更多信息。

答案2

Linux 分区类型代码的用途可发现分区规范是让/etc/fstab大多数系统不再需要书写。这是惯例优于配置的一个例子。

Systemd 已添加systemd-gpt-auto-generator早在 2014 年版本 211 中就已出现。此生成器.mount从启动驱动器上的 GPT 分区创建单元。

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

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

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

答案3

需要为/home和其他分区制定代码这里由 Rod Smith 创建，他至今 (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 对其他分区类型（如 RAID、LVM 和交换空间）有自己的 GUID 类型代码。

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

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

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

如果你看一下代码零件类型，您会注意到所有适用于 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)

相关内容