この答えは私の頭からのものです。いいえテスト済みです。テストしてみると、答えを更新してください。

残念ながら、この質問には、私たちがこれを行う理由を説明する文脈はほとんどありません。表面的には以下を参照できます。qemu-img答えは「いいえ」です。

しかし、それは退屈でしょう。代わりに、いくつかの言葉にならない仮定をして実行してみましょう。

説明するソリューションはqemu-imgFreeBSDで可能です。エミュレータ/qemu-utilsvboxmanageは以下から来ています。エミュレータ/仮想ボックス-ose。おそらくそれがあなたがしていることでしょうか？しかし、これがなぜ問題なのかは言っていませんでした（ただ1つのツールを使用したくないのですか？）。

興味深いことに、これはただのヒントです。GUIDパーティションテーブル（GPT）ディスクに。qemu-imgディスクに何があるかはあまり気にしないでください。しかし、vboxmanageヘルパー機能だけで十分です。

ディスクへ

/dev/ada0したがって、asのフルソースコピー（またはQemuによって作成されたソースファイル）がある場合は、ada0.ddそのイメージを仮想メモリディスクとして使用できます。

# mdconfig -a -t vnode -u 0 -f /home/johndoe/ada0.dd

/dev/md0これにより、完全なディスクが提供されます。

これで、すべてがよく見えることを確認できます。

# fdisk /dev/md0

これは前のディスクとまったく同じでなければなりません。

# glabel status

GPTを使用するときは、次のことを好むことができます。gpart

# gpart create -s gpt /dev/md0

UUIDはこのコマンドを使用して自動的に生成されます。実際、パーティションテーブルのエントリに触れるかどうかはわかりません。このような場合は、まずバックアップしてください。たぶんテーブル全体を破壊するかもしれません。作成して復元しますか？ここではいくつかのテストを実行する必要があります。しかし、重要なのは、ドライブへのフルアクセス権があることです。

以下を使用してファイルシステムをマウントできます。この方法しかも

ファイルとして

GUIDパーティションテーブルの回路図を見るとウィキペディアパーティションテーブルヘッダのオフセット56で混合エンディアンディスクGUIDが見つかったと聞きました。

したがって、ディスクイメージをマウントする代わりに、単にバイトの束と考えることができます。 512バイトセクタを使用していると仮定しますが、4Kセクタに合わせて調整する必要があるかもしれません。ヘッダはＬＢＡ１にあり、オフセット５６に興味がある。したがって、512 + 56 = 568です。

$ hexdump -v -s 568 -n 16 -e '1/1 "%.2x\n"' /home/johndoe/ada0.dd

その後、必要なバイトだけを簡単に変更できます。 Hexdumpでは十分ではありません。見てください。xxd付属編集/vim。ウイデゲン正しいGUIDを生成するのに役立ちます。

このルートに移動する場合は、次の点に注意してください。

• 何かを書く前に、「EFI PART」の署名を確認してスクリプトの弾力性を確保してください。
• また、変更する必要があるヘッダーのセカンダリコピーもあることを覚えておいてください（オフセット32を参照してください）。

これは面白い小さなスクリプトになります。

ストリームメディア

私はあなたが本当に欲しいものが元の生の画像を元の状態に保ち、即座に作業を行うことであるという秘密の疑いがあります。私たちは部分的にxxdサポートを提供stdinしstdout、パイプを介して接続することができます。残念ながら、それはqemu-imgサポートのようには見えませんstdin。

その後、ディスクにファイルが必要です。実用的な解決策は、元のファイルをバックアップとして保持し、新しいコピーを使用して変更することです。これはディスク容量のコストだけ増加します。

ただし、FreeBSDを使用すると、ディスク容量を節約し、コピーを避けるための非常に高速な方法があります。 ZFSは有利に使用できる。新しいデータセットを作成し、元のイメージファイルをここに配置してからスナップショットを作成します。その後、ファイルを直接変更できますが、変更されたバイト（または変更されたセクタ）にのみ影響します。完了したら、スナップショットをロールバックしてそのセクタをすばやく復元できます。

すべてのスナップショットを撮りたくないので、特定のデータセットを作成します。

# zfs create zroot/rawfiles

必要なデータをここに入れて、/rawfilesきれいな状態のスナップショットを作成します。

# zfs snapshot zroot/rawfiles@cleanstate

その後、潜在的に大きなイメージファイルで数バイトを変更できます。きれいな状態に戻りたいときにロールバックします。

# zfs rollback zroot/rawfiles@cleanstate

スペース制約がある場合、これは高速で実行可能なオプションです。このようなことをしている場合は、ロールバックを続行する場合は競合状態に注意してください。

これを備えてこれをバックアップとして持っている場合は、別々のデータセットの作成をスキップし、zfs snapshot zroot@hailmary問題が発生した場合にのみ実行できます。cp /.zfs/snapshot/hailmary/......

手動

画像生成プロセスに影響を与える場合、いくつかの興味深いオプションもあります。

qemu-img新しい画像を作成し、それをマウントし、GPT（新しいGUIDを含む）を生成するために使用できます。

# qemu-img create -f raw VM10G.raw 10G
# mdconfig -a -t vnode -u 0 -f VM10G.raw
# gpart create -s gpt /dev/md0

しかし、ファイルだけなのでqemu-img。

# truncate -s 10g VM10G.raw
# mdconfig -a -t vnode -u 0 -f VM10G.raw
# gpart create -s gpt /dev/md0

バラより最初からUFSブータブルイメージの構築

私はこれをなぜ見せていますか？まあ、多分あなたはこの文脈で何かをしているかもしれません。 FreeBSDには非常に賢いトリックがあります：ムジンガ(1)。

これにより、FreeBSDはディスクイメージを作成し、QCOW、QCOW2、動的VHD、固定VHD、VMDK、RAWをサポートします。つまり、VMDKに直接移動できます。

mkimg -f vmdk -s gpt -b /boot/pmbr -p freebsd-boot:=/boot/gptboot -p freebsd-ufs:=root-file-system.ufs -p freebsd-swap::1G -o gpt.vmdk

この例はFreeBSD中心ですが、rawパーティションを使用しています。したがって、ソース全体のディスクイメージからパーティション専用イメージにソースを変更する場合は、作業パスが必要です。