ブートパーティションの(ddクローン)バックアップにより、重複したUUIDが残りました。
blkid
の表示:
/dev/sda1: UUID="32579810-0388-416d-bb49-7031ac2c2975" TYPE="ext4"
...
/dev/mapper/raidgroup-osbackup: UUID="32579810-0388-416d-bb49-7031ac2c2975" TYPE="ext4"
...
ここで、/dev/mapper/raidgroup-osbackup
はLVMデバイスです。
ライブUbuntuイメージから起動して、次のことを試しました。
Sudo tune2fs -U random /dev/mapper/raidgroup-osbackup
これは成功したように見え、ターゲットデバイスは新しいUUIDを示しました。
ただし、再起動後、/dev/mapper/raidgroup-osbackup
は/
に再マウントされ、blkid
は元のUUIDを示しました。
tune2fs
による変更は永続的であるはずだと思いましたが、そうではないようです。どうすればこれを修正できますか?
私は今それを解決したようです。どのステップで問題が解決したか正確にはわかりませんが、今回は次のようにしました。
新しいUUIDを生成します。
uuidgen
これにより、新しいUUIDが得られ、それを次の場所にコピーしました。
Sudo tune2fs -U <insert here> /dev/mapper/raidgroup-osbackup
次に、以下を使用して論理ボリューム/dev/mapper/raidgroup-osbackup
を無効にしました。
Sudo lvm lvchange -an /dev/mapper/raidgroup-osbackup
同じボリュームグループと物理ボリューム上の他の論理ボリュームを無効にしました。次に、「ディスク」GUIで基盤となる(ソフトウェア)RAIDアレイを無効にしました。 「ディスク」でRAIDアレイを再度有効にしました。これにより、いじっていたファイルシステムの論理ボリュームが自動的に再度アクティブになりました。 blkid
でUUIDを確認すると、UUIDがまだ変更されていることを確認できました。
追加の確認として、Ubuntuライブイメージを再起動し、/dev/mapper/raidgroup-osbackup
のUUIDをblkid
でもう一度確認しました。まだ変更されているので、この部分は解決されました。
それに伴い、新しい問題が発生しました...通常のインストールからシステムを再起動すると、UUIDが異なるにもかかわらず、ブートローダーが/
にマウントされた間違ったパーティションを取得します。私はこの問題を新しい質問として投稿しました: buntuがrootとして間違ったパーティションをマウントするのはなぜですか?
このコマンド
Sudo udevadm trigger
/ dev/disk/by-uuid /ディレクトリを更新する必要があります。/etc/fstabファイルを変更することを忘れないでください。
それが助けになることを願っています。