Import .dmg of an existing partition?

[arekkusu42]

Greetings, I am attempting to set up UTM 4.4.5 on an M3 Macbook Pro running Sonoma 14.3.
The guides (and adespoton/utmconfigs) I have read all document installing an fresh OS from a boot ISO.

However, I already have every version of Mac OS X from 10.2 - 10.15 installed (and configured with devtools and licensed software etc) on old physical PPC and Intel Macs. I would like to create a .dmg of these partitions and then import the pre-installed/configured OS into UTM.

In other words: "copy old Mac into VM on new Mac."

This seems like a very obvious use case, is it possible?

I have tried creating a new UTM VM (following e.g. adespoton/utmconfigs/10.9 Mavericks), and replacing the IDE drive with a new one, importing from a compressed .dmg imaged from a partition with Disk Utility. This appears to work-- it copies the .dmg inside the .utm and converts it into a .qcow2 image. However, the resulting VM immediately fails during boot:

Loading kernel cache file 'System\Library\Caches...'
....Read error 0x2
...
...Error reading driver 'System\Library\Extensions...'
and then panics.

I tried a couple variations on this, with compressed .dmg, read-only .dmg, and .cdr, but none work (all IDE drives configured in the VM as NOT read-only.)

Any tips?

[johnkgibson]

Try an uncompressed read/write image.

Once that is finished you want to convert it to a CDR master. In disk Utility use the convert menu

In the convert dialog make your settings

Once you do this, you will see your disk image with the extension.cdr (unless you have don't show extensions on for your system)
Change the disk image extension to .ios. I suggest using the Get Info command.

Then try installing whatever system you want on it and test it out.

[arekkusu42]

Thank you for the reply. Unfortunately, this does not work. And, I do not want to create a new uncompressed read/write image and then install a new system on it. As I wrote, I already have every OS installed on real partitions:

If I create an uncompressed read-write .dmg from one of these partitions, UTM will (silently) fail to import it. If I convert that .dmg to a .cdr (or renamed .iso, or a read-only .dmg) then it will import and convert to qcow2, but the resulting image doesn't boot, with the aforementioned "Read error 0x2".

Any other suggestions to copy-old-Mac-into-VM?

Alternatively, what would be even better (considering Time Machine interactions with huge files) would be a way to boot the VM from a mounted /Volume. That way I could keep a regular read-write (sparse) .dmg, excluding the .dmg itself from Time Machine, but mount it when I want to use the VM and allow Time Machine to back up individual files within the /Volume.

[johnkgibson]

Let me do some testing. I've been building different VMs lately because I'm trying to preserve copies of my old systems.

[johnkgibson]

Hey, Can you message me? I am working on a setup like yours but have a few questions.

[arekkusu42]

What do you need to know?

This is how I set up:

1. Because UTM doesn't include a preconfigured Mac template, instead start with i.e. OS X 10.9 (config only) which includes OVMF.bin and EFI-LEGACY.qcow2 drives, along with instructions for installing an OS from an .iso.
2. In that config's System settings, turn off "Force Multicore" because x86_64 multicore emulation on arm64 doesn't work.
3. In that config's Drives, delete the empty disk-0.qcow2 IDE drive, and the CD/DVD (ISO) image drive.
4. Add a new IDE drive, and in the little floating pop-over, Import a .dmg created from an existing Mac partition. As written above, depending on the format of that .dmg, UTM will either silently fail, or convert it into a .qcow2.
5. Boot the configured VM, and watch it go through the BIOS and immediately fail to load kernel with Read Error 0x2.

[johnkgibson]

I don’t have a working 10.9 installer which I can find. The problem of having a large collection of external drives. I’m in process of consolidating all those drives to a couple raid systems. I can send a link for my Google Drive. Would you compress the installer and upload it. Thanks, believe it or not, I find pleasure in working with UTM, I no longer need Parallels licenses. What do you need to know? This is how I set up: Because UTM doesn't include a preconfigured Mac template, instead start with i.e. OS X 10.9 (config only) which includes OVMF.bin and EFI-LEGACY.qcow2 drives, along with instructions for installing an OS from an .iso. In that config's System settings, turn off "Force Multicore" because x86_64 multicore emulation on arm64 doesn't work. In that config's Drives, delete the empty disk-0.qcow2 IDE drive, and the CD/DVD (ISO) image drive. Add a new IDE drive, and in the little floating pop-over, Import a .dmg created from an existing Mac partition. As written above, depending on the format of that .dmg, UTM will either silently fail, or convert it into a .qcow2. Boot the configured VM, and watch it go through the BIOS and immediately fail to load kernel with Read Error 0x2. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[arekkusu42]

If you don't have the Mavericks installer in your AppleID's App store purchases, then you can easily find copies on archive.org.

But you can try any OS version. I got similar Read Error 0x2 failures with a .dmg made from my 10.12.6 Sierra partition.

[arekkusu42]

After a lot of investigation, I have a conclusion:
This problem happens because the .qcow2 created by UTM does not have any formatted partition.

When UTM "Import"s a disk (compressed .dmg, or .cdr) it uses qemu-img to convert to .qcow2.
The result is a correctly-restored Mac volume, but inside of an unformatted disk, which isn't bootable (there is no GUID or Apple partition scheme to boot.)

(Obvious in hindsight. I still feel this should "just work", but UTM would need to guess the user's intent when "Import"ing,
i.e. determine if the disk being imported contains a bootable OS, and if so, of which architecture/filesystem vintage, and then follow the below recipe.)

After even more experimentation (dozens of hours of rsync/dd/restoring in VMs), I have a (fast) workaround which does not require going through any OS install.
Here is a recipe to clone old physical partitions directly into new UTM VMs, using Mavericks as an example:
(times noted -> below are on an M3 Max MacBook Pro running Sonoma 14.4)

1. On old Mac, use Disk Utility to create a compressed .dmg of an original partition (while booted into a different partition, or recovery OS.)
   On a physical Mac, you can use Disk Utility to Restore this .dmg to a partition, and then boot it.
   Note that if you mount this .dmg, Disk Utility or "diskutil list" shows it only contains one volume, not a partitioned disk.
2. On host Mac, don't use UTM to "Create" or "Import" a drive (it will be an unformatted partition and fail to boot.) Instead use hdiutil:
   time hdiutil create -size 30g -fs HFS+J -type UDTO -volname RESTORE_ME Mavericks
   The size must be >= the old partition size. UDTO creates a .cdr, but it is really a read-write .img. I haven't verified APFS yet.
   -> 6 seconds (to create empty 30GB .cdr)
   Importantly, this creates a new "RESTORE_ME" volume inside a bootable GUID partition (or for PPC, use -layout SPUD for Apple Partition Scheme.)
   (Alternatively, you can create a raw .img with UTM, and then (slowly) boot into the VM, format it there with one partition, and quit the VM.)
   Mount the new image (or double-click it in Finder):
   hdiutil attach Mavericks.cdr
3. On host Mac, use asr in Terminal to restore the compressed .dmg to the new .cdr:
   time sudo asr restore --source "10.9.5_Mavericks_cmp.dmg" --target /Volumes/RESTORE_ME --erase --noverify
   It will ask permission to "erase contents of /dev/disk#s2", note that the target volume is a partition (with "s"), not a whole disk.
   -> 14 seconds (to restore 20GB of data from compressed 7GB .dmg)
   The mounted volume is now renamed, and contains the original partition's content. Eject it (or use Finder):
   hdiutil detach /dev/disk#
4. Convert the .cdr back into UTM's preferred .qcow2 format
   Use qemu-img for this, which is built into UTM, but unfortunately UTM has compiled it as a .dylib instead of an executable.
   You can download a working executable from the Emaculation forum.
   time qemu-img convert -O qcow2 Mavericks.cdr Mavericks.qcow2
   -> 3 seconds (to compress 30 GB .cdr to 8GB .qcow2)
   Move the .qcow2 into VM.utm/Data/ and delete the huge .cdr file.
   In VM.utm/config.plist, edit the "Drive" entry's "ImageName" to use the newly created .qcow2
5. re-launch UTM, verify the VM's settings show the proper disks, and launch the VM.
   The guest Mac now boots without Read errors (because the partition is properly formatted.)

Bonus: for an Intel OS, I do a little VM-specific tuning on the restored image:

1. Fix the (single) boot resolution (from 16:9 to 16:10 to fit my laptop screen)
   In the VM's settings, temporarily un-check "Read Only" on the USB Drive "EFI-LEGACY.qcow2".
   Boot the VM.
   In the guest Mac, edit /Volumes/EFI-LEGACY/EFI/OC/config.plist, and search for "Resolution".
   Change 1280x720 to 1280x800.
   Shut down the VM, and in the settings re-check "Read Only".
2. Prevent the EFI volume from mounting
   In the guest Mac, sudo vifs, and add the following line:
   LABEL=EFI-LEGACY none msdos ro,noauto
   Reboot the VM.

These VMs (based on adespoton's configs) work well enough to run Xcode, Photoshop, etc. But, they:

• crash in CoreGraphics when running any 32-bit GUI app
• frequently assert during boot if Force Multicore is on
• have working network, but very slow files transfers from the host over smb (i.e. restoring an 8GB .dmg takes 14 seconds on the host, but several hours over smb.)
• have only one resolution, and custom settings (like 1512x945) don't "just work"
• have no audio (or glitchy audio, on PPC)
• have no GPU
  These problem remain unsolved...

[johnkgibson]

Hey, I'm sorry. I'm having major issues with my family at this point, and my attention is on them. I am still interested in seeing if we can get this working. Thanks.

[arekkusu42]

Root-caused the CoreGraphics 32-bit crash. Tracking it in UTM #5371 although a QEMU bug needs to be filed.

[arekkusu42]

The described recipe is a usable workaround for me.

Tracking a UTM enhancement to make this "just work" and avoid needless headaches for new users, over in #6282.