ClonezillaとBTRFS、GRUBとブート

ClonezillaとBTRFS、GRUBとブート

私はClonezillaを使用してOpenSUSE TumbleweedがインストールされているBtrfsドライブをより大きなドライブに複製し、セクターごとに複製してみました。ただし、毎回プロセスが正常に完了しているように見えますが、新しいドライブから起動しようとすると、Ubuntu GRUBが表示され、もちろん何も読み込まれません。私はUbuntuメニューがClonezilla自体から来たと仮定します。しかし、Clonezillaがすべてを正確にコピーしないのはなぜですか?

また、OpenSUSEから新しいドライブをマウントすることはできません。ドライブはPartition Managerに表示されますが、マウントオプションは使用できません。

誰かがドライブの複製が開始されないか、マウントされていない原因を明確にすることはできますか? Btrfsにはいくつかの特別な詳細があると思いますが、なぜセクタ固有のレプリケーションがすべてのものと同じコピーを作成しないため、ディスクを起動してマウントできるようにするのかわかりません。助けてください。

修正する:次の助けを借りてパーティションをマウント可能にすることができました。`mount`エラー: `システムコールに失敗しました:ファイルが存在します。 `しかし、まだ起動できません。また、何らかの理由で/home/コピーが同じであると仮定しても、新しいディスクにはユーザーディレクトリはありません。

答え1

わかりました、それに基づいてあなたのlsblk結果そしてあなたの/etc/fstabbtrfs、デフォルトではEFIシステムパーティションを除くシステム全体があります。

単一btrfsのファイルシステムは、単一のパーティションを超えて複数のディスクにまたがって拡張できます。lsblk出力が実行中の操作を示していないため、サブボリュームを含む拡張機能として/dev/sdc機能できます。これはレプリカにない理由を説明したり、他のすべてのサブボリュームをマウントできなかった可能性があります。これを使用して、マウントされた各ファイルシステムにどのデバイス/パーティションが属しているかを確認できます。btrfs/homebtrfs filesystem showbtrfs

btrfstune -m /dev/sdb3リンクされた他の質問の説明で説明されているように実行すると、複製されたファイルシステムのUUIDが変更されるため、複製されたファイル/etc/fstabシステムのUUIDエントリは正しくありません。/etc/fstab複製されたファイルとGRUBの設定および/またはinitramfsで問題を修正する必要があります。lsblk -o +UUID新しいコンテンツを表示するために使用できます。ファイルシステムUUID。このUUIDはGRUBおよびLinuxカーネルで使用されますが、UEFIファームウェアでは使用されません。ファイルシステムメタデータに保存されます。

あなたはこれをしなければなりません:

mount /dev/sdb3 /mnt
mount -o subvol=/@/boot/grub2/x86_64-efi /dev/sdb3 /mnt/boot/x86_64-efi
mount /dev/sdb1 /mnt/boot/efi

それから:

  • /mnt/etc/fstabbtrfsファイルシステムを参照する各行のファイルシステムUUIDを置き換えるように編集します。

  • カーネルブートオプション行でファイルシステムUUIDを置き換えるように編集する/mnt/boot/grub/grub.cfg(またはOpenSuSEが実際のGRUB構成を配置する場所によって異なります)/mnt/boot/efi/EFI/opensuse/grub.cfg

  • /mnt/etc/default/grubカーネルアップデートがインストールされたときや他の理由でGRUB設定が再生成されたときに古いUUIDが予期せず返されないように、ファイルシステムのUUIDを置き換えるように編集します。
  • initramfs ファイルを完全に再作成することもできます。

initramfsファイルを再作成する必要がある場合(ルートファイルシステムを見つけるためにカーネルブートパラメータに完全に依存している場合は必要ありません)、この時点で次のことができます。

mount -t proc none /mnt/proc
mount -t sysfs none /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt /bin/bash
mkinitrd   # or whatever is the appropriate command for OpenSuSE
exit
  • 最後にインストールしたすべてのアイテムを削除します。

システムが複製されたディスクから実際に起動するには、そのディスクのUEFI起動変数を定義する必要があります。 ~からあなたのefibootmgr -v結果、OpenSuSEの開始エントリはEFIシステムパーティションを表します。パーティションUUID。 UEFIファームウェアでのみ使用される個別のUUID。 GPTパーティションテーブルに保存されます。

Boot0000* opensuse-secureboot   HD(1,GPT,e099a79f-8b66-412d-89ae-a4869876f500,0x800,0x100000)/File(\EFI\opensuse\shim.efi)

を使用してパーティションUUIDを表示できますlsblk -o +PARTUUID

同じパーティションUUIDを持つ2つのディスクがあると、システムファームウェアが混乱する可能性があり、ファームウェアは単に一致するUUIDを持つ最初のディスクを選択することもできます。同じマシンに両方のディスクを保持するには、Change Partition UUIDを使用する必要があります。sgdisk --partition-guid=1:R /dev/sdb(このコマンドは、パーティション#1に対して新しいランダムパーティションUUIDを作成します/dev/sdb。)

完了したら、複製されたディスクの新しいUEFIブート変数を作成する必要があります。コマンドはに似ていますefibootmgr -c -d /dev/sdb -l \\EFI\\opensuse\\shim.efi -L opensuse-clone。バックスラッシュはシェルの特殊なエスケープ文字なので、ESPファイルシステムはFAT32なので、UEFIファームウェアはUnixスタイルのスラッシュの代わりにMS-DOS / Windowsスタイルのバックスラッシュを使用します。便利なことに、このコマンドは指定されたドライブからパーティションUUIDを自動的に読み取るため、これを入力する必要はありません。

efibootmgr -B -b XXXX(廃止予定のUEFIブート変数のシステムNVRAMを消去するには、XXXXが以前のLinuxインストールの1つのBootXXXX番号であるBootXXXX番号を使用する必要があります。)

ただし、ディスクを別のコンピュータに移動する予定の場合は、パーティションのUUIDを変更する必要はありませんが、複製されたディスクを受け取るシステムにUEFIブート変数を作成する必要があります。一部のLinux Liveブートメディアを使用してこれを実行できますが、そのメディアから具体的にブートする必要があります。UEFIスタイルそうしないと、UEFIブート変数にアクセスできなくなります。

または、主要な準備なしでUEFIシステムからレプリケーションディスクを起動できる必要がある場合は、レプリケーション\EFI\Boot\bootx64.efiディスクESPパーティションの代替/リムーバブルメディアブートローダパスにUEFIブートローダのコピーを設定する必要があります。残念ながら、OpenSuSE UEFIブートローダに関する正確な設定情報がないため、正確な手順をお知らせすることはできません。

複製されたディスクのESPにアクセスするには、まずそれをインストールする必要があります。たとえば、次のようになります。

mount /dev/sdb1 /mnt

/mnt/EFI/BOOT/bootx64.efiその後、UEFIファームウェアで使用されているDOSスタイルのパス名に対応するフォールバックブートローダを配置できます。\EFI\BOOT\bootx64.efi

関連情報