パーティション情報とパーティションデータを再フォーマットしてコピーするために、Raspberry Piシステム用のPythonスクリプトをテストしています。最初のデバイス(通常はUSBスティック)から情報を取得するには、次のようにします。
sfdisk -d /dev/sda >sda_data.txt
その後、同じテーブルをターゲットドライブにコピーするには、次のようにします。
sfdisk /dev/sdb <sda_data.txt
全体的に期待どおりに動作しますが、より小さなディスクで使用するとどうなりますか?たとえば、sda1 は msdos 形式のブートパーティションで、sda2 はドライブの残りの部分を埋める extfs パーティションであるとします。 /dev/sda2の合計データ(ブートコマンドとデータを除く)が約10GBで、/dev/sdaが64GBであるとします。
私のデータは、64 GBデバイスからより小さい32 GBデバイスにファイルをコピーするとき、小さいデバイスの/ dev / sdbにすべてのデータをより小さなデバイスに保存するのに十分なスペースがあるほど小さくなります。したがって、sdaが64GBでsdbが32GBの場合でも、sdaのすべてのデータをsdbにコピーできます。
問題は小さなsdbのパーティションにあります。
sda からパーティション情報を読み取る場合、これにはパーティションのサイズが含まれ、2 番目のパーティション sda2 は新しいパーティション sdb2 よりはるかに大きくなります。 sdbでsda_data.txtのinfodumpを使用すると、私の経験によれば、sfdiskはsdbでより小さなデバイスサイズを受け入れ、大きすぎるパーティションを作成しようとしません。 sdb2で自動移動を作成します。最後のパーティションはより小さいデバイスです。
これは私の経験です。これは標準的な行動ですか? sfdiskは常に最後のパーティションのサイズをより小さなデバイスに調整しますか?つまり、sfdiskを使用して小さなデバイスに小さなパーティションを作成できますか? (これはsdbが終了した後にパーティションが起動せず、そのデバイスのスペースを完全に超えていると仮定しています。ない)
答え1
ダンプオプションは、特定のパーティションの正確なコピーを作成するのに適しています。
パーティションとデバイスのサイズが一致しない場合、sfdiskを使用することがどれほど安定しているかはわかりません。
ただし、最初からまたはダンプに基づいてより寛大なsfdiskスクリプトを簡単に作成できます。
たとえば、sfdiskから次のダンプを受け取った場合
label: gpt
label-id: 01234567-89AB-CDEF-0123-456789ABCDEF
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 7814037134
sector-size: 512
/dev/sda1 : start= 34, size= 32734, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=01234567-89AB-CDEF-0123-456789ABCDEF, name="Microsoft reserved partition"
/dev/sda2 : start= 32768, size= 629145600, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=01234567-89AB-CDEF-0123-456789ABCDEF, name="something"
/dev/sda3 : start= 629178368, size= 1300070400, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=01234567-89AB-CDEF-0123-456789ABCDEF, name="something else"
/dev/sda4 : start= 1996365824, size= 5817669632, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=01234567-89AB-CDEF-0123-456789ABCDEF, name="root"
デバイスパス、開始セクタ、およびサイズパラメータのいずれかを削除して、より柔軟なパーティションを作成できます。
label: gpt
size= 32734, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, name="Microsoft reserved partition"
size= 629145600, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="something"
size= 1300070400, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="something else"
type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="root"
これにより、sfdiskは自動的にデフォルトの開始位置を計算し、最後のパーティションを拡張して残りのスペースを埋め(必要なサイズがないため)、パーティションの新しいUUIDを生成する4つのパーティションを作成します。パーティションが以前と同じUUIDを持つようにするには、uuid
ダンプにパラメーターを保持するだけです。
関連部品は以下で提供されます。マンページ:
推奨されるアプローチは、開始オフセットをまったく指定せずに、パーティションサイズをMiB、GiB(またはそれ以上)単位で指定することです。この場合、sfdiskはすべてのパーティションをブロックデバイスI / O制限(またはI / O制限が小さすぎてディスクレイアウトを移植可能に保つことができない場合はメガバイト境界)に合わせます。
サイズのデフォルトは「最大」、つまり次のパーティションまたはデバイスの終わりまでを意味します。
通常、sfdiskスクリプトを直接作成することが可能です。ブート+ルート設定の場合(注:sfdiskを使用してパーティションがどのファイルシステムを持つかは重要ではありません)、次の簡単な方法を使用する必要があります。
label: gpt
size=5GiB, type=linux, name="boot", bootable
type=linux, name="root"