デバイスのUUIDを変更すると起動できないのはなぜですか？
Ec2インスタンスを回復しようとしたときに、そのインスタンスのルートボリュームを他のマシンにマウントできないと、次のコマンドを使用して新しいUUIDを生成できないことに気付きました
xfs_admin -U generate /dev/xdfg。
（これは、UUIDが重複しているためにドライブをマウントできなかったとシステムが言っているためですが、なぜそうなったのかはまだわかりません）
これにより、ボリュームにアクセスできました。ただし、マウントして元のec2インスタンスで起動しようとすると、起動に失敗してunknown filesystemエラーが発生し、grubレスキューを使用するように求められました。
これを解決するために、ドライブをセカンダリマシンに再度マウントし、UUIDを元の状態に戻しました。幸い、コンソールの履歴にそれがありました。
xfs_admin -U xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx /dev/xdfg
これにより、マシンを再起動できました。
質問
では、好奇心のために、UUIDがシステムの起動を妨げているのでしょうか。両方のUUIDを持つ別のマシンにマウントすると、システムはファイルシステムがxfsであることを認識していました。
質問の一部はすでにここで回答されていますが、 https://unix.stackexchange.com/questions/137862/why-does-fstab-use-uuid-instead-of-the-actual-file-システム名
別の説明をしようと思います。現在、fstabを介してルートファイルシステムをマウントするためにUUIDを使用しています。これは、常に同じディスクを参照するハードウェアを追加するときに1つの利点があります。ブートディスクを変更するときは、必ずfstabのUUIDを変更してください。 blkidコマンドを使用して、新しいディスクUUIDを取得します。両方のディスクを同じシステムに接続し、新しいUUIDを取得してfstabでUUIDを変更すると、これはかなり簡単です。古いディスクを削除する前に、ルートファイルシステムを新しいディスクにコピーする必要があります。
FstabでUUIDを指定せずに別の方法を使用できます。たとえば/ dev/sdaを参照し、fstabでファイルシステムを指定する必要があります。たとえば、2番目のドライブを接続し、システムがルートディスクの/ dev/sdaを/ dev/sdbに変更すると、後で失敗する可能性があります。ここで、UUIDが役立ちます。
組み込みシステムや他の一部のシステムでは、独自のパーティションに/ etc/fstabと一緒にブートディレクトリがある場合があるため、ブート時に間違ったUUIDを指定し、システムがそれを見つけられない場合、システムは単にブートしません。
したがって、ディスクを変更する前に、ブート時にパーティションのレイアウト、fstabの場所、デバイスのマウントを確認する必要があります。