Idea

125 views
Skip to first unread message

Gregory Neagle

unread,
Jul 19, 2017, 10:40:27 PM7/19/17
to imag...@googlegroups.com
I use Imagr for more that restoring images built with AutoDMG. I have two other types of workflows:

1) A workflow that installs my "bootstrapping" packages: packages that install a local admin account, disable the setup assistant, and install and configure the Munki tools. Upon reboot, the machine can then finish bootstrapping via Munki.

2) Workflows that _install_ macOS (rather than restore an image). Prior to the release of 10.12.4, these workflows simply installed a package built using the createOSXinstallPkg tool set.

But 10.12.4 broke createOSXinstallPkg in some significant ways, and I plan to do no further development on it. Munki has moved to using the startosinstall tool inside the Install macOS application. But that tool no longer allows installs on volumes other than the current startup disk, and has other strange behaviors that make it a poor fit for part of an Imagr workflow. So what can we do?

We could steal code from AutoDMG. AutoDMG installs macOS and additional packages on a disk image --I don't think it would be difficult to modify the code to install macOS on a target volume instead. The one (admittedly major) limitation as compared to the createOSXinstallPkg method: this proposed method could only install a version of macOS that closely matched the version of the OS that is the basis of the boot disk -- so you need to be booted from a Sierra volume (netboot or local disk) in order to install Sierra on the target volume.

If we implemented something along these lines we would not need to replicate the code in AutoDMG that installs additional packages -- that could be handled by Imagr's existing package installation methods.

Thoughts? Is this worth working on?

-Greg

Graham Gilbert

unread,
Jul 19, 2017, 10:47:44 PM7/19/17
to imag...@googlegroups.com
If this is going to be valuable to you, go for it. Indications are that ASR will be updated to work with APFS, so that solves my use case.


--
You received this message because you are subscribed to the Google Groups "imagr-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to imagr-dev+unsubscribe@googlegroups.com.
To post to this group, send email to imag...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/imagr-dev/757E2265-FD84-49DF-B0CA-4182889AA2B5%40mac.com.
For more options, visit https://groups.google.com/d/optout.

Gregory Neagle

unread,
Jul 19, 2017, 10:52:57 PM7/19/17
to imag...@googlegroups.com
I like having options. I could just build NetInstall nbis in order to be able to install macOS. I'll need to think about this. 

Sent from my iPhone
To unsubscribe from this group and stop receiving emails from it, send an email to imagr-dev+...@googlegroups.com.

To post to this group, send email to imag...@googlegroups.com.

Erik Gomez

unread,
Jul 19, 2017, 11:03:01 PM7/19/17
to imag...@googlegroups.com
This seems like a lot of work with small benefits.

What are you gaining from a full install? Firmware updates? If so, perhaps it would be better suited to focus on that.

Thanks,
Erik Gomez
From: imag...@googlegroups.com <imag...@googlegroups.com> on behalf of Gregory Neagle <gregn...@mac.com>
Sent: Wednesday, July 19, 2017 9:52:43 PM
To: imag...@googlegroups.com
Subject: Re: [imagr-dev] Idea
 

Gregory Neagle

unread,
Jul 19, 2017, 11:06:09 PM7/19/17
to imag...@googlegroups.com
I don't know how much work it will be. Maybe an afternoon's worth?  I bet I'll spend as much time setting up an Imagr dev/test environment. 

As for why: have you never had to install macOS? The target volume doesn't have to be _empty_...

Sent from my iPhone

Erik Gomez

unread,
Jul 19, 2017, 11:15:41 PM7/19/17
to imag...@googlegroups.com
For recovery purposes here and there but it usually never works.

But at this point with the fixes to internet recovery + caching server it's not a huge issue. Maybe a few mins difference.

Thanks,
Erik Gomez
Sent: Wednesday, July 19, 2017 10:06:06 PM

Gregory Neagle

unread,
Jul 19, 2017, 11:16:50 PM7/19/17
to imag...@googlegroups.com
It's OK if you won't use it. I won't make you. 

Sent from my iPhone

Erik Gomez

unread,
Jul 19, 2017, 11:25:34 PM7/19/17
to imag...@googlegroups.com
:)

Thanks,
Erik Gomez
Sent: Wednesday, July 19, 2017 10:16:47 PM

Gregory Neagle

unread,
Jul 19, 2017, 11:33:51 PM7/19/17
to imag...@googlegroups.com
I'm guessing that there really won't be much work to implement this:

Admin needs to make the appropriate InstallESD.dmg available on the Imagr web server.

Imagr would mount the dmg, then run `installer -pkg /path/to/mounted/InstallESD.dmg/Packages/OSInstall.mpkg -target <target_volume>`

The _only_ difference from a "normal" Imagr pkg install is the path to the package on the dmg.

But there should probably be some sanity-checking to ensure that the OS version in the InstallESD.dmg has the same major version as the currently booted OS.

-Greg

Reply all
Reply to author
Forward
0 new messages