Allow reboot delay

[Pueo2]

A feature which I think would add value to an already powerful script would be to have an argument allowing a HuD to appear on the current active screen alerting the user they have a certain time (in mins) before a reboot occurs. This display may or may not show a count down.

Describe the solution you'd like
Implementation of the argument --rebootdelay. I think this may be the argument from startosinstall
Implementation of a HuD showing a count down or the fixed mins of the countdown i.e 3 mins.

Steps:

• Fullscreen JamfHelper is showing the "Please wait as we prepare your computer for upgrading macOS" screen.

• Device prep is occurring in the back ground.

• When device is ready to reboot a HuD appears informing the User a reboot is happening in 3 mins.

The HuD appears only if added in the command line i.e /Library/Management/erase-install/erase-install.sh --os=12 --reinstall --rebootdelay 180 --current-user --confirm

• This HuD could also have a Now button or just leave it run the xx amount of time. The time in mins could be configured in the script as a variable (or not).

• User has time to save work or leave a call and then acknowledge the HuD or let the timer run out.

Describe alternatives you've considered
As suggested I have added in the --confirm argument to the command line. Also considered other ways of upgrading Mac but all of them behave so differently. Nudge was highly recommended. I recently discovered I can use the erase-install script with Nudge to minimize user interaction for a better End User experience.
Tried MDM commands from Jamf
Tried Jamf Policies

Additional context
Scenario
When a user clicks on the Nudge Upgrade button this launches a Self Service policy which runs the erase-install.sh script with arguments.
Although we have the --confirmationargument activated. This alerts the user prior to the macOS upgrade prep screen launching. These days most users have 2 - 3 screens and will navigate away from the JamfHelper (or other) screen. Some will take a Teams/Zoom call or start working on a document.
While on a call, their Mac will reboot. The user may be in an important call or meeting.
During Sprints having your device down for 30-40mins is quite a long time. If a end user can work for 30 of these minutes while the device is prepping in the long wrong this will save user frustration, time and money and a over all better experience.
/--
No matter how much education or warnings we inform end users (via emails), users will continue to work and some will get caught out.
I've already had our CTO get caught with a forced reboot and update during his executive meeting. Emails and communication was provided prior.
Every company culture is different. Some companies may say "this will happen" and that's the end of it, mine is not like that.

[grahampugh]

I agree that there is value in adding the --rebootdelay option. I just have to check which OSs it works with.

Additionally, for Big Sur and up, there is an argument that we shouldn't need to block the screen during the preparation phase, because this is now a background task where a snapshot is being made, and people could/should be able to continue working. I'm going to consider an option to suppress the dialog during that stage, if --rebootdelay works.

[Pueo2]

Hello Graham Thanks for looking into my feature request. If I was a pro at scripting I’d help out. I am still learning. I tend to agree with the argument about not blocking the screen. It may be better to not have the display which allows people to work (windows is like that). Most users would prefer. It reduces the upgrade time which is always a good thing. However this is when the reboot delay would be a great enhancement. We would use the confirmation argument then rebootdelay at the end. If the HUD can appear on the active screen so users can see it, This would prevent users complaining they never saw a warning before the reboot. We both know this would happen. Lol. Really appreciate the email. Thank you for your contribution to Mac Admin world. Cheers, Ashley Paul James

…

On Jan 30, 2022, at 06:51, Graham Pugh ***@***.***> wrote:  I agree that there is value in adding the --rebootdelay option. I just have to check which OSs it works with. Additionally, for Big Sur and up, there is an argument that we shouldn't need to block the screen during the preparation phase, because this is now a background task where a snapshot is being made, and people could/should be able to continue working. I'm going to consider an option to suppress the dialog during that stage, if --rebootdelay works. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[grahampugh]

I added the --rebootdelay option. It's not so easy to test, as you really have to go through an upgrade.

I just tried it once and I'm not sure if it works. I didn't see any output that a delay was set or was being observed. There's nothing in the logs, and I don't think the delay was honoured at all.

I would welcome any tests. Try the v26.0 pre-release I just uploaded.

It would only be useful if there is some obvious output somewhere that can be monitored for so that a DEPNotify window could be popped up or whatever.

[Pueo2]

Thank you for adding --rebootdelay. I was not expecting a quick turnaround. I went through a full upgrade using a VM. Took awhile but got the result I needed to see. I have a short screen video of the countdown. If you want to see the video let me know. Happy to share it.
Did you make changes after you sent your reply? I was looking at the release page and script. Notice there were entries to have DEP display the countdown. It works!

For my testing I used DEPNotify and the arguments --no-fs --rebootdelay 60 (plus other arguments).
As you said you have to run an upgrade to see this working. I upgraded from 11.5.2 to 12.2 on a VM.

[grahampugh]

Hi, yes I did make more changes after posting here, after some help from other Mac admins on how --rebootdelay interacts with --pidtosignal.

I still need to get localisation strings for the countdown window, fine tune what happens at the end of the countdown, provide output for people who don't use DEPNotify, and decide on whether to have a mode without windows at the download and preparation stage for those that use the --rebootdelay option. At the moment I've tried to add an OK button which dismisses those windows, but I haven't tried it to see if it works yet.