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

很多时候，尤其是在与引导加载程序打交道时，我会看到使用了数字驱动器和分区号。例如，在我/boot/grub/grub.cfg看来set root='hd0,gpt2'，我的UEFI引导条目经常引用驱动器/分区号，并且在涉及引导加载程序的几乎所有情况下，它似乎都是出现的。

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

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

1. 这种寻址方案是否像我上面概述的那样不稳定？我是否在标准中遗漏了一些东西，这意味着该方案比我预期的要可靠得多，还是由于仅在驱动器中识别出驱动器，该寻址方案会真正使您的系统无法启动（至少要修复启动项）。不同的顺序或将它们插入主板上的不同插槽？

2. 如果以上问题的答案为是，那么为什么继续使用此寻址方案？使用UUID或PARTUUID进行所有操作是否会更加稳定和一致？

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

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

这将基于文件系统的UUID选择根分区。

实际上，普通编号方案通常是稳定的（只要没有硬件更改即可）。我观察到的唯一实例是不可预测的编号，该系统具有许多USB驱动器，这些驱动器是根据先到先服务模式枚举的，然后将其模拟为IDE驱动器。这些过程本质上都不是混乱的，因此我认为该特定系统BIOS实现中存在问题。

注意：在此上下文中，“根分区”是指要从其引导的分区，它可能与包含“根/文件系统”的分区不同。

严格来说，UUID根本没有寻址。

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

UUID未寻址。取而代之的是搜索，查找，有时等待设备出现以及了解文件系统（★）。并且取决于有多少设备，这可能需要很长时间。一旦找到，就回到常规地址。

在GRUB中，这称为search（★★），并且仅在GRUB已经扩展后才可用（搜索是一个模块，它支持的每个文件系统也是如此，因此仅在加载内核后可用）。在Linux中，它是（例如）呼吁findfs，findfs将搜索块设备在系统中寻找一个文件系统或分区。

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

通常，UUID非常有用，当然，您应该在所有可用的地方使用它们，尤其是在传统寻址势必失败时，因为Linux中的驱动器顺序是随机的；但是请理解，复杂性超出了简单寻址的意图。尤其是在引导加载程序的早期阶段，它可能根本不是一个选择。首先解决，然后发展。

对于引导加载程序，可能根本无需付出任何努力（并非每个引导加载程序都支持GRUB等各种文件系统）。如果hd0由于某种情况（BIOS提供）而保证是“我们引导的磁盘”，那么如果您可以排除随机的驱动器顺序问题，则可能不需要遍历其中可能存在的大量其他分区搜索UUID。

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

（★）我以前在这里为标签解释过 ...

标签没有通用标准，都是手工编织的，例如，请参见util-linux中超级块格式的这种实现。如果您明天发明一个新的文件系统，即使它带有标签，它也要到添加支持后才会显示。

...并且对于UUID几乎相同。

（★★）实际上，GRUB search有一个--hint选项，并且...现在我还没有检查源代码，甚至在他们的手册中也没有进行记录，但是这样的选择对于您两全其美是有意义的：提示应该告诉您search首先检查该分区，并且如果UUID符合预期，则只需花费很少的精力即可识别设备，如果不匹配，它仍将退回到完全搜索状态以保持某种状态。

除此之外，以前发现的UUID往往会被缓存，因此它不必一次又一次地遍历所有设备-如果您要查找的UUID实际上存在于某个地方，它也可以很好地工作。首先将其放入缓存。

也不要忘记标签。它们不像UUID那样唯一，但是信息量更大，并使fstab易于阅读。如果是台式机或小型公司（换句话说，您要管理几到几十个驱动器），则可能更喜欢使用标签而不是UUID。

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

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

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

• 所有现代OS发行版，我们想象中的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期间，没有一个工具在日志中抱怨！

当然，我在日志中打印了安装表。和当然的烂摊子起来是很难发现的，因为安装（8）打印中途随意之间，在该装置被安装在为了坐骑，所以这并不奇怪我没有发现它的时候了。可以想象，以前使用相同脚本（但使用来自不同映像的磁盘）的工作就像15岁的Glenfiddich一样流畅。猜猜我花了几个小时来梳理日志以找出问题所在吗？

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

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

  在实用上，标记哪个SATA连接器连接到您自己的台式机中的哪个驱动器可能是最快，最简单的解决方案，而改变系统引导方式并从极有可能的启动故障中恢复则可以说是最糟糕的时机。但是，如果你管理它的50个程序员谁认为一个额外的驱动器扔是没有打扰你，至少是不试一试自己的运气的限制，并确保他们的初始引导驱动器都看到了平头一样值得的问题hd0和系统为sda。

• 用于管理您自己的驱动器和分区的标签，可以在台式机或三个台式机或一个小型环境（一个装有软件工程师的房子的客厅里，他们把这个地方称为“启动办公室”）中进行管理。如果从某人的计算机上拉物理驱动器，则始终使用标签就可以知道它来自何处。

  如果lsblk（8）表示LABEL=bubba-boot，您知道它已从名为bubba的机器中拉出；此外，bubba-boot比6864c4ea-f9b9-46db-b875-4d7fc2981007更容易在我的舌头上滚动，按我的口味，这真是令人a目结舌。现在，确保标签独特是您的责任，但是您得到的回报是标签的意义。

• /dev-link命名时，命令一个寿命相对较短，维护需求低的VM，它们是同一映像的衍生，并且您不会打赌您的周薪是他们的所有UUID都符合UU承诺。任何理智的 VM服务，无论是您自己的物理服务器上的Vyper-H还是Kugel Cloud或任何其他工具，都切勿调用启动驱动器sde，第二个也是唯一一个sdc。另一方面，在物理计算机中，通过创造性地连接SATA电缆，您可以轻松实现相同的布置。

  我现在离开了，但是在这种情况下，我采用了“一致的”以太网接口命名的相同方法：在VM中禁用它。别误会，只要您插入PCI插槽4的NIC不会在您不注意时（甚至可能是您所在的状态），自己不会随心所欲地突然跳到插槽5，则命名实际上是一致的别无耻）。不幸的是，事实上，在“ VM营”环境中确实如此。在这种情况下，与直觉相反，eth0是更比一致enp0s4f6。VM提供程序未保证始终将其虚拟NIC编号1放置在PCI总线0的插槽4中（并且提到的3个实体中的任何一个都不是真实的），并且它始终是功能6。考虑到它们通常具有相同的驱动程序模块（通常来自virtio系列），因此它们很大程度上依赖于第一个接口（如果第一个NIC并非始终eth0是相同的，则仍然使用相同的注2），因此它们很大程度上取决于第一个接口。

  ---

¹当然，具有象征意义。我去过这家公司太久了，以至于还剩下什么。
²如果他们这样做，我会认真考虑让他们尖叫着改变提供商或VM虚拟机管理程序软件。

两种方案都可以与大多数Linux发行版混合使用。

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

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

说到引导装载程序：GRUB在现代UEFI PC上几乎是多余的，从某种意义上说，它与引导机器无关。如今，GRUB只是充当内核选择器程序，针对此任务，有更简单，更好的替代方案可用，例如systemd-boot。