Bearbeiten (1&2):

Bearbeiten (1&2):

Bearbeiten (1&2):

Ich habe mein funktionierendes Betriebssystem geklont (ausgeschaltet, Festplatte auf USB-Laufwerk gemountet,

> dd if=/dev/sdc1 of=/data/system.img

Die Original-SSD sieht wie folgt aus:

> 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

Um eine VM mit nur der ersten Partition zu erstellen, habe ich mich von dem folgenden Artikel inspirieren lassen:Technische Hinweise: Konvertieren eines Partitionsimages in ein bootfähiges Disk-Image.

Ich habe ein vollständiges Disk-Image rekonstruiert:

> dd if=/dev/zero of=d.img count=1 bs=1MiB

Beginnen wir mit dem Header eines normalen modernen Systems (beginnend mit einer leeren Tafel mit 2048 Blöcken zu je 512 Bytes) – aber anders als mein altes System, das nur einen 512-Byte-Block hatte.

> 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)

Partition neu erstellen (n (+ alle Standardeinstellungen, Nein zum Entfernen der vorhandenen Ext4-Signatur gesagt), a (bootfähig machen), 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

Ich kann das Bild also definitiv sehen, aber GRUB in QEMU erkennt die Partition irgendwie nicht:

> qemu-system-x86_64 d.qcow2

Bleibt unter grub_rescue stehen und gibt an, dass es die UUID wie oben nicht erkennt. Und was ich sehen kann, ist:

> ls
(hd0) (fd0)

Eine Sache, die ich anders gemacht habe als in dem Artikel, von dem ich inspiriert wurde, ist, dass ich das lokale (alte) grub-install(im chroot) anstelle des Hostsystems verwendet habe. Und wenn ich „file d.img“ vorher und nachher überprüfe, zeigt sich ein Unterschied, also ist das vielleicht der Punkt, an dem es kaputt geht, obwohl ich es immer wieder mounten kann und fdiskvorher und nachher dieselben Daten anzeigt:

Vorher 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
Nachher:d.img: DOS/MBR boot sector

Ich habe keine Ahnung, warum die gültige Partition nicht angezeigt wird.

Ursprüngliche Frage:

Kontext:
Ich habe mein aktuelles Betriebssystem (Ubuntu 10.04) von einer einzelnen Partition auf einer nicht gemounteten SSD geklont.

dd if=/dev/sdc1 conv=sync,noerror bs=100M of=/data/system.img

Habe das Rohbild auf meinem neuen U18.04-System in qcow2 konvertiert (beide Bilder befinden sich auf einer vom Betriebssystem getrennten ext4-Datenpartition):

qemu-img convert -f raw -O qcow2 system.img system.qcow2

Der Start schlägt offensichtlich fehl (qemu-kvm meldet dies geom errorbeim Bootversuch).

Ich möchte nicht die ganze Festplatte kopieren, da sie zu groß ist (sehr langsam und für meinen Zweck unbrauchbar).
Mir ist jedoch klar geworden, dass diese Methode wichtige Festplattensektoren nicht kopiert - darunter auch den MBR beim GRUB-Boot.

Daher habe ich auch die ersten 512 Bytes in eine separate Datei kopiert:

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

Jetzt sieht es so aus, als würde das System starten, aber es friert während des Bootvorgangs für immer ein. Es sagt, Booting from hard disk...bleibt aber hängen.


SW-Versionen:

> 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

Problem:

Dieses Image bootet nicht unter KVM:

qemu-system-x86_64-spice -hda system2.qcow2 -m 4096

oder

qemu-system-x86_64 -hda system2.qcow2 -m 4096

oder

qemu-system-x86_64 -hda system2.qcow2 -m 4096 -no-acpi

Das Ergebnis ist ähnlich: Das QEMU-Fenster hängt während des Startvorgangs, wobei eine CPU zu 90–100 % ausgelastet ist, bis ich es beende.

Was mache ich falsch und welche Anleitung muss ich lesen, damit dies funktioniert, ohne die gesamte Festplatte kopieren zu müssen?

Antwort1

/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

Versuche dies:

$ 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

Die Befehle mit der #Eingabeaufforderung müssenschreibgeschütztZugriff auf Ihre Festplatte (d. h. Sie sollten sie als Root ausführen). Sie sollten nur in die Sparse- disk.imgDatei schreiben, aber das sollten Sie besser zweimal überprüfen ;-)

Das resultierende Image ist möglicherweise nicht direkt bootfähig, wenn Grub oder ein anderer Bootloader seine 2. oder 3. Stufe auf einer Partition gespeichert hat, über die Sie nicht kopiert haben (sdc5 oder sdc6).

Du solltestnichtführen Sie aus grub-install. Wenn Sie überprüfen möchten, ob die Partitionierung ordnungsgemäß funktioniert hat, können Sie Folgendes tun (vor dem Löschen disk.img):

# kpartx -l disk.img

# kpartx -a disk.img  # even try to attach ...
# mount /dev/mapper/loop0p1 /mnt/tmp  # and mount it

verwandte Informationen