Cannot restore an APFS disk image with asr

I'm working within the Recovery Environment, using High Sierra 10.13.0 (public release).


I have made a disk image from an APFS container like this, just as described in the hdiutil man page:

hdiutil create -srcdevice disk2 -format UDZO /Volumes/external-disk/my-image

(disk2 is the /dev node of the APFS container holding all the volumes on this Mac).


And I have also tried like this:

hdiutil create -srcfolder '/Volumes/Macintosh HD' -volname 'Macintosh HD' /Volumes/external-disk/my-image


I then imagescan the "my-image" with

asr imagescan --source /Volumes/external-disk/my-image.dmg


If I made the disk image of the APFS container (ie. "-srcdevice disk2" above), an "asr info" outputs some useful information about the volumes in the container. According to asr's man page, that's what I should be doing.


According to the man page for asr, I should restore the image with

asr restore --source /Volumes/external-disk/my-image.dmg --target '/Volumes/Macintosh HD' --erase

but that always fails as soon as it tries to validate the source, saying the image "doesn't have any appropriate volumes to restore".


If I make the image with the "-srcfolder" option instead, as above, then it restores the blocks into a new file inside /Volumes/Macintosh HD as expected, but then fails with "APFS inverter failed to invert the volume - Invalid argument".


From everything I've read in the man page for asr about using it with APFS, one of these combinations should work.

But neither of them do.

And there is no other documentation available at all, if you ignore the "feature list" document.


Can anyone help, please?

macOS High Sierra (10.13), asr hdiutil disk images

Posted on Sep 28, 2017 9:54 AM

Reply
12 replies

Sep 29, 2017 1:15 AM in response to VikingOSX

No, the man page for asr on 10.13 has an entire section devoted to restoring with APFS filesystems. It starts like this:


"RESTORING WITH APFS FILESYSTEMS

Individual APFS volumes can not be restored directly, because their

device nodes don't allow I/O from a standard process. However, asr can

restore entire APFS containers, including all volumes...."

Nov 16, 2017 9:55 AM in response to JulesFM

Hdiutil invalid argument is where you should probably start.. It means you didn't follow the format required to use create. size_spec is the first thing listed after create so you need to include the disk image's intended size, for example 409600m. Seems like you can specify block size too which probably shouldn't be overlooked.


So create would be failing for that reason but also I'm fairly sure that you're getting ahead of yourself somehow. For creating any volume you should use the disk image's (not .dmg disk image btw) /dev node not the /Volumes directory listing. hdiutil needs that mount point written out like that even though diskutil doesn't mind just saying disk*.


It'd be easiest to create the APFS container and volume(s) with Disk Utility or by using diskutil which is a little less sophisticated than hdiutil but honestly hdiutil is like physics in that no one really understands what the it all means.


newfs_apfs and several options are available too. It makes me wonder if the disk has any issues which might cause problems like the pmap or boot sector and you could run hdituil pmap -complete -debug /dev/[r]disk* or hdiutil fsid -debug /dev/disk*. You'll need to tell whatever you use exactly where on disk2 the volume you will create is no matter what like /dev/disk2s*s* or possibly /dev/disk2s* but I'd think you set it up in a way that would require the three form.


You're also not using asr correctly... imagescan would embed metadata with checksums to validate a disk image in the file so I'm not sure if that's your end goal but it doesn't sound like it? asr is the command line interface for Disk Util's "Restore" feature so again if you have the .dmg file just restore it to. Is that what you wanted it to do? I'm wondering what is in the high Sierra man pages now...might just make a pdf of my current files. asr info will just give you that..info so unless that's what you want that's not what you should be doing.


I'd codesign --verify --vvv -deep your dmg too because really who knows anymore. They're downloaded with SHA1 encrypted certificates (laughable) on HTTP not HTTPS for the actual connection and have other SSL problems so that file could be just about anything really.


I'm confused though...really...seriously why and how did you come across hdiutil and asr?? Is there a reason you don't want to just use Disk Utility to do everything? The .dmg will have an install package and with like two click you could have got everything done with a real live app. Is this something you expect not to have its code signing validate?


It happens a lot where the examples given are not anything that resembles the format at the top of man page but if you look at hdiutil's example, which actually reads:

hdiutil create -volname Dick -size 1.3m -fs HFS+ -attach Moby.dmg


At least someone at Apple has a sense of humor...maybe the entire thing is a joke.

Oct 16, 2017 2:14 AM in response to chris-1111

chris-1111,

I'm trying to restore to the internal SSD on a 2nd Mac (not the one that created the image). You are restoring the image to an external SSD.


I make the image on the initial Mac as a sparsebundle or sparseimage (as recommended by the author of SuperDuper). Then on there I "hdiutil convert" it to a read-only image (UDZO). Then on there I "asr imagescan" it.

Then "asr info --source MacDeployment.dmg" produces exactly the list of volumes in the image that you would expect to see in the image: Macintosh HD, Recovery, Preboot and VM.

I then boot the target Mac into its Recovery environment. It's already been upgraded to High Sierra, so the disk layout is already entirely APFS. There isn't a "sudo" command in the Recovery environment as it's running as root anyway.

Then I do

asr restore --source /Volumes/USB-SSD/MacDeployment.dmg --target /Volumes/Macintosh\ HD --erase

That verifies the source and target, merrily restores the data, happily verifies it, then fails inverting the filesystem with this cryptic error message:

"APFS inverter failed to invert the volume - Invalid argument"


Adding --debug or --verbose (or both) to the asr restore command doesn't change the output at all. And it doesn't log anything to /var/log either.


Any more suggestions please?

Many thanks! Jules.

Oct 3, 2017 6:42 AM in response to JulesFM

I set disk slice as target, and restored from an APFS container image.

asr restore --source /Volumes/sieraUSB/dmgs/NewHSierra.dmg --target /dev/rdisk1s4 --erase


  • BEFORE
  • prepare disk1s4 ( HFS)

riakirazeinoiMac:~ lmr$ diskutil list

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *120.0 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_APFS Container disk2 119.8 GB disk0s2


/dev/disk1 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.0 TB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_HFS Data 869.7 GB disk1s2

3: Apple_HFS sieraHDD 67.1 GB disk1s3

4: Apple_HFS hsierraHDD 62.8 GB disk1s4


/dev/disk2 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +119.8 GB disk2

Physical Store disk0s2

1: APFS Volume hsierraSSD 18.6 GB disk2s1

2: APFS Volume Preboot 22.6 MB disk2s2

3: APFS Volume Recovery 517.4 MB disk2s3

4: APFS Volume VM 20.5 KB disk2s4


/dev/disk3 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *320.1 GB disk3

1: Apple_HFS sieraUSB 320.1 GB disk3s1



  • RESTORE
  • restore to disk1s4

riakirazeinoiMac:~ lmr$ sudo su

Password:

sh-3.2# asr imagescan --source /Volumes/sieraUSB/dmgs/NewHSierra.dmg

Block checksum: ....10....20....30....40....50....60....70....80....90....100

successfully scanned image "/Volumes/sieraUSB/dmgs/NewHSierra.dmg"

sh-3.2# asr restore --source /Volumes/sieraUSB/dmgs/NewHSierra.dmg --target /dev/rdisk1s4 --erase

Validating target...done

Validating source...done

Erase contents of /dev/disk1s4 (/Volumes/hsierraHDD)? [ny]: y

Repartitioning target device...done

Retrieving scan information...done

Validating sizes...nx_kernel_mount:1364: checkpoint search: largest xid 477, best xid 477 @ 9

done

Restoring ....10....20....30....40....50....60....70....80....90....100

Verifying ....10....20....30....40....50....60....70....80....90....100

Remounting target volume...done

sh-3.2# diskutil list

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *120.0 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_APFS Container disk2 119.8 GB disk0s2


/dev/disk1 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.0 TB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_HFS Data 869.7 GB disk1s2

3: Apple_HFS sieraHDD 67.1 GB disk1s3

4: Apple_APFS Container disk4 62.8 GB disk1s4


/dev/disk2 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +119.8 GB disk2

Physical Store disk0s2

1: APFS Volume hsierraSSD 18.6 GB disk2s1

2: APFS Volume Preboot 22.6 MB disk2s2

3: APFS Volume Recovery 517.4 MB disk2s3

4: APFS Volume VM 20.5 KB disk2s4


/dev/disk3 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *320.1 GB disk3

1: Apple_HFS sieraUSB 320.1 GB disk3s1


/dev/disk4 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +62.8 GB disk4

Physical Store disk1s4

1: APFS Volume hsierrassd 11.4 GB disk4s1

2: APFS Volume Preboot 20.4 MB disk4s2

3: APFS Volume Recovery 517.4 MB disk4s3

4: APFS Volume VM 20.5 KB disk4s4

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Cannot restore an APFS disk image with asr

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.