私は自分のPCでDebianWheezyを単独で実行し、最近ルートパーティションをrsyncで別のパーティションにコピーしました。これはうまく機能していることがわかりました(ddとddrescueについても知っていますが、新しいパーティションに使用できないスペースが残ります) 。 Sudo tune2fs -U random/dev/hda9を使用して、新しいパーティションの新しいランダムUUIDを生成し、fstab /および/ homeエントリも更新しました。
次に、GRUBについてほとんど知らないので、GUI(GRUB Customizer)を使用して新しいOSをプローブし、GRUBおよびMBR-にエントリを追加しました。 /etc/grub.dエントリを作成してから、GRUBを更新します。
起動時に、GRUBリストには新しいOS(sda9上)が含まれていますが、最初のOS(-sda5からコピーしたもの)が起動します。
/boot/grub/grub.cfgには新しいDebianOSが含まれていますが、次のようになります。
set root='(hd0,msdos9)'
search --no-floppy --fs-uuid --set=root 64662470-0e58-4dfd-90ac-43227d773556
linux /boot/vmlinuz-3.2.0-2-AMD64 root=UUID=cc3bca0d-aee4-4b9c-95c2-57212cc36d4d ro quiet
initrd /boot/initrd.img-3.2.0-2-AMD64
最初のuuidはsda9のものですが、2番目のuuidはsda5のものです。起動時に(Eを使用して)2番目のuuidを変更すると、sda9が起動します。
では、sda9 GRUBリストエントリがsda9から永続的に起動するようにgrub.cfgを修正するにはどうすればよいですか?
/boot/grub/grub.cfg/
を編集して、sda5のUUIDをsda9のUUIDに置き換えるだけです。
search --no-floppy --fs-uuid --set=root 64662470-0e58-4dfd-90ac-43227d773556
linux /boot/vmlinuz-3.2.0-2-AMD64 root=UUID=64662470-0e58-4dfd-90ac-43227d773556
将来このタイプのエラーを回避するには、update-grub
使用するシステムからを実行します。古いOSから実行すると、currentルートパーティションが取得され、そこから起動するようにgrub.cfgが設定されます。
update-grub
からsda5
を実行すると、/boot/grub/grub.cfg
からコピーされたsda9
からsda5
が読み取られます。まず、プライマリOSであるsda5
を起動します。次に、次のコマンドを使用して修正します。
SourceUUID=cc3bca0d-aee4-4b9c-95c2-57212cc36d4d
TargetUUID=64662470-0e58-4dfd-90ac-43227d773556
Sudo mkdir /mnt/clone
Sudo mount -t auto -v /dev/sda9 /mnt/clone
Sudo sed -i "s/$SourceUUID/$TargetUUID/g" /mnt/clone/boot/grub/grub.cfg
Sudo update-grub
Sudo umount /mnt/clone -l
私はこの答えを buntu 16.04 LTSクローンから新しいパーティションスクリプトへ に基づいています。
/boot/grub/menu.lstを削除して(最初にバックアップをcpする必要があります)、次にupdate-grubが「はい」と言って新しいバックアップを生成する必要がありました。次に、起動元の正しいパーティションUUIDを検出しました。