Imaging with ASR in High Sierra 10.13.4 - Something changed!!!

[monaronyc]

What's up everybody!

Ever since High Sierras inception, we've been imaging using the following commands in Terminal. And its been working great for us! To create the image we would use:

hdiutil create -srcdevice disk2 -format UDZO /Volumes/ExternalDiskNameHere/ImageNameHere.dmg

and to restore the image if not scanned, we would use:

asr restore --source /Volumes/ExternalDiskNameHere/ImageNameHere.dmg --target /dev/disk2 --erase --noverify

And if the image was scanned:

asr restore --source /Volumes/ExternalDiskNameHere/ImageNameHere.dmg --target /dev/disk2 –erase

Now that 10.13.4 was released, the hdiutil command to create the .dmg still works, but the asr restore command does not. When we try to restore with ASR, we get:

Couldn't find container disk for Image "image .dmg path" on the external drive, and Couldn't attach source image "image path to .dmg". Could not validate source - Invalid Argument

We've searched high and low with no avail. Anyone familiar with ASR and can maybe help us out? What the heck changed that we can't image like this anymore?!?! Thanks a bunch!

[Nix4Life]

Still works for me. This was on the 3/29 release of 10.13.4. I have not tried the 4/5 release of 10.13.4 . Same command but over http:
'asr restore --source http://192.168.0.1:8080/restore/10.13.4.apfs.dmg --target /dev/disk0s2 –erase '. However I am really starting to like Google's restor. This is mainly for redeloying hardware. For new hardware its bootstrappr and quickadd.pkg or munki bootstrap/firstboot.pkg

[monaronyc]

@Nix4Life Thanks man! Could it be the way the .dmg is maybe being created? I have the string pointing to disk2:

hdiutil create -srcdevice disk2 -format UDZO /Volumes/ExternalDiskNameHere/ImageNameHere.dmg

Yet when we run the ASR string we get:

Validating target... done
Validating source...
Couldn't find container disk for image "/Volumes/Untitled/10134.dmg"
Couldn't attach source image "/Volumes/Untitled/10134.dmg"
Could not validate source - Invalid Argument

Strange?!?

[Nix4Life]

@monaronyc my apologies, I just realized you were not using AutoDMG. There was a change and it should be reflected in the upcoming AutoDMG release. I am currently working with a pre-release that addresses this issue. One last thing, all devices in the chain are running High Sierra, correct?

[monaronyc]

@Nix4Life That's correct. All devices are now High Sierra. 10.13.4 to be exact.

[j_tanudjaja]

@monaronyc we're on the same boat, interested if you managed to get it working??

[Nix4Life]

Try using new AutoDMG release, it should work now

[j_tanudjaja]

@Nix4Life I'm capturing the whole disk so can't use autodmg

[Nix4Life]

oh @j.tanudjaja are you trying to do mono/thick imaging? yeah you might me pushing the limits. Have you tried the google product I mentioned above? We add 4 packages to the AutoDMG image that are a total of 5mb, then reboot. It may work with your image..good luck

[j_tanudjaja]

yeah trying to do mono, the imacs has logic with all loops and its like 150gb image.

ok will try Restor, missed it!

[j_tanudjaja]

@Nix4Life would you mind explaining how it works? I downloaded restor and nothing is displayed but "Failed to download configuration - Unsupported URL"

[Nix4Life]

@j.tanudjaja

check your plist file. is it a valid URL.IIRC if you use custom you may need an additional forward slash if its a local file(file///:). we host it over http

[monaronyc]

Folks, we had to move a step backwards on this and go back to 10.13.3. Kinda had no choice. Once we did everything worked again. We even compared and checked the man pages for ASR and HDIUTIL in both versions .3 and .4 to see if maybe something changed. Couldn't really find anything. I guess we'll have to wait till .5 releases to see if fixed. Luckily the new machines we've received were all 10.13.3. Just applied the combo update 10.13.4 manually.

[maurits]

@monaronyc Are you imaging APFS or HFS images? That is important since apfs has 'containers' and 'volumes' , and it is important to reference the correct device number. (the container is locally typically numbered like disk1, stored on disk0s2, while the Macintosh HD is disk1s1 , when mounted in target disk, numbers will be different))

[dstranathan]

I have downlaoded Google Restor, but like @j.tanudjaja I cant find any documentation on how to use it. I dont see a .plist file to edit anywhere. Any additional info would be appreciated.

[j_tanudjaja]

Hey @dstranathan you can follow the guide on the github page, I know its not the best doco.

This link is helpful, I followed this to get it to work
https://github.com/google/restor/issues/6

Basically you need 2 .plist file
One in /Library/Preferences/com.google.corp.restor.plist and another one hosted somewhere (e.g dropbox or S3)
Even if you are using a local image, you still need to configure the plist.

in saying that restor will work if you use AutoDMG, but not if you are trying to do mono.

[Nix4Life]

Still works for me. This was on the 6/1 release of 10.13.5 'asr restore --source http://192.168.0.1:8080/restore/10.13.5.apfs.dmg --target /dev/disk0s2 –erase '. Moving current hardware from 10.12.6 to 10.13.5.

[chrisdaggett]

@Nix4Life @monaronyc The problem is not the restore, its the Making/Scanning of the image. Disk Util / HDiutil is doing something wrong now on 10.13.4+

Images captured of containers with 10.13.4+ will not scan or restore.

I also had to go back to a 10.13.3 machine to capture the image of the container, then restoring works fine. I couldn't find any way to get Disk Utility / HDIUTIL to work properly with AFPS/10.13.4

[Nix4Life]

@chrisdaggett I am using a clean OS only AutoDMG file with no issues, have been since 10.13.3. Not sure what happens when additional packages are added or with monolithic imaging/restore

[chrisdaggett]

@Nix4Life Yeah I have no doubt that method works fine (cleaninstall/AutoDMG/etc + packages), the issue is with Disk Util / HDIUTIL which is what the OP was trying so I just wanted to clarify.

If you want to do real imaging you have to use pre-10.13.4 to make the master image.

[angelofilho33]

@chrisdaggett where do I down the pre-10.13.4? in the Apple Store does not have this option

[ImAMacGuy]

it's working with 10.13.5

[taugust04]

@jwojda beat me to it. I can confirm as well that if you build a APFS image of 10.13.5 using the latest AutoDMG on a 10.13.5 system, it works. Again. Casper Imaging restores it down as smooth as butter. :-D

[chrisdaggett]

I dont get all the people commenting about AutoDMG??

You do realize the OP is talking about building an IMAGE, not a fresh install of OSX? and is using HDIUtil not AutoDMG??

It's like someone asking about a specifc problem with their Ford's Ecotec motor and your like Hey my Honda Vtec is running smooth. cool story....

[chrisdaggett]

@angelofilho33 I kept copies in case something like this happened. They are out there for download from other sources though.

[monaronyc]

We just tried this in 10.13.5, with a 10.13.5 image and the ASR restore is still broken. Returns an error of Couldn't find container disk for image. Has anyone been able to figure this one out?

[chrisdaggett]

@monaronyc So far the only solution I have come up with is using 10.13.3, its a PITA but we knew Apple didn't want us to image so no surprise. It still works fine even if the Master is 10.13.5 at least.

[ClassicII]

This is still a problem. Has anyone tested this on 10.13.6 yet ? It would be the last chance to see this fixed on High Sierra :(

[ClassicII]

I am guessing that is a no.

[ImAMacGuy]

Not sure if it's just me, but it appears that it's broken with 2018 MBPs on 10.13.6 (build 17G2307)

$ sudo asr restore --s ~/SOE96_APFS.dmg --t /dev/disk3s2  --erase
Password:
    Validating target...done
    Validating source...done
    Erase contents of /dev/disk4 ()? [ny]: y
    Retrieving scan information...done
    Validating sizes...nx_kernel_mount:1359: : checkpoint search: largest xid 77, best xid 77 @ 153
done
    Restoring  ....10....20....30....40....50....60....70....80....90....100
    Verifying  ....10....20....30....40....50....60....70....80....90....100
    Inverting target volume...done
Personalization failed: Error Domain=OSPErrorDomain Code=103 "The given secure boot bundle is invalid." UserInfo={NSLocalizedDescription=The given secure boot bundle is invalid.}
asr: Couldn't personalize volume /Volumes/Macintosh HD 1

When I ran it off my 2016 MBP w/ 10.13.6 (17G65) the same command ran successfully.