主页 / unix / 问题 / 532434
Accepted
quixotrykd
Asked: 2019-07-28 02:03:04 +0800 CST

为什么仍然使用驱动器/分区号？

  • 772

很多时候，尤其是在使用引导加载程序时，我会看到使用的数字驱动器和分区号。例如，在我的/boot/grub/grub.cfgI seeset root='hd0,gpt2'中，我的 UEFI 引导条目经常引用驱动器/分区号，并且它似乎出现在几乎所有涉及引导加载程序的环境中。

现在我们有了 UUID 和 PARTUUID，以这种方式寻址分区似乎非常不稳定（afaik，不能保证驱动器总是以相同的顺序安装，用户可以移动驱动器插入其主板的顺序等）

因此，我的问题是双重的：

  1. 这种寻址方案是否像我上面概述的那样不稳定？我是否遗漏了标准中的某些内容，这意味着该方案比我预期的要可靠得多，或者由于您的驱动器只是在不同的顺序或将它们插入主板上的不同插槽？

  2. 如果上述问题的答案是肯定的，那么为什么还要继续使用这种寻址方案？对所有事情都使用 UUID 或 PARTUUID 会不会更加稳定和一致？

partition grub2

5 个回答

  1. 严格来说，UUID 根本不是寻址。

    寻址非常非常简单：读取驱动器 X 扇区 Y - 否则。读取内存地址 Z - 否则。寻址简单、快速，没有太多解释空间，而且无处不在。

    UUID 没有寻址。相反，它是搜索、查找、有时等待设备出现，以及了解文件系统(★)。根据设备的数量，可能需要很长时间。一旦找到，就回到常规寻址。

    在 GRUB 中，这称为search(★★) 并且仅在 GRUB 已经长出翅膀时才可用（搜索是一个模块，它支持的每个文件系统也是一个模块，因此只有在加载核心后才可用）。在 Linux 中，它（例如）被称为findfsfindfs将搜索系统中的块设备以查找文件系统或分区。

    它会遍历所有块设备，将它们从待机状态唤醒，读取数据，如果 UUID 不是应有的唯一性（在dd事故等之后），结果甚至可能仍然是随机的，或者如果 UUID 更改，则您不会得到任何结果 - UUID 也容易出现配置错误。

    一般来说，UUID 非常棒，当然，如果可用的话，你应该在任何地方使用它们，尤其是当传统寻址必然会失败时，因为 Linux 中的驱动器顺序是随机的；但要明白，复杂性超出了简单寻址的目的。尤其是在引导加载程序的早期阶段，它可能还不是一个选择。先解决，后长翅膀。

    对于引导加载程序，可能根本没有必要付出努力（并非每个引导加载程序都支持广泛的文件系统，如 GRUB）。如果hd0由于情况（BIOS 提供）而保证是“我们启动的磁盘”，因此如果您可以排除随机驱动器顺序问题，则可能不需要通过潜在的大量其他分区列表搜索 UUID。

    如果您对自己的配置有足够的信心，可以说这hd0,gpt2是您想要的，而且必须是，否则就不可能，那么这样使用它就没有错。有时，简单明了的寻址就可以了。

    (★) 我之前在这里为 LABEL解释过这个......

    标签没有通用标准，都是手工编织的，例如在 util-linux 中查看 superblocks 格式的实现。如果你明天发明一个新的文件系统，即使它有标签，在添加支持之前它也不会出现。

    ...对于 UUID 来说也差不多。

    (★★) 实际上，GRUBsearch有一个--hint选项，而且...现在我还没有检查源代码，甚至在他们的手册中也没有记录，但是这样的选项可以为您提供两全其美的选择：提示应该告诉search首先检查该分区，如果 UUID 符合预期，它会以最小的努力识别设备，如果它不匹配，它仍然会退回到完整的搜索以保持事情以某种方式工作.

    除此之外，以前发现的 UUID 往往会被缓存，因此它不必一遍又一遍地遍历所有设备 - 这也很有效，前提是您要查找的 UUID 确实存在于某个地方首先将其放入缓存中。

    • 20
  2. Best Answer

    普通编号方案实际上并没有在最近的系统中使用（“最近的”是 Ubuntu 9 及更高版本，其他发行版可能也适应了那个时代）。
    您正确地观察到根分区是使用普通编号方案设置的。但这只是默认或备用设置，通常会被下一个命令覆盖，例如：

    search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

    这会根据文件系统的 UUID 选择根分区。

    在实践中，普通编号方案通常是稳定的（只要没有硬件更改）。我观察到的唯一一个不可预测编号的实例是具有许多 USB 驱动器的系统，这些驱动器基于先到先服务模式进行枚举，然后模拟为 IDE 驱动器。这些过程中没有一个本质上是混乱的，所以我假设特定系统 BIOS 实现中存在问题。

    注意：这里的“根分区”是指启动的分区，它可能与包含“root aka./file system”的分区不同。

    • 14

  3. 也不要忘记标签。它们不像 UUID 那样独特，但信息量更大，并使您的 fstab 易于阅读。如果它是您的台式机或小公司——换句话说，您正在管理几个到几十个驱动器，您可能更喜欢标签而不是 UUID。

    仔细考虑@frostschutz 对您的问题的出色回答，您可能更喜欢“经典”设备链接寻址的一种情况是虚拟机设置，尤其是在虚拟机出租（缩写为“IaaS”）云中。假设您要自定义Ubunzima 04.18映像。您创建一个具有 2 个磁盘的（一次性）VM：一个将是（一次性）系统驱动器，第二个是您安装和自定义的磁盘。如果你想在你的新磁盘上 grub 一个新的 grub，你大概也挂载了它的 UEFI 引导分区。假设您已为 下的目标分区选择挂载点/mnt，您所需的挂载表如下所示

    /dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

    因此，您可以从现有的、提供商提供的、云就绪的映像制作 2 个相同的驱动器，将它们连接到新的 VM 并启动它。自然，

    • 所有现代操作系统发行版，我们想象中的Ubunzima 04.18也不例外，都依赖于以 UUID 命名的挂载。
    • 从同一映像推出的所有硬盘驱动器都具有相同的 UUID。UUID 是唯一的，那么会出现什么问题呢？

    你已经看到了这一切的去向。

    这个 frankencontraption 第一次启动时，它被sda9选为 EFI 启动分区，但 Linux 决定重新挂载sdb1为根 FS：

    /dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

    而且由于我的推出脚本对此毫无准备，所以最后我得到了一个无法启动的无用图像，在 frankenbuild 期间没有一个工具在日志中抱怨！

    当然，我在日志中打印了挂载表。当然，混乱是很难发现的，因为 mount(8) 打印的安装顺序介于随机和安装设备之间的顺序，所以我没有立即发现它也就不足为奇了。想象一下，相同的脚本（但使用不同图像的磁盘）以前像 15 岁的 Glenfiddich 一样流畅。猜猜我花了多少小时在日志上拉头发¹试图找出问题？

    没有适用于任何情况的硬性规定，从台式电脑到嵌入在路由器中的 Linux，再到您的 Android 手机，再到云数据中心。SO 答案应该是客观的，而我的经验或偏好当然不是。因此，在选择不同的分区识别方法时，我宁愿展示逻辑推理的示例：

    • 如果您没有理由不这样做，请不要理会它。UUID 是大多数现代发行版的默认设置。如果要添加第二个驱动器，请尝试并决定。有可能你甚至不需要知道。如果您的系统仍在启动并且您可以看到新设备并对其进行分区，请格式化并将其添加到 fstab（通过 UUID、LABEL 或/dev链接，同样的注意事项适用）。只有当您的系统在插入额外的驱动器后拒绝启动时，您才会遇到问题（并且可能在 UEFI BIOS 中更改启动顺序是最快的解决方法）。

      务实地，在您自己的桌面上标记哪个 SATA 连接器连接到哪个驱动器可能是最快和最简单的解决方案，而更改系统启动方式并从很可能的启动故障中恢复可以说是最糟糕的时间狼吞虎咽。但是，如果您为 50 位认为添加额外驱动器不值得困扰您的问题的程序员管理它，那么至少不要测试您的运气极限，并确保 grub 可以看到他们的初始启动驱动器hd0和系统为sda.

    • 标签用于管理您自己的驱动器和桌面或三个或一个小环境中的分区（一个房子的客厅，里面挤满了软件工程师，他们有趣地将这个地方称为他们的“启动办公室”）。如果您从某人的机器上拉出一个物理驱动器，那么如果您始终使用标签，您就会知道它是从哪里来的。

      如果 lsblk(8) 说LABEL=bubba-boot，你知道它是从名为bubba的机器中提取的；此外，bubba-boot比6864c4ea-f9b9-46db-b875-4d7fc2981007更容易在我的舌头上滚动，在我被宠坏的口味中，它简直是一个令人震惊的东西。确保标签是独一无二的现在转移到你身上，但你得到的回报是标签的意义。

    • /dev- 当指挥一个相对短命、低维护的虚拟机营时基于链接的命名，这些虚拟机是同一个镜像的产物，而且你不会用你的周薪打赌他们所有的 UUID 都符合 UU 的承诺。任何健全的VM 服务，无论是您自己的物理服务器上的Vyper-H还是Kugel Cloud或其他任何东西，都不应调用您的引导驱动器sde，而第二个也是唯一一个sdc²。另一方面，在物理机中，您可以通过创造性地连接 SATA 电缆轻松获得相同的布置。

      我现在离题了，但在这种情况下，我采用所谓的“一致”以太网接口命名方式：在 VM 中禁用它。不要误解我的意思，只要您放入 PCI 插槽 4 的网卡不会在您不看的时候（或者甚至在您看的时候）突然跳到插槽 5，命名真的是一致的；网卡一点也不羞耻）。不幸的是，在“虚拟机营”环境中，他们确实做到了。在这种情况下，违反直觉，eth0比enp0s4f6. VM 提供者并没有承诺总是将他们的虚拟 NIC 编号 1 放在 PCI 总线 0 上的插槽 4 中（并且提到的 3 个实体都不是物理实体），并且它将始终是功能 6。但是你可以很漂亮很大程度上依赖于第一个接口在第二个之前，考虑到它们通常具有相同的驱动程序模块，通常来自 virtio 系列（如果第一个 NIC 并不总是eth0，同样的注释²仍然适用）。

    ¹ 形象地说，当然。如果这项业务太久了，我一直没有留下任何东西。
    ² 如果他们这样做了，我会认真考虑逃避他们更改供应商或虚拟机管理程序软件。

    • 5

  4. 这两种方案都可以与大多数 linux 发行版混合和匹配。

    根据用例，结果可能是可取的或不可取的 - 例如，如果热更换（虚拟硬件或实际硬件）驱动器而无需修改配置文件，则可能更喜欢旧方案（甚至禁用 udev 风格的持久性黑客）通缉。

    • 3

  5. 我猜你的第二个问题（“为什么继续使用这种寻址方案？”）的答案是惯性。是的，完全可以在 GPT 分区磁盘上只使用 UUID。/dev/xxx您可以使用UUID代替/etc/fstab. 现在我们有了Discoverable Partitions Specification，在许多情况下，您甚至不必再指定 UUID，只需使用分区类型对磁盘进行分区，分区就会被自动拾取。在我的机器上root=，内核命令行中完全缺少该条目。

    说到引导加载程序：GRUB 在现代 UEFI PC 上大多是多余的，因为它与引导机器几乎没有关系。如今，GRUB 仅用作内核选择程序，对于该任务，有更简单更好的替代方案可用，例如 systemd-boot。

    • 2

相关问题