Этот ответ пришел мне в голову и не проверен. Если вы проверите это, не стесняйтесь обновлять ответ.

К сожалению, у вопроса очень мало контекста, чтобы объяснить, почему мы это делаем. На первый взгляд мы могли бы просто обратиться к qemu -img и дать ответ :№

Но это было бы скучно. Вместо этого давайте сделаем несколько диких предположений и будем работать с ними.

То, что вы описываете как решение, возможно во FreeBSD с помощью qemu-imgиз emulators/qemu -utils и vboxmanage из emulators/virtualbox -ose . Может быть, это то, что вы делаете? Но вы не указываете, почему это проблема. (Может быть, вы просто хотите использовать на один инструмент меньше? ).

Интересно, что это только подразумевается. :Вы используете таблицу разделов GUID (GPT)на своем диске. qemu-imgна самом деле не заботится о том, что находится на диске, тогда как vboxmanageдостаточно хорош, чтобы иметь вспомогательную функцию.

Как диск

Таким образом, если у вас есть полная исходная копия /dev/ada0какada0.dd(или просто необработанный файл, созданный в Qemu )-, вы можете использовать образ в качестве диска виртуальной памяти:

# 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 из Википедии , нам говорят, что мы находим GUID диска со смешанным порядком байтов в заголовке таблицы разделов по смещению 56.

Таким образом, вместо того, чтобы монтировать образ диска, мы можем просто обращаться с ним как с набором байтов. Я предполагаю, что вы используете сектора по 512 байт, но вам может потребоваться настроить для секторов по 4 КБ. Тогда заголовок находится на LBA 1, и нас интересует смещение 56 -, таким образом, 512 + 56 = 568

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

Затем мы можем просто изменить необходимые байты. Hexdump для этого недостаточно, и вам следует взглянуть на xxd , который поставляется с editors/vim . uuidgen может помочь вам сгенерировать правильный идентификатор 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:mkimg (1).

Благодаря этому вы можете создавать образы дисков во FreeBSD, и она поддерживает форматы QCOW, QCOW2, Dynamic VHD, Fixed 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, но использует необработанные разделы. Поэтому, если вы измените свой источник с необработанного полного образа диска на просто образы разделов, у вас должен быть жизнеспособный маршрут.