在啟動時自動安裝 USB 快閃記憶體驅動器的正確機制是什麼？
我看到有關在啟動時自動掛載 USB 快閃記憶體驅動器的正確方法的資訊顯然相互矛盾。大多數關於如何操作的說明都說使用 fstab 中的條目。Gnome Disks 有一個內置功能可以自動執行此條目。它似乎將快閃記憶體驅動器辨識為快閃記憶體驅動器，並且知道如何在 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.一旦繞過該消息，磁碟管理器就會從其顯示中排除（正確安裝的）驅動器。它的問題在於它不是塊設備，更不用說可插拔了。
我假設是磁碟管理器在某些時候對 fstab 進行的備份，
/etc/fstab-disk-manager-save以註釋開頭：# Pluggable devices are handled by uDev, they are not in fstab.一個觀察：自動安裝快閃記憶體驅動器是一個司空見慣的要求。因此，人們會期望有工具來幫助進行設置。現有的工具似乎都是通過在 fstab 中創建一個條目來完成的。使用 uDev 似乎需要編寫自己的自定義程序，並且在 Stack Exchange 上有很多程序員需要幫助的問題（因此它似乎不是新手使用者的方法）。
有句老話，“如果它沒有壞，就不要修復它”，fstab 入口方法似乎有效。OTOH，關於使用 uDev 的建議和關於掛載失敗的警告意味著在某些情況下 fstab 無法解決此問題，這表明 fstab 是該工作的錯誤工具，不應僅僅因為它有效而依賴它在某些情況下。
那麼是否應該通過 fstab 或 uDev 安裝“永久”插入式快閃記憶體驅動器，磁碟管理器警告提示的風險是什麼？
Eduardo Trapani 的評論為我指明了研究問題要點的正確方向。對於其他登陸這裡的人，我會用這個自我回答來結束循環。
阻止成功啟動的問題可能會使電腦處於需要跳過箍以使其再次執行的狀態，因為您無法訪問發行版自己的工具來解決問題。將 fstab 用於 USB 快閃記憶體驅動器的基本風險是，如果驅動器被認為是必不可少的並且無法完成安裝，則啟動可能會掛起或進入恢復模式。
如果驅動器在 fstab 中並且沒有被指定（通過相關選項），則認為它是必不可少的，因為它只是需要而不是必需的。許多情況可能導致無法掛載，包括驅動器被拔出、驅動器發生故障（USB 快閃記憶體驅動器的常見情況），或者在掛載參數中指定了 fsck 檢查並且系統無法完成該檢查。
這些問題可以通過掛載參數中指定的選項來緩解，但是這些選項在不同發行版中的可用性和實現方式上有所不同。因此，使用 fstab 掛載可移動驅動器會受益於研究發行版中可用的掛載選項，即使使用自動化工具（如 Gnome 磁碟）來創建 fstab 條目也是如此。
安裝選項包括：
- nofail：我已經閱讀了關於nofail功能 的各種描述。有些人將此選項描述為僅導致 fsck 在無法執行測試時跳過測試（如果缺少自動選項，則測試會自動跳過失去的驅動器）。其他人將nofail描述為更普遍地將掛載定義為僅需要，而不是必需。這意味著無論設備是否可以成功掛載，引導都會繼續進行。
- nobootwait： 不同的描述類似於nofail。一些描述似乎將其目的限制為使引導不依賴於啟動或完成該設備的 fsck 檢查的能力。如果設備可用，它會在後台同時執行 fsck，而不是按順序執行。潛在的副作用（也適用於nofail）是引導可以完成，但該資源（尚）不可用，可能會導致操作問題。
其他描述並未將nobootwait限制為 fsck；他們將其描述為防止由於任何原因而無法安裝驅動器而停止引導。
一篇文章指出，這兩個選項之間的區別在於nofail在確定驅動器不可用之前最多等待幾分鐘，如果是，則會導致啟動延遲，而nobootwait會立即繼續。
我的理解是nobootwait從未與 Ubuntu 兼容（不知道這是否擴展到某些非基於 Ubuntu 的發行版，並且不能保證此時是否仍然適用）。
- x-systemd 選項： 有一些選項可以直接控制設備是需要還是僅僅需要，以及引導將等待設備多長時間。它們以 pattern 命名
x-systemd.<option>，並且取決於使用 systemd 的發行版。