You are not logged in.

Announcement

[2017.09.08] DeployStudio build v1.7.8 (checksum, release note).
[2016.08.26] DeployStudio build v1.6.19 (release note).
[2013.02.23] DeployStudio last universal build v1.5.17 (release note).

#1 2016-08-12 14:39:50

MichalM.Mac
Member
Registered: 2014-07-27

First boot scripts not launched in order

We use latest DeployStudio 1.7.4.3 from USB drive to deploy our computers.
I discovered that some first boot scripts launched in finalize phase are sometimes not executed in order ds_0001.sh ds_0002.sh ds_0003.sh etc.

This led to launching munkienroll script before munkisetup which led to troubleshooting discovering this.
Is this expected behaviour or bug?

Look. ds_0002.sh ds_0001.sh ds_0004.sh

Install successful, removing script and related packages...
ds_finalize.sh - running /etc/deploystudio/bin/ds_0002.sh
ds_finalize.sh - running /etc/deploystudio/bin/ds_0001.sh
ds_finalize.sh - running /etc/deploystudio/bin/ds_0004.sh
/Users/matus
ByHost does not exist in /Users/matus/Library/Preferences/ByHost
/System/Library/User Template/Non_localized
ByHost does not exist in /System/Library/User Template/Non_localized/Library/Preferences/ByHost
/System/Library/User Template/English.lproj
ByHost does not exist in /System/Library/User Template/English.lproj/Library/Preferences/ByHost
/System/Library/User Template/cs.lproj
ByHost does not exist in /System/Library/User Template/cs.lproj/Library/Preferences/ByHost
ds_finalize.sh - running /etc/deploystudio/bin/ds_0003.sh
ds_finalize.sh - running /etc/deploystudio/bin/ds_0006.sh
2016-08-12 03:57:11.382 defaults[755:6294]
The domain/default pair of (/Library/Preferences/ManagedInstalls, ClientIdentifier) does not exist
[Munkienroll] trying for 1 time
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100    46  100    46    0     0     60      0 --:--:-- --:--:-- --:--:--    60
Computer manifest does not exist. Will create.
[Munkienroll] Success
[Munkienroll] Setting: /clients/matus.calkovsky
ds_finalize.sh - running /etc/deploystudio/bin/ds_0005.sh
Set TimeZone: Europe/Prague
Network Time is already on.
2016-08-12 12:57:12.364 systemsetup[772:6340] **** -[ADMNetworkTimeClient _ntpSetEnabled:] /etc/ntp.conf doesn't exist. You need to create it first before ntpd can start sucesfully
setNetworkTimeServer: time.euro.apple.com.
Automatic check is off
ds_finalize.sh - Disabling iCloud and gestures preference panes auto-launch at first login.
ds_finalize.sh - reboot required by packages installation, system will automatically reboot in s.
ds_finalize.sh - end

Last edited by MichalM.Mac (2016-08-12 14:42:16)

Offline

#2 2016-08-12 14:51:40

admin
Administrator
Registered: 2007-03-29
Website

Re: First boot scripts not launched in order

The finalize script should respect the file creation/modification date.

Offline

#3 2016-08-12 16:41:01

MichalM.Mac
Member
Registered: 2014-07-27

Re: First boot scripts not launched in order

> admin wrote:

> The finalize script should respect the file creation/modification date.

What do you mean?

timestamp on original script files in /DeployStudio_REPO/Scripts or on copied ds_000X.sh files?

Offline

#4 2016-08-13 06:19:36

admin
Administrator
Registered: 2007-03-29
Website

Re: First boot scripts not launched in order

Check the *_XXX.sh files creation/modification date before rebooting.

Offline

#5 2016-09-15 02:36:32

jfilice
Member
From: Seaside, Ca
Registered: 2012-04-19
Website

Re: First boot scripts not launched in order

DeployStudio admin:

I am having troubles with this as well on 2015 iMacs with SSD disks.

I thought you changed the finalize script back in 2012 (around 1.0rc135) so it would no longer rely on script timestamps to set execution order. With networks, CPUs, and disks being so fast today, it does not surprise me that multiple scripts are being written in /etc/deploystudio/bin/ with nearly the exact same timestamp (within milliseconds). We need ds_finalize.sh to execute REMAINING_DS_SCRIPTS in sequential order by ds_000X.sh index--otherwise, why even have them? They should govern the order in which scripts are executed, without regard to the timestamps on the files in /etc/deploystudio/bin/.

Offline

#6 2017-01-17 22:00:53

n8felton
Member
Registered: 2011-08-04

Re: First boot scripts not launched in order

Hello! This "bug" bit me today. I noticed this was mentioned in another post at http://www.deploystudio.com/Forums/viewtopic.php?pid=18918#p18918. I'm assuming this was not actually fixed/changed? I have always been under the impression (much like jfilice above) that the purpose of the scripts being copied as "ds_0001", "ds_0002", "ds_nnnn" was so that they were executed in the order that we set them in the workflows.

Can we get this fixed? For now I resorted to rearranging scripts and other workflow tasks so the the script that sets the needed settings runs early enough in the workflow to have an older modification date than the scripts that are reliant on those settings.

Offline

#7 2017-02-15 22:38:50

Oh4sh0
Member
Registered: 2016-09-29

Re: First boot scripts not launched in order

> n8felton wrote:

> Hello! This "bug" bit me today. I noticed this was mentioned in another post at http://www.deploystudio.com/Forums/viewtopic.php?pid=18918#p18918. I'm assuming this was not actually fixed/changed? I have always been under the impression (much like jfilice above) that the purpose of the scripts being copied as "ds_0001", "ds_0002", "ds_nnnn" was so that they were executed in the order that we set them in the workflows.

Can we get this fixed? For now I resorted to rearranging scripts and other workflow tasks so the the script that sets the needed settings runs early enough in the workflow to have an older modification date than the scripts that are reliant on those settings.

I'm seeing this too. After upgrading from 1.7.1->1.7.5 our last two scripts in our workflow, which execute on first boot, execute in reverse order from their workflow position. Tried creating a new workflow with the scripts, same results. Tried switching their order in the workflow, same results. Only solution that worked was to rename them, so that the one that should run second, is alphanumerically ordered after the first one.

Offline

#8 2017-02-17 02:09:53

nider
Member
Registered: 2016-01-11

Re: First boot scripts not launched in order

This bug had been biting me too, looked into it today and worked out it was due to the files having the same modification time (which under HFS+ is one second granularity), it will be solved naturally under APFS with it's nanosecond granularity, although there are questions about DeployStudio's ability to restore when the new filesystem drops.

Can we please get this fixed?

Edit:

I fixed it myself. It's easy to replicate this:
1. create a new folder
2. touch three files with the same command (touch ds_0001.sh ds_0002.sh ds_0003.sh)
3. Wait a sec
4. touch three more files with the same command (touch ds_0004.sh ds_0005.pl ds_0006.sh)
5. list the files in the same way the finalise script does (ls -tr ds_*.sh ds_*.pl)
6. Files with the same modification time are listed in reverse order

Edit2: The patch didn't work, actually. Working on it again.

Last edited by nider (2017-02-20 04:58:04)

Offline

#9 2017-02-20 11:38:53

nider
Member
Registered: 2016-01-11

Re: First boot scripts not launched in order

Okay, so I discovered today that my previous "quick fix" was woefully inadequate as I forgot my simple workflow also included some package installs which were out of order as a result of the change I made.

Therefore I've written a more complicated patch that corrects the order of any shell script tasks it finds in the list of remaining tasks. The rest of the tasks are still ordered as they come out of the ls -tr command, so there's a chance that there may still be some tasks that aren't in the correct order, however this at least addresses the common case where a number of shell scripts tasks would be run out of order. This patch was a pain to write given the idiosyncrasies and feature set of /bin/sh ugh.

Below you'll find the updated patch for anyone else's use.

https://www.dropbox.com/s/gyaqw9hu25c0kuf/script_order_fix.patch?dl=0

Offline

Board footer

Powered by FluxBB