first-boot fails to start after Mojave install about imagr

[grahamgilbert]

Do you see this issue when using the release version?

[grahamgilbert]

And what does the install log say when moving these items?

[pilfs]

I tried imagr-1.4.2 - same thing.

"2018-10-24 15:30:47.275 Imagr[602:74038] Copying first boot pkg install tools"

imagr.log

[grahamgilbert]

You cut the log off before the bit I am interested in. The macOS installer is what is moving these items, I need to know why. It will probably be in /var/log/install.log

[pilfs]

Ah, my bad.
install.log

[grahamgilbert]

I'm at a loss. I can't see anything out of the ordinary in that log. All I have left is suggesting to take all your items out and add them back one at a time in case they're doing anything.

[pilfs]

Bit of an update:

I've verified that /Library/{LaunchAgents, LaunchDaemons, PrivilegedHelperTools} gets written to the target volume correctly before startosinstall.

I assume the Mojave installer sees anything in these directories as "Previous Content" and moves them out of the way as part of the install process.

I've made a workaround by taking everything that is supposed to go in /Library and putting it in a pkg (attached).

Then I let the OSX installer add it as an extra package like so:

<dict>
    <key>type</key>
    <string>startosinstall</string>
    <key>url</key>
    <string>http://192.168.100.7/netboot/osx-10.14.1.dmg</string>
    <key>additional_package_urls</key>
    <array>
        <string>http://192.168.100.7/netboot/first-boot.pkg</string>
    </array>
</dict>

The only downside is that it takes one extra reboot after install to start the first-boot process.

first-boot.zip

[grahamgilbert]

Okay, I’d take a PR to this effect.

…

On Nov 20, 2018 at 14:51, <Linux From Scratch on the Raspberry Pi ***@***.***)> wrote: Bit of an update: I've verified that /Library/{LaunchAgents, LaunchDaemons, PrivilegedHelperTools} gets written to the target volume correctly before startosinstall. I assume the Mojave installer sees anything in these directories as "Previous Content" and moves them out of the way as part of the install process. I've made a workaround by taking everything that is supposed to go in /Library and putting it in a pkg (attached). Then I let the OSX installer add it as an extra package like so: <dict> <key>type</key> <string>startosinstall</string> <key>url</key> <string>http://192.168.100.7/netboot/osx-10.14.1.dmg</string> <key>additional_package_urls</key> <array> <string>http://192.168.100.7/netboot/first-boot.pkg</string> </array> </dict> The only downside is that it takes one extra reboot after install to start the first-boot process. first-boot.zip (https://github.com/grahamgilbert/imagr/files/2601886/first-boot.zip) — You are receiving this because you commented. Reply to this email directly, view it on GitHub (#219 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABJwr2l7NbPxfRNbTz_hKK9swOKk5XuPks5uxIeEgaJpZM4X1sUp).

[chrisgrande]

I currently have a branch that I'm working on that has this built in, caveat being that it's based off Greg's embedded python fork - however the included changes should be able to be back ported into the none embedded branch if someone is interested.

Currently implemented:

• Builds first-boot tools pkg at app build time and copies into the bundle
• Appends the first-boot tools to the end of a 10.14 or later macOS install(*)
• PKG install then loads the launch agents and kicks off the first-boot tools script(**)

Currently not finished or working:
(*) Currently there is no detection of the OS version being installed in the workflow, it is being hard set to 10.14 for testing purposes
(**) While the first-boot script runs correctly, LoginLog will not open after the OS installer finishes - still working on why. I assume some combination of being the transient user space between the installer and the loginwindow and the OS not wanting the launch anything with a GUI.

https://github.com/chrisgrande/imagr/tree/first-boot-pkg

[teejo75]

I seem to be having a similar issue with 10.13.6, however there is no Previous Contents folder. All packages and scripts end up correctly in the Target Volume .imagr folder, but nothing in the LoadAgents or LoadDemons or PrivilegedHelperTools.

[grahamgilbert]

Then that sounds like a different issue. More information would be required, but I have to admit that the last time I used imagr was around 10.13.4. If it is broken on both 10.14 and 10.13 now I may just archive the project as there are better ways of deploying macOS these days.

[teejo75]

I'm certainly open to suggestions. I was looking for something to replace deploystudio, and I thought imagr was it. If there are better ways I'm all ears.

[grahamgilbert]

DEP is what I, and apple would recommend. You could also use Greg Neagle’s Installr or Bootstrappr