在引导时自动安装USB闪存的正确机制是什么？

Question

我看到了明显冲突的信息，在正确的方式，自动挂载USB闪存驱动器在启动。大多数关于如何做的说明都说要在fstab中使用条目。Gnome磁盘有一个内置功能来自动化这个条目。它似乎识别了一个闪存驱动器作为一个闪存驱动器，并知道如何正确地为它在fstab中创建一个条目，并且该条目工作。

另一方面，我已经读到可插拔驱动器应该由uDev来处理，而不是fstab，包括本质上永久插入的设备。与此相一致的是，磁盘管理器(与MX Linux捆绑在一起的实用程序)在我的系统上打开(包含一个用于闪存驱动器的工作fstab条目)，并带有错误消息：

I cannot find any existing block devices corresponding to the following devices:
/dev/disk/by-id/usb-Samsung_Flash_Drive_<id> on <mount point>
It is advisable to remove them to avoid failed mount at start-up.

一旦绕过该消息，磁盘管理器就会从其显示中排除(正确安装的)驱动器。它有一个问题，因为它不是块设备，更不用说可插拔了。

我假设的是磁盘管理器( Disk )在某个时候( /etc/fstab-disk-manager-save )所做的fstab备份，首先是注释：

# Pluggable devices are handled by uDev, they are not in fstab.

注意:自动安装闪存盘是一个常见的要求.因此，人们预计会有一些工具来帮助建立这一机制。现有的工具似乎都是通过在fstab中创建一个条目来实现的。使用uDev似乎需要编写您自己的自定义程序，而且需要帮助的程序员在Stack上有许多问题(因此它似乎不是新手用户的方法)。

有句老话说，“如果它没有坏，就不要修复它”，而fstab条目方法似乎是有效的。OTOH，关于使用uDev的建议和挂载失败的警告意味着fstab在某些情况下不起作用，这意味着fstab是作业的错误工具，不应该仅仅因为它在某些情况下工作而被依赖。

那么，一个“永久”插入的闪存驱动器是否应该通过fstab或uDev安装，磁盘管理器警告的风险是什么？

Answer 1

Eduardoápani的评论为我指出了研究这个问题的要点的正确方向。我会用这个自我回答结束循环，让其他人在这里着陆。

阻止成功引导的问题可能会使计算机处于需要跳转才能重新运行的状态，因为您无法访问发行版自己的工具来解决问题。在USB闪存驱动器中使用fstab的基本风险是，如果驱动器被认为是必需的，并且无法完成安装，则引导可以挂起或进入恢复模式。

驱动器被认为是必要的，如果它是在fstab中，并且没有被指定(通过相关的选项)，只是想要而不是需要。许多条件可能导致无法挂载，包括驱动器被拔出插头、驱动器已经故障(对于USB闪存驱动器来说很常见)，或者在挂载参数中指定fsck检查，以及系统无法完成这些检查。

这些问题可以通过挂载参数中指定的选项来缓解，但这些选项在不同发行版的可用性和实现上有所不同。因此，即使在使用自动化工具(如Gnome磁盘)创建fstab条目时，使用fstab来挂载可移动驱动器也会受益于研究发行版中可用的挂载选项。

安装选项包括：

• nofail:我读过关于nofail所做事情的各种描述。一些人认为这个选项只是导致fsck在不能执行测试的情况下跳过测试(如果有自动选项，测试会自动跳过丢失的驱动器)。其他人则将nofail描述为更一般地将挂载定义为只想要，而不是必需的。这意味着，无论设备能否成功安装，引导都将继续进行。
• 无启动:不同的描述类似于无失败。有些描述似乎将其目的限制在使引导不依赖于启动或完成设备fsck检查的能力。如果设备可用，它将在后台并发运行fsck，而不是按顺序运行。潜在的副作用(也适用于无失败)是，引导可以完成，但该资源(还没有)可用，可能导致操作问题。其他描述并没有将引导限制在fsck上；他们将其描述为防止由于任何原因而无法安装驱动器，从而停止引导。有一篇文章指出，这两个选项的不同之处在于，在决定驱动器不可用之前，没有失败等待数分钟，如果是，则会导致启动延迟，而没有立即启动。我的理解是，nobootwait从来没有与Ubuntu兼容(不知道它是否扩展到了一些非基于Ubuntu的发行版，并且不能保证这个版本在这个时候是否仍然适用)。
• x选项:有一些选项可以直接控制设备是否是必需的，而不是仅仅需要的，以及启动等待设备的时间。它们使用模式x-systemd.<option>命名，并取决于使用systemd的发行版。