我的伺服器上有一些磁碟（用於 RAID）和一些啟動分割區來測試各種發行版。有時我有一個最近的（10 buster）Debian 32 位和一個最近的（10 buster）Debian 64 位，由於某些原因，我決定將Debian 64 位移動到較低的分區（使用dd，設置一個新的分割區） UUID 並在該分割區的 /etc/fstab 中更新它），然後我在我之前移動 Debian 的分割區上安裝了最新的（20.1 Ulyssa）Linux Mint Cinnamon。我沒想到它會帶來問題，因為安裝 Linux Mint 會運行 update-grub 並為 Debian 64 獲取我的新分割區，但是，當時我的 Debian 64 位元停止工作。提示找不到根分區。
對此有一些評論：Debian 安裝過程非常好地警告我，可能存在非 UEFI 分區，如果我嘗試在 UEFI 模式下安裝 grub（並建議在 BIOS 中啟動），這些分區可能無法工作。 Mint 似乎不太關心這一點。所以 mint 在 UEFI 模式下配置了我的 grub。然而，奇怪的是，它阻止了我的 Debian 64 的工作，但沒有阻止我的 Debian 32 的工作。
我必須承認 grub 過程對我來說一直不清楚，但我不明白的是，嘗試從我的 Debian 32 重新安裝和更新 grub 並沒有解決問題，並嘗試找到一個帶有兩個分區（Debian 32 和64 ）上的/etc 和/boot （包括子目錄）中的失敗UUID。最後，我透過在啟動時編輯 Debian 64 的 grub 命令列，然後從 Debian 64 重新安裝和更新 grub 解決了這個問題。
然而，我真正想了解的是這個 UUID 的儲存位置（為什麼我找不到它），以及為什麼我無法從 Debian 32 分區解決這個問題。
編輯：為了讓自己清楚：我能夠透過在引導期間從 grub 選單編輯核心參數，用 root=/dev/sdxx 替換 root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 來引導在後續的grub 恢復過程中未進行修改。但是，我無法在 /etc 和 /boot 中的任何未壓縮檔案中找到此 UUID 值（既不是 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 也不是 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx）。
EDIT2：好的......我正在尋找的是在 /boot/grub/grub.cfg （感謝Archemar），但我沒有找到它，因為我在搜索中摸索了我的正則表達式
find /boot /etc -type f -print0 |
xargs -0 grep -li 'a9c85b02-?751e-?48b5-?b85e-?df60d20b5d3e'
grep 正規表示式無法辨識？我應該用 {0,1} 來代替...:'(
find /boot /etc -type f -print0 |
xargs -0 grep -li 'a9c85b02-\{0,1\}751e-\{0,1\}48b5-\{0,1\}b85e-\{0,1\}df60d20b5d3e'
但是，它並沒有解釋為什麼當我從 debian 32 分割區重新安裝並重新配置 grub 時它不起作用。是否會偶然識別其他 linux 分區，基於解析/boot/grub/grub.cfg這些分區中的 ??? :-o
答案1
我在 vmware 將啟動+系統磁碟從 800Gb 磁碟移動到 16Gb 時遇到了類似的問題，只需複製分割區和檔案（從 800Gb 磁碟到 16Gb），並且刪除 800Gb 磁碟是不夠的（核心啟動正常但無法找到/' s UUID） 。 （遺憾的是，在這種情況下，vmware 的快照無法用作回滾保護）
- 掛載點在
/etc/fstab但有2fstab - 平原
fstab是在/etc - Secret
/etc/fstab位於initrd.gz（或類似）/boot啟動磁碟分割區中，此 fstab 會儲存指向/作業系統（根 FS）的 UUID。
initrd如果您已從此作業系統啟動，請重建。
或者，如果您從另一個作業系統啟動，initrd.gz則為 gzip 壓縮的 cpio，「簡單地」提取 fstab文件，編輯它，然後將其放回initrd.gz.