編集（1＆2）：
動作中のOSをクローンしました（電源オフ、HDをUSBドライブにマウント、
> dd if=/dev/sdc1 of=/data/system.img
元の SSD は次のとおりです。
> sfdisk -d /dev/sdc
# partition table of /dev/sdc
unit: sectors
/dev/sdc1 : start= 63, size= 92164842, Id=83
/dev/sdc2 : start= 0, size= 0, Id= 0
/dev/sdc3 : start= 0, size= 0, Id= 0
/dev/sdc4 : start= 92164905, size=884603160, Id= 5
/dev/sdc5 : start= 92164968, size= 33559722, Id=82
/dev/sdc6 : start=125724753, size=851043312, Id=83
最初のパーティションのみを持つ VM を作成するには、次の記事を参考にしました。技術ノート: パーティションイメージを起動可能なディスクイメージに変換する。
完全なディスクイメージを再構築しました:
> dd if=/dev/zero of=d.img count=1 bs=1MiB
通常の最新システム ヘッダー (512 バイトのブロックが 2048 個ある空白の状態から開始) から開始します。ただし、512 バイトのブロックが 1 つしかなかった古いシステムとは異なります。
> pv system.img >> d.img # to paste sdc1 onto that header
> file d.img
d.img: data
> fdisk d.img # to initialise the header suitably (create the partition)
パーティションを再作成します (n (+すべてデフォルト、既存の ext4 署名の削除を拒否)、a (起動可能にする)、w)
> file d.img
d.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS \
(0x0,32,33), end-CHS (0x275,145,28), startsector 2048, 92364800 sectors
> cp d.img e.img # take a backup
> file e.img
e.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS \
(0x0,32,33), end-CHS (0x275,145,28), startsector 2048, 92364800 sectors
> losetup -f -P d.img
> losetup -l
/dev/loop4 0 0 0 0 /data/d.img 0 512
> blkid
/dev/loop4: PTUUID="55733c83" PTTYPE="dos"
/dev/loop4p1: UUID="437b9924-b81d-4054-b89e-b1ce0cf2a2c7" TYPE="ext4" PTTYPE="dos" PARTUUID="55733c83-01"
> mkdir d
> mount /dev/loop4p1 d/
> ll d
> mount --bind /dev d/dev
> mount --bind /sys d/sys
> mount --bind /proc d/proc
> chroot d
> ls -al /boot/grub
> less /boot/grub/grub.cfg
<...>
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set 437b9924-b81d-4054-b89e-b1ce0cf2a2c7
<...>
> grub-install /dev/loop4
Installation finished. No error reported.
> vi etc/fstab
# uncomment swap and /data, just keep the root partition (which includes /boot)
> exit # come out of the chroot environment
> umount d/sys
> umount d/proc
> umount d/dev
> umount d/
> losetup -d /dev/loop4
> qemu-img convert -f raw -O qcow2 d.img d.qcow2
つまり、イメージは確かに表示されますが、どういうわけか qemu の GRUB はパーティションを表示できません。
> qemu-system-x86_64 d.qcow2
grub_rescue で停止し、上記のように UUID が認識されないことが示されます。表示される内容は次のとおりです。
> ls
(hd0) (fd0)
私がインスピレーションを得た記事と違う点は、ホストのシステムではなく、ローカル (古い) grub-install( 内chroot) を使用したことです。また、前後で「ファイル d.img」をチェックすると違いが見られるので、何度でもマウントでき、fdisk前後で同じデータが表示されるにもかかわらず、おそらくそこが壊れている部分です。
ビフォアーd.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0x275,145,28), startsector 2048, 92364800 sectors
アフター：d.img: DOS/MBR boot sector
有効なパーティションが表示されない理由はわかりません。
元の質問:
コンテクスト：
マウントされていない SSD 上の単一のパーティションから現在の OS (Ubuntu10.04) をクローンしました。
dd if=/dev/sdc1 conv=sync,noerror bs=100M of=/data/system.img
新しい U18.04 システムで RAW イメージを qcow2 に変換しました (両方のイメージは OS とは別の ext4 データ パーティションに存在します)。
qemu-img convert -f raw -O qcow2 system.img system.qcow2
これは明らかに起動に失敗します (qemu-kvm がgeom error起動しようとすると表示されます)。
ディスク全体が大きすぎるため、ディスク全体をコピーしたくありません (非常に遅く、私の目的には役に立ちません)。
ただし、この方法では、GRUB ブートの MBR を含む重要なディスク セクターをコピーできないことが明らかになりました。
そこで、最初の 512 バイトも別のファイルにコピーしました。
dd if=/dev/sdc of=/data/sdc-512B.img bs=512 count=1 conv=sync,noerror
cat sdc-512B.img system.img > system2.img
qemu-img convert -f raw -O qcow2 system2.img system2.qcow2
システムは起動しているように見えますが、起動中に永久にフリーズします。「Booting from hard disk...しかし、そこでハングします」と表示されます。
SW バージョン:
> qemu-system-x86_64 --version
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14)
> uname -a
Linux <hostname> 4.18.0-18-generic #19~18.04.1-Ubuntu SMP Fri Apr 5 10:22:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
問題：
このイメージは kvm では起動しません:
qemu-system-x86_64-spice -hda system2.qcow2 -m 4096
または
qemu-system-x86_64 -hda system2.qcow2 -m 4096
または
qemu-system-x86_64 -hda system2.qcow2 -m 4096 -no-acpi
結果は同様です。qemu ウィンドウは起動プロセス中にハングし、終了するまで 1 つの CPU が 90 ～ 100% で動作します。
何が間違っているのでしょうか? また、ディスク全体をコピーせずにこれを機能させるには、どのガイドを読む必要がありますか?
答え1
/dev/sdc1 : start= 63, size= 92164842, Id=83 /dev/sdc2 : start= 0, size= 0, Id= 0 /dev/sdc3 : start= 0, size= 0, Id= 0 /dev/sdc4 : start= 92164905, size=884603160, Id= 5 /dev/sdc5 : start= 92164968, size= 33559722, Id=82 /dev/sdc6 : start=125724753, size=851043312, Id=83
これを試して：
$ dd if=/dev/null of=disk.img seek=$((125724753 + 851043312))
# create a big sparse file, the same size as /dev/sdc
# dd if=/dev/sdc of=disk.img conv=notrunc count=$((63 + 92164842))
# copy through the mbr + gap + 1st partition into place
# sfdisk -d /dev/sdc | sfdisk disk.img
# replicate the complete partitioning of /dev/sdc onto disk.img
$ qemu img convert -O qcow2 disk.img disk.qcow2
# convert the raw image to qcow2
#プロンプト付きのコマンドは読み取り専用ディスクへのアクセスを許可します (つまり、root として実行する必要があります)。スパースdisk.imgファイルにのみ書き込む必要がありますが、2 回確認することをお勧めします ;-)
grub またはその他のブートローダが、コピーしなかったパーティション (sdc5 または sdc6) に第 2 段階または第 3 段階を保持している場合、結果のイメージは直接起動できない可能性があります。
あなたがすべきないを実行しますgrub-install。パーティション分割が正常に行われたかどうかを確認したい場合は、( を削除する前にdisk.img) 次を実行できます。
# kpartx -l disk.img
# kpartx -a disk.img # even try to attach ...
# mount /dev/mapper/loop0p1 /mnt/tmp # and mount it