I realized later the post above is likely wrong or misleading... Keep in mind that how you do a restore depends on what is in the DMG you are trying to restore.
If the DMG is collection of files like a zip file, something like above will work to restore to the volume "MacintoshHD". The target APFS container should have the 3 system partitions, so you don't want to only create the data partition, but all three. The preboot partition can only be updated once there is actual OS on the data partition since that is where the preboot info comes from. Also, the recovery volume will exist, but simply be blank.
If DMG is an image of an APFS container, then all that stuff above does not need to be done, just create the container to restore to. (See [https://www.jamf.com/jamf-nation/discussions/25954/creating-restoring-deployment-images-in-high-sierra#responseChild173296] for some possibly other useful information)
Just do something like this, disk0 is physical disk node, disk1 is container disk if current volume is APFS, otherwise hfs will only need physical disk:
diskutil unmountdisk force /dev/disk1
diskutil unmountdisk force /dev/disk0
diskutil eject /dev/disk1
diskutil erase disk apfs MacHD gpt /dev/disk0
After that, there will be a container disk device node as well as the physical disk device node. Restore the DMG-of-an-APFS-container to the container disk device node, not the physical disk device node in Disk Utility or using asr.
.
The idea is that APFS filesystem can be thought of like files in a partition that are loop-back mounted. There is a Physical Disk that has two partitions on it, the Fat32 (I think) EFI partition for boot and another partition has in it one 'large file' the represents a complete filesystem. That large file is re-mounted as a disk itself (similar to the way virtual machine disk files are mounted for the virtual system), which is the 'container disk'. I don't think there actual is a "filesystem wwith a file in it that is loopback-mounted" but that the whole partition content itself is loopback mounted, but I'm not sreally sure how this works out.
As I understand, in that loop-back mounted file that is the container disk, are the objects representing actual 'files' which are tagged as belonging to a particular volume. All the objects are just in one big pile and the only thing distinguishing them as belonging to one "APFS volume" or another in that container file is that tag. This is why volumes can grow or shrink easily, because there is no actual 'partitioning' of volumes in the container. Setting a volume size directly is accomplished by just setting the arbitrary quota min-max values to the same number. This is also why one cannot really take an image of just a single volume in a container, because there is no concept of a 'single volume' in the structure of the container.
.
PhysicalDisk /dev/disk0 |--->-- loop-back mounted to --> Container disk /dev/disk1
| | |
EFI Partition | ---------------------------------------------------
| | | Large pile Preboot |
APFS partition ^ | of files tagged Recovery |
| | | for volumes VM |
|---- | | Macintosh HD |
large APFS container file --->- |-------------------------------------------------|
.
Internally in the container file, the filesystem type is (I think) a copy-on-write filesystem (CoW ... Incidentally, this is why the linux-land filesystem for suse was called btrfs 'butter fs' because "cow"... oi). This fact is what allows it to be inherently producing "versions" of files and for "copy" operations to be extremely fast.. unless the contents have been modified, it's not actually copying anything except some file header information when you make a direct copy. THIS also complicates the idea of "copying a volume bit-by-bit" or partition, in that the structure of the data inside that filesystem is not as straightforward. You can copy bit-for-bit, the "whole system" but not portions of the system.
I should note that all the above is gleaned information, not gained from an authoritative source, so if it's wrong, tell me
