startosinstall fails to install with PerformAuthRestarts and BridgeOS shutdown requirement

290 views
Skip to first unread message

Kyle Crawford

unread,
Feb 11, 2020, 7:06:32 PM2/11/20
to munki-dev
When doing a startosinstall-style upgrade using munki, T2 devices download iBridge OS updates during the prepare phase of the install to meet the BridgeOS version requirement for the upgrade.

These can be seen in /var/log/install.log.

2020-02-05 15:50:33-05 mac osinstallersetupd[55201]: Started downloading package com.apple.pkg.BridgeOSUpdateCustomer (http://swcdn.apple.com/content/downloads/13/03/061-62855-A_I1OL4KN694/q73ftsncfsp5s3ev58sl2u7chcyfep1wca/BridgeOSUpdateCustomer.pkg)



This happens as part of startosinstall, not a normal softwareupdate run.  And I think any configured CatalogURL is ignored.

The issue is that iBridge updates usually require a shutdown.

It after a BridgeOS update, the device is not shut down, but is instead restarted, the BridgeOS update will fail and thereby the OS upgrade will also fail.

munki has support for detecting the need for a shutdown when it is using softwareupdate, but not currently in startosinstall-based installs.

Currently with startosinstall, if munki has PerformAuthRestarts enabled, it will only every try to do a restart.

If PerformAuthRestarts is not enabled, I think munki allows startosinstall to handle the shutdown/restart and it does the right thing.

I'm not sure what can be done to improve this or whether PerformAuthRestarts still adds value.

There is no authshutdown option to fdesetup that I am aware of.

And I am not sure whether it is possible to detect the need for a shutdown during a startosinstall-based run.

If anyone else would like to confirm this behavior it might at least warrant a warning in the munki authrestarts wiki page and perhaps feedback to Apple.

Kyle

Gregory Neagle

unread,
Feb 11, 2020, 7:32:40 PM2/11/20
to 'Gregory Neagle' via munki-dev
To my knowledge you are correct that there's no way to do an "Authorized Shutdown" with tools available to us.

I don't know if it's possible to detect the need to shutdown instead of restart during a `startosinstall` run.

And the one-way nature of BridgeOS updates makes testing/investigation really difficult.

I don't currently have a T2 Mac with not-up-to-date BridgeOS firmware to test this with. :-(

The approaches I can think of to possibly deal with this have some repercussions:

1) Don't ever try to do an authrestart and just let `startosinstall` do the needed shutdown or restart. For upgrades that require only a restart, this approach might lead to failed upgrades if the user is not around to unlock the startup disk after the initial reboot. It's unclear (to me) how a shutdown doesn't suffer from the same issue after the BridgeOS update is completed.

2) Attempt to detect the need for a shutdown and if the need is detected, either do a shutdown instead of restart, or again, leave the task to `startosinstall`. This is more complex and relies on accurately detecting the need for a shutdown (and whatever we use to determine this might change in future macOS releases) -- it might be fragile/unreliable.

I've been using Munki to do macOS upgrades since Mac OS X Lion (and radmind to to macOS upgrades before that!). It would be sad if the T2 ultimately breaks this and we once again have to manually babysit Macs or make all our Mac users admins and bug them to upgrade manually.

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/8343096b-2731-4ab7-ac95-31f19ed83d27%40googlegroups.com.

Kyle Crawford

unread,
Feb 11, 2020, 10:56:55 PM2/11/20
to munk...@googlegroups.com
Yes reproducing BridgeOS update issues has been a real challenge for us without the ability to revert.

I’ll ask Apple about detecting the shutdown requirement.

In the meantime we might disable PerformAuthRestarts to see if that helps more than it harms.

Kyle

Sent from Mobile

On Feb 11, 2020, at 7:32 PM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

To my knowledge you are correct that there's no way to do an "Authorized Shutdown" with tools available to us.

Graham Pugh

unread,
Feb 12, 2020, 1:31:55 AM2/12/20
to munk...@googlegroups.com
Startosinstall operations without PerformAuthRestarts shouldn’t cause failed upgrades when the user is absent. Rather, the upgrade may not complete until they return. Worst case scenario is the user has to wait for the upgrade to complete when they return to the computer. I think that’s better than a failed upgrade. A warning message (which Apple provide when you do an upgrade using native GUI) should be sufficient. 

Cheers,
Graham
 

Von meinem iPhone gesendet

Am 12.02.2020 um 04:56 schrieb Kyle Crawford <kcr...@gmail.com>:

PerformAuthRestarts

Gregory Neagle

unread,
Feb 12, 2020, 2:14:31 AM2/12/20
to munk...@googlegroups.com

On Feb 11, 2020, at 10:31 PM, Graham Pugh <g.r....@gmail.com> wrote:

Startosinstall operations without PerformAuthRestarts shouldn’t cause failed upgrades when the user is absent. Rather, the upgrade may not complete until they return. Worst case scenario is the user has to wait for the upgrade to complete when they return to the computer.

I'm not 100% convinced that's what will happen.

At least up through 10.12, the macOS install setup process recorded a timedate stamp ("IAEndDate"). If the actual install began "too long" after that date, it failed.

I think it's just as likely that what will happen if the user does not unlock the startup disk on the initial reboot after the macOS install is set up is that the machine will shut down. If it is then "too long" when the machine is started up again, the macOS install will be aborted altogther and the machine will startup in the (old/previous) OS.

That's just as much a "failed upgrade" as is the scenario Kyle describes. In no case are we left with an unbootable machine -- it's just that the attempt to upgrade to the new OS fails, and we remain in the old OS.

I think that’s better than a failed upgrade. A warning message (which Apple provide when you do an upgrade using native GUI) should be sufficient. 

Cheers,
Graham
 

Von meinem iPhone gesendet

Am 12.02.2020 um 04:56 schrieb Kyle Crawford <kcr...@gmail.com>:

PerformAuthRestarts

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

Graham Pugh

unread,
Feb 12, 2020, 2:37:46 AM2/12/20
to munk...@googlegroups.com
Ok fair enough. By “failed” I assumed that rather than “aborted”, you meant ending up in the state that sometimes happens where a bridgeOS problem means that it boots to recovery and online remediation is necessary - a support-ticket-generating situation if ever there was one.

Von meinem iPhone gesendet

Am 12.02.2020 um 08:14 schrieb 'Gregory Neagle' via munki-dev <munk...@googlegroups.com>:



Gregory Neagle

unread,
Feb 12, 2020, 5:11:07 PM2/12/20
to munk...@googlegroups.com
I have not yet tried to replicate this issue here (since I don't yet have access to an appropriate machine in the right state), but I have contacted several people here who used Munki to update their MacBookPro15,1 machines from Mojave to Catalina. They did not observe issues consistent with the problem Kyle describes. Perhaps there is another triggering facter involved, or perhaps for some reason BridgeOS did not need to be updated on these machines (maybe the machine can have an upgraded BridgeOS even while on Mojave -- installed maybe as part of a Mojave Security Update).

Has anyone else seen/replicated this issue?

-Greg

On Feb 11, 2020, at 4:06 PM, Kyle Crawford <kcr...@gmail.com> wrote:

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

Miq Viq

unread,
Feb 12, 2020, 5:16:19 PM2/12/20
to munk...@googlegroups.com
I had similar issues with latest 16" MBPros.

For those machines (7 units) I decided to use standard Apple SWUPD catalog.
And I upgraded to 10.15.3 "manually" using softwareupdate -ia; halt

-MiqViq

Gregory Neagle

unread,
Feb 12, 2020, 5:27:32 PM2/12/20
to munk...@googlegroups.com
The 16" MacBook Pros ship with Catalina and will not run Mojave, so whatever issue you are seeing --  it can't be failed `startosinstall`-style upgrades from Mojave to Catalina.

You are seeing some _other_ issue.

-Greg

Gregory Neagle

unread,
Feb 12, 2020, 5:27:52 PM2/12/20
to 'Gregory Neagle' via munki-dev
The 16" MacBook Pros ship with Catalina and will not run Mojave, so whatever issue you are seeing --  it can't be failed `startosinstall`-style upgrades from Mojave to Catalina.

You are seeing some _other_ issue.

-Greg

On Feb 12, 2020, at 2:16 PM, Miq Viq <miq...@gmail.com> wrote:

Gregory Neagle

unread,
Feb 12, 2020, 5:57:19 PM2/12/20
to munk...@googlegroups.com
Kyle:

When this issue occurs, does the Mac boot into Boot Recovery Assistant?

If so, I think I have reproduced the issue...

-Greg

Graham Pugh

unread,
Feb 12, 2020, 7:33:40 PM2/12/20
to munk...@googlegroups.com
FWIW, `softwareupdate -iaR` is supposed to correctly handle restarts or halts as required:

-R | --restart Automatically restart (or shut down) if required to complete installation.

Cheers,
Graham

Gregory Neagle

unread,
Feb 12, 2020, 7:39:57 PM2/12/20
to 'Gregory Neagle' via munki-dev
Yes, but that's of no help for `startosinstall` installs.

-Greg

Mike Solin

unread,
Feb 12, 2020, 9:51:47 PM2/12/20
to munk...@googlegroups.com
I have a 2019 15-inch MacBook Pro, and upgraded to 10.15.3 a couple of weeks ago. I installed the 10.14.6 security update on January 29th, then upgraded to 10.15.3 on January 30th. I used the latest version of munkitools, 4.0.1. My Mac has FileVault enabled, as well as PerformAuthRestarts, and I gave it authorization when proceeding with the OS upgrade. I did not observe anything out of the ordinary - my Mac upgraded to 10.15.3 successfully on the first attempt.

It's entirely possible that the BridgeOS update installed as part of the 10.14.6 security update and another BridgeOS update was not necessary when upgrading the OS from 10.14.6 to 10.15.3.



To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/98AAED58-EF3A-404D-9AC8-CEC84E332CE4%40mac.com.

Kyle Crawford

unread,
Feb 12, 2020, 11:39:35 PM2/12/20
to munk...@googlegroups.com
Yes it does boot to Boot Recovery Assistant at least in some cases.

If you shut down from there, BridgeOS might actually update because it is just wanting a shutdown.  So don’t if you want to keep reproducing the issue.

Also, yes security updates usually also update BridgeOS and startosinstall won’t need to update it and shutdown if it already meets minimum version requirement.

I have a case open with AppleCare.  So far they have pointed me to MDM command for ScheduleOSUpdate etc.  I clarified and they are going look into it.

Kyle

Sent from Mobile

On Feb 12, 2020, at 5:57 PM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

Kyle:

Per Olofsson

unread,
Feb 13, 2020, 3:36:18 AM2/13/20
to munk...@googlegroups.com
12 feb. 2020 kl. 23:11 skrev 'Gregory Neagle' via munki-dev <munk...@googlegroups.com>:
>
> Has anyone else seen/replicated this issue?

Anecdotally, yes. I've had a couple of reports of hung OS upgrades that match Kyle's description. I've only been consulted after the fact though so I haven't had a chance to replicate it. Just like the rest of us, I don't have a stack of T2s, and my personal machines have upgraded without issue.

--
Per Olofsson, IT-service, University of Gothenburg

Joaquin Cabrerizo Egea

unread,
Feb 13, 2020, 8:20:09 AM2/13/20
to munk...@googlegroups.com

> El 12 feb 2020, a las 23:11, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> escribió:
>
> Has anyone else seen/replicated this issue?

I had several users with this issue updating Mojave’s latest sec update. I could test with my own test Mac this behavior and I found the same about BridgeOS but I didn’t know it was related with the necessary shutdown.

Kyle Crawford

unread,
Feb 13, 2020, 4:48:56 PM2/13/20
to munk...@googlegroups.com
I saw this today with softwareupdate to 10.15.4 beta. Munki did not detect the need for shutdown. So a separate issue may also exist for softwareupdate handling.

I don’t think it tried an authrestart even though it was enabled. I was not prompted by MSC.

It booted to Recovery Assistant and I shutdown. It then booted back up and asked for FDE credentials. I shutdown rather than enter FDE creds to see if update would still proceed after another shutdown. I started back up and entered credentials and the OS update proceeded to install.

Apple’s answer so far for determining shutdown requirement is to check for a BridgeOS package in /Library/Updates/*/

Kyle

Sent from Mobile

> On Feb 13, 2020, at 8:20 AM, Joaquin Cabrerizo Egea <lct...@gmail.com> wrote:
>
> 
>> El 12 feb 2020, a las 23:11, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> escribió:
>>
>> Has anyone else seen/replicated this issue?
>
> I had several users with this issue updating Mojave’s latest sec update. I could test with my own test Mac this behavior and I found the same about BridgeOS but I didn’t know it was related with the necessary shutdown.
>
> --
> Find related discussion groups here:
> https://github.com/munki/munki/wiki/Discussion-Group
> ---
> You received this message because you are subscribed to the Google Groups "munki-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/49DCD913-36DF-42EA-BE92-97D14A80B1C0%40gmail.com.

Gregory Neagle

unread,
Feb 13, 2020, 5:45:16 PM2/13/20
to 'Gregory Neagle' via munki-dev
The Munki4dev branch (https://github.com/munki/munki/tree/Munki4dev) now contains code with a different strategy for running `startosinstall` when FileVault is active and when PerformAuthRestarts is set.

This new code takes advantage of an `fdesetup authrestart` option that did not exist when I first wrote this code.

The new code no longer attempts to "trick" `startosinstall` to quit instead of restart when FileVault is active, PerformAuthRestarts is set, and we're currently running 10.12 or later. Previously (and still under 10.11 and earlier) it does so that it can do an authrestart after `startosinstal`l completes.

The new code instead calls `fdesetup authrestart -delayminutes -1`, which sets things up such that the next restart becomes an auth restart. We allow `startosinstall` to handle the restart (or shutdown) itself. Presumably `startosinstall` will do the proper thing (shutting down if needed, restarting if not), and Munki doesn't have to know or care.

Please test if you can. I've done some basic testing and successfully kicked off a Mojave-to-Catalina upgrade on a machine with FV enabled (sadly not one that needed a BridgeOS update, since I don't have access to one).

I think the code that runs `/usr/sbin/softwareupdate` may need to be updated to use a similar strategy: if on 10.14 or later, and the Apple updates to be installed require a "restart", set up a delayed auth restart if applicable, then call `softwareupdate` with the `-R` flag so that `softwareupdate` handles the need to restart or shutdown. Previously Munki was examining the plain text output from `softwareupdate` and looking for certain terms that indicated the need for a shutdown instead of a restart, but it seems clear that the output has changed, and Munki is not seeing the warning to shutdown instead of restart. Taking the responsibility from Munki and handing it to `softwareupdate` seems the right approach.

One caveat: for some time after the `-R` functionality was added to `softwareupdate`, it failed to shutdown or restart if no-one was logged in, because it was calling the wrong APIs. Can anyone confirm that has been fixed, and if so, which macOS version it was fixed in?

-Greg

Kyle Crawford

unread,
Feb 13, 2020, 6:48:38 PM2/13/20
to munk...@googlegroups.com
That’s great!  I’ll see if I have any devices with older BridgeOS to test.

Kyle

Sent from Mobile

On Feb 13, 2020, at 5:45 PM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

The Munki4dev branch (https://github.com/munki/munki/tree/Munki4dev) now contains code with a different strategy for running `startosinstall` when FileVault is active and when PerformAuthRestarts is set.

Gregory Neagle

unread,
Feb 16, 2020, 1:39:14 AM2/16/20
to 'Gregory Neagle' via munki-dev
A test on a 10.14 VM seems to indicate this functionality is broken at the loginwindow for that release, at least. :-(

Gregory Neagle

unread,
Feb 16, 2020, 12:20:13 PM2/16/20
to munk...@googlegroups.com
I manually updated the VM to 10.14.1, then tried the 10.14.6 upgrade again. Terrible results; softwareupdate just never is done updating and never exits:



--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

Gregory Neagle

unread,
Feb 16, 2020, 12:59:19 PM2/16/20
to munk...@googlegroups.com
Reset the VM to an earlier snapshot and tried again; this time `softwareupdate` did not hang indefinitely, but the 10.14.6 update wasn't successful -- once again, `softwareupdate` output "Restarting to complete installation of selected updates." but failed to actually do so.

So in my tests with 10.14 and 10.14.1, I'm not seeing `softwareupdate -i --restart` do the right thing when at the loginwindow.

On to 10.14.2...

-Greg

On Feb 16, 2020, at 9:20 AM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

I manually updated the VM to 10.14.1, then tried the 10.14.6 upgrade again. Terrible results; softwareupdate just never is done updating and never exits:

<PastedGraphic-1.png>

Gregory Neagle

unread,
Feb 16, 2020, 2:46:51 PM2/16/20
to munk...@googlegroups.com
Same behavior in 10.14.2. :-(

Gregory Neagle

unread,
Feb 16, 2020, 4:57:57 PM2/16/20
to munk...@googlegroups.com
No difference in 10.14.3...

Gregory Neagle

unread,
Feb 17, 2020, 1:45:41 PM2/17/20
to 'Gregory Neagle' via munki-dev
Behavior unchanged in 10.14.4.

Gregory Neagle

unread,
Feb 17, 2020, 3:24:10 PM2/17/20
to munk...@googlegroups.com
And the same in 10.14.5.

So in 10.14-10.14.5, even when Munki calls `softwareupdate --install` with the `--restart` option, `softwareupdate` _fails_ to restart (or shutdown) the machine. Munki of course attempts this install while at the loginwindow.

It seems that `softwareupdate` is fundamentally broken for the reliable automation of macOS updates on T2-based Macs in 10.13.x and 10.14.x at least.

I'm going to continue to do some more testing and experimentation, but my current inclination is to start working toward Munki no longer attempting macOS updates, and rather, opening the Software Update preferences pane and encouraging users to do these updates themselves via Apple's GUI tools.

File issues with Apple if find this situation unacceptable.

-Greg

Gregory Neagle

unread,
Feb 17, 2020, 3:34:03 PM2/17/20
to munk...@googlegroups.com
Next experiment: I turned on SSH and sshed into a 10.14.5 VM sitting at the loginwindow. `sudo softwareupdate -iaR` did download, set up the install and reboot the VM to kick off the real OS update.


Gregory Neagle

unread,
Feb 17, 2020, 3:56:36 PM2/17/20
to munk...@googlegroups.com
Next experiment. To more closely mimic how Munki runs softwareupdate at the loginwindow, I created a simple launchd LaunchDaemon definition:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>test.greg.softwareupdate</string>
<key>OnDemand</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/softwareupdate</string>
<string>--install</string>
<string>--all</string>
<string>--restart</string>
</array>
    <key>StandardOutPath</key>
    <string>/private/tmp/test.greg.softwareupdate.log</string>
</dict>
</plist>

I sshed into a 10.14.5 VM that was at loginwindow, created, loaded, and started the the launchd job:

bash-3.2# launchctl load /Library/LaunchDaemons/test.greg.softwareupdate.plist 
bash-3.2# launchctl start test.greg.softwareupdate
bash-3.2# tail -f /tmp/test.greg.softwareupdate.log 
Software Update Tool

Finding available software

Downloaded macOS 10.14.6 Update
Installing macOS 10.14.6 Update
Done.

You have installed one or more updates that requires that you restart your computer.

Restarting to complete installation of selected updates.

And the machine was _not_ restarted.

So the restart/shutdown functionality works in specific circumstances, but quite clearly fails in others. Since Munki is ultimately a launchd job, (a LaunchDaemon in this context, it seems this approach is doomed with Apple's tools).

I have not yet tested with any of the 10.15.x series (I don't have any handy VMs right now), but I suspect the issue is the same, and there is no truly reliable way to use softwareupdate to install macOS updates on T2 machines.

-Greg


Joaquin Cabrerizo Egea

unread,
Feb 17, 2020, 4:18:23 PM2/17/20
to munk...@googlegroups.com
Greg you did a very good job as always testing this behavior. After my tests (not as good as yours) I ended up with the same thought, softwareupdate is broken, not Munki fault, and we need to point users to Apple GUI. I will file an issue with Apple as well but I will as well start testing Nudge by Erik Gomez ASAP.

Enviado desde mi iPhone

El 17 feb 2020, a las 21:56, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> escribió:

Next experiment. To more closely mimic how Munki runs softwareupdate at the loginwindow, I created a simple launchd LaunchDaemon definition:

Kyle Crawford

unread,
Feb 17, 2020, 8:32:56 PM2/17/20
to munk...@googlegroups.com
Can we escape the launchd context using launchctl asuser to run softwareupdate or does it want a tty?

Kyle

Sent from Mobile

On Feb 17, 2020, at 4:18 PM, Joaquin Cabrerizo Egea <lct...@gmail.com> wrote:

Greg you did a very good job as always testing this behavior. After my tests (not as good as yours) I ended up with the same thought, softwareupdate is broken, not Munki fault, and we need to point users to Apple GUI. I will file an issue with Apple as well but I will as well start testing Nudge by Erik Gomez ASAP.

Gregory Neagle

unread,
Feb 18, 2020, 10:12:10 AM2/18/20
to munk...@googlegroups.com
I look forward to your findings!

-Greg

Message has been deleted
Message has been deleted

Gregory Neagle

unread,
Feb 18, 2020, 10:40:28 AM2/18/20
to munk...@googlegroups.com

On Feb 18, 2020, at 7:38 AM, Michal Moravec <micha...@gmail.com> wrote:

Test case:

- VM with 10.15.2. 
- No GUI user is logged in
- SSH into the Mac as local admin

Test A. 
  1. `sudo /usr/sbin/softwareupdate --install --all --restart` 
Works. macOS is rebooted

Yes, I also did that and saw the same results. But Munki doesn't work by SSHing into Macs and running commands...

On Feb 17, 2020, at 12:33 PM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

Next experiment: I turned on SSH and sshed into a 10.14.5 VM sitting at the loginwindow. `sudo softwareupdate -iaR` did download, set up the install and reboot the VM to kick off the real OS update.

Test B. 
    1. `sudo su -`

-Greg

-Greg

Behavior unchanged in 10.14.4.

No difference in 10.14.3...

-Greg

<PastedGraphic-1.png>

To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.
--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

Michal Moravec

unread,
Feb 18, 2020, 10:40:53 AM2/18/20
to munki-dev
Sorry. I hit some sort of shorcut.

Test setup:

- VM with 10.15.2. 
- No GUI user is logged in
- SSH into the Mac as local admin

Test A. 
    1. `sudo /usr/sbin/softwareupdate --install --all --restart` 
    2. Works. macOS is rebooted
Test B. 
    1. `sudo su -`
    2. /usr/sbin/softwareupdate --install --all --restart` 
    3. Does not work. macOS is NOT rebooted.

On Tuesday, February 18, 2020 at 4:12:10 PM UTC+1, gregn...@mac.com wrote:
-Greg

-Greg

Behavior unchanged in 10.14.4.

No difference in 10.14.3...

-Greg

<PastedGraphic-1.png>

To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

Michal Moravec

unread,
Feb 18, 2020, 12:11:39 PM2/18/20
to munki-dev
I also replicated the problem with LaunchDaemon as Greg did with 10.14.5 -> 10.14.6.
Filled radar... ehm feedback FB7587210 -> http://www.openradar.me/radar?id=5041147722334208

Looks like Catalina is also no go for --restart switch at the moment.

M

Gregory Neagle

unread,
Feb 18, 2020, 2:48:30 PM2/18/20
to munk...@googlegroups.com
The softwareupdate issues aside; I think the code in the Munki4dev branch is successfully running startosinstall with authorized restarts and letting startosinstall handle the restart (or shutdown). Would like other people testing this. The most _interesting_ test would be on a T2-based machine that needs a BridgeOS update for the macOS upgrade, but testing of other upgrade scenarios would be helpful as well.

-Greg

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/7d5aa811-6f67-4943-85d6-e1d042cf698f%40googlegroups.com.

Kyle Crawford

unread,
Feb 19, 2020, 1:02:18 AM2/19/20
to munki-dev
Regarding softwareupdate --restart, I have also reproduced and was unable to get it to restart without a user logged in.  I tried various hacks and those did not work. 

The existing munki code to figure out the RestartAction is by parsing the dist files for onConclusion attribute correct?  Does munki check dependent BridgeOS dist entries or only the user-visible items directly listed in softwareupdate -l?

I'll check for outdated BridgeOS devices to test with tomorrow.

Kyle
-Greg

Kyle Crawford

unread,
Feb 19, 2020, 1:16:49 PM2/19/20
to munk...@googlegroups.com

Tested an upgrade from Mojave to Catalina 10.15.3 using just built Munki4dev 3923 on T2 that needs BridgeOS update with PerformAuthRestarts on.

Unfortunately it restarted rather than shutdown and landed in Boot Recovery Assistant.

Kyle

Sent from Mobile

On Feb 19, 2020, at 1:02 AM, Kyle Crawford <kcr...@gmail.com> wrote:


To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/059d02f3-df4f-4941-bd50-05ce9e6883dc%40googlegroups.com.

Gregory Neagle

unread,
Feb 19, 2020, 1:20:09 PM2/19/20
to munk...@googlegroups.com
Did you preserve (or can you get now) the relevant parts of ManagedSoftwareUpdate.log and install.log?

-Greg

Gregory Neagle

unread,
Feb 19, 2020, 1:25:38 PM2/19/20
to 'Gregory Neagle' via munki-dev
I am seeing on my only testing T2 machine, that some of the time `startosinstall` fails to restart _or_ shut down, and instead it just exits. In that case, Munki has no way to know a shut down is required, and just does an (auth)restart.

This seems to be a bug in startosinstall. Out of five upgrade attempts yesterday (10.14.6 to 10.15.3), I saw this (undesired) behavior twice. Testing continues today.

If you (or others) continue to test, be sure to grab the latest code from the Munki4dev branch (`./code/tools/make_munki_mpkg_from_git.sh -b Munki4dev` is your friend here)

-Greg

Kyle Crawford

unread,
Feb 19, 2020, 3:49:44 PM2/19/20
to munki-dev
I think I tried 4 times.  3 failed by rebooting to Boot Recovery Assistant.  1 failed to prompt for FileVault password in Managed Software Center so I cancelled it to preserve my BridgeOS.

No successes so far.

I will send logs to your email.
-Greg

-Greg


To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/5C127626-18FD-4E34-99DC-7A4F15C46D81%40mac.com.

Kyle Crawford

unread,
Feb 19, 2020, 6:58:59 PM2/19/20
to munk...@googlegroups.com
It also failed with performAuthRestarts  off so I don’t know. I guess I need to do more testing.

Is there a way we could run these before the log out?

Kyle

Sent from Mobile

On Feb 19, 2020, at 3:49 PM, Kyle Crawford <kcr...@gmail.com> wrote:


To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/13cb4e9c-d0bb-4122-8cf5-d5c5f5fb5fbc%40googlegroups.com.

Gregory Neagle

unread,
Feb 19, 2020, 6:59:36 PM2/19/20
to munk...@googlegroups.com

On Feb 19, 2020, at 3:58 PM, Kyle Crawford <kcr...@gmail.com> wrote:

It also failed with performAuthRestarts  off so I don’t know. I guess I need to do more testing.

Is there a way we could run these before the log out?

Run _what_?

Kyle Crawford

unread,
Feb 19, 2020, 7:35:30 PM2/19/20
to munk...@googlegroups.com
The idea being if we determine that startosinstall and softwareupdate -R do the right thing with a user logged in, could munki treat them as not requiring a logout.

Kyle

Sent from Mobile

On Feb 19, 2020, at 6:59 PM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:



Gregory Neagle

unread,
Feb 19, 2020, 7:48:59 PM2/19/20
to munk...@googlegroups.com
How would this work if no one is logged in?

Sent from my iPhone

On Feb 19, 2020, at 4:35 PM, Kyle Crawford <kcr...@gmail.com> wrote:

The idea being if we determine that startosinstall and softwareupdate -R do the right thing with a user logged in, could munki treat them as not requiring a logout.

Kyle Crawford

unread,
Feb 20, 2020, 1:24:53 AM2/20/20
to munk...@googlegroups.com
I don’t know.  I guess just as it does today.
Hopefully Apple fixes this so it works when logged out.

Having it work reliably when a user is logged in would handle a lot of cases.

But I suppose we shouldn’t give up on figuring out a way to handle loginwindow yet.

More testing to do.

Kyle

Sent from Mobile

On Feb 19, 2020, at 7:48 PM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

How would this work if no one is logged in?

Gregory Neagle

unread,
Feb 20, 2020, 12:06:47 PM2/20/20
to munk...@googlegroups.com
This might indeed be possible, if it actually works (won't shock me if it still fails to work as expected/desired when called from a LaunchDaemon).

It would probably require a fairly larger set of changes to Munki, and would take weeks or more of testing and debugging to get to a release state.

And I would not trust Apple to not break it all again this summer.

It really feels like the safest approach going forward is for Munki to stop trying to install Apple update at all, and instead, when there are pending/available Apple updates, instead of opening Managed Software Center, open the System Preferences preferences pane and "nudge" users to do Apple updates that way. Since (I believe) non-admins can install Apple updates from the System Preferences pane, this _should_ work relatively well for 1-to-1 deployed Macs, even if the primary user is not an admin.

How to handle OS upgrades is a harder topic.

-Greg

Gregory Neagle

unread,
Feb 20, 2020, 12:40:07 PM2/20/20
to 'Gregory Neagle' via munki-dev
A quick test of using a LaunchDaemon to run `softwareupdate -iaR` while a user is logged in on a VM running 10.14.5:

Software Update Tool

Finding available software

Downloaded macOS 10.14.6 Update
Installing macOS 10.14.6 Update
Done.

You have installed one or more updates that requires that you restart your computer.
Restarting to complete installation of selected updates.
Connection to tests-mac.local closed by remote host.
Connection to tests-mac.local closed.
softwareupdate then restarted the machine with no warning to the user and no opportunity to save open documents, etc.

So to use this "safely" we'd need to write code to request all open applications quit (except MSC.app), not proceed until they are all quit, then perhaps take over the entire screen to prevent apps from being relaunched, etc, etc. Seems difficult to get right. The UX would be unfamiliar and the chance of lost user data would dramatically increase. From what I'm seeing right now, this does not seem a promising route to take.

-Greg


Graham Pugh

unread,
Feb 20, 2020, 1:54:19 PM2/20/20
to munk...@googlegroups.com
Just a thought - do you think this restriction in the use of softwareupdate is intended, or an oversight? Is it worth filing FB?

Von meinem iPhone gesendet

Am 20.02.2020 um 18:40 schrieb 'Gregory Neagle' via munki-dev <munk...@googlegroups.com>:

A quick test of using a LaunchDaemon to run `softwareupdate -iaR` while a user is logged in on a VM running 10.14.5:

Gregory Neagle

unread,
Feb 20, 2020, 1:57:33 PM2/20/20
to munk...@googlegroups.com
I don't think anyone at Apple tests the use of `softwareupdate` outside of the context of a local admin running it in their Terminal window, and maybe, possibly, via ARD.

If this functionality is important to you, then yes, you should file a Feedback.

Personally I think that's like doing a rain dance. It might rain later, but the connection to the two things is dubious. (Weather systems probably aren't affected by human dances)

-Greg

Kyle Crawford

unread,
Feb 21, 2020, 1:16:44 AM2/21/20
to munki-dev
I was hoping that `/usr/libexec/remotectl show localbridge` would show pending update status, but it didn't in my testing. And it sounds like you need to do a lot of work to communicate with BridgeOS using XPC including disabling SIP so no go there as far as I can tell.  https://duo.com/labs/research/apple-t2-xpc

I did discover an nvram variable that is set when a BridgeOS is pending a shutdown:  (Checked on Mojave and Catalina so far.)

2020-02-13 12:55:45.659052-0500 0x1061d    Default     0x0                  13126  30   bosreporter: (BridgeOSInstall) [com.apple.mac.install:BridgeOSInstall] Setting BOSUpdateStarted with Thu Feb 13 12:52:53 2020 (uuid = C06CB61F-D314-48E8-83A3-F3D7866CC746)
2020-02-20 16:05:35.393457-0500 0x747      Default     0x0                  346    30   bosreporter: (BridgeOSInstall) [com.apple.mac.install:BridgeOSInstall] Clearing NVRAM state (BOSUpdateStarted)

This nvram variable BOSUpdateStarted contains the unix timestamp when the BridgeOS was applied (queued for install at a shutdown) and a uuid.

The nvram variable is cleared at startup.

I tried setting it manually, and shutting down.  That doesn't seem to be sufficient to trigger the shutdown/startup behavior, but the variable was cleared upon startup.

So as long as munki intercepts and handles the restart/shutdown behavior (is not ceding this to startosinstall/softwareupdate -R), we can check for this nvram variable (and validate timestamp if desired) and shutdown if found.

Technically I think this could be handled today using a postinstall_script or munki postflight that shuts down if this variable is set.  And perhaps that is the best course of action in the interim since we don't know for sure whether this nvram variable can be reliably used for detecting the shutdown requirement.

I'll see if Apple can confirm whether this is a good indicator for the shutdown requirement.

Kyle


On Thursday, February 20, 2020 at 1:57:33 PM UTC-5, gregn...@mac.com wrote:
I don't think anyone at Apple tests the use of `softwareupdate` outside of the context of a local admin running it in their Terminal window, and maybe, possibly, via ARD.

If this functionality is important to you, then yes, you should file a Feedback.

Personally I think that's like doing a rain dance. It might rain later, but the connection to the two things is dubious. (Weather systems probably aren't affected by human dances)

-Greg

-Greg


-Greg

-Greg




Kyle
-Greg

-Greg

To view this discussion on the web visit <a href="https://group

Kyle Crawford

unread,
Feb 27, 2020, 4:42:09 PM2/27/20
to munk...@googlegroups.com
Update on softwareupdate - -restart.

Apple says it has to include - -force (if no user is logged in.)!

I haven’t tested.

Kyle

Sent from Mobile

On Feb 21, 2020, at 1:16 AM, Kyle Crawford <kcr...@gmail.com> wrote:


To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/d96aa37c-8a7f-47cb-bb59-bdff02dc4ed9%40googlegroups.com.

Gregory Neagle

unread,
Feb 27, 2020, 4:47:22 PM2/27/20
to munki-dev
On Feb 27, 2020, at 1:42 PM, Kyle Crawford <kcr...@gmail.com> wrote:

Update on softwareupdate - -restart.

Apple says it has to include - -force (if no user is logged in.)!

I haven’t tested.

I don't plan to test myself any time soon. If they can't be bothered to document anything...

No mention of --restart or --force in `man softwareupdate`.

`softwareupdate --help` has this to say about `--force`:

--force Force an operation to complete.  Use with --background to trigger a background scan regardless of "Automatically check" pref

No mention or hint of its use together with --restart. Since it's not documented, even if it works today, it might not work tomorrow...

Forgive my skepticism this will work.

-Greg

Gregory Neagle

unread,
Feb 27, 2020, 6:53:25 PM2/27/20
to munki-dev
OK, I lied. This looks promising. I created a LaunchDaemon:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>test.greg.softwareupdate</string>
<key>OnDemand</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/softwareupdate</string>
<string>--install</string>
<string>--all</string>
<string>--restart</string>
<string>--force</string>
</array>
    <key>StandardOutPath</key>
    <string>/private/tmp/test.greg.softwareupdate.log</string>
</dict>
</plist>

I sshed into a 10.14.5 VM at the login window and loaded and started this job.
It downloaded several updates, including a 10.14.6 update, installed them, and actually RESTARTED.

The update has "About 29 minutes remaining" still, but it is happening.

I may not get time to test this with Munki code for a few days.

-Greg


Eric Holtam

unread,
Feb 27, 2020, 11:44:35 PM2/27/20
to munki-dev
I noticed that the 10.15.4 b3 update also has a BridgeOSUpdateCustomer (ProductID 061-81249).  I believe that means for T2 machines that update to 10.15.4b3 there should be a bridgeOS update as well. I have 2 test T2s that haven't had 10.15.4b3 installed on them yet.  Is there anything I can do to provide data on this?  Or would it be more beneficial to wait to use them for any kind of munki code test to possibly incorporate the force flag?


-Eric

-Greg

-Greg


-Greg

-Greg




Kyle
-Greg

On Tuesday, February 18, 2020 at 4:12:10 PM UTC+1, gregn...@mac.com wrote:<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color:

Gregory Neagle

unread,
Feb 28, 2020, 12:01:35 AM2/28/20
to munk...@googlegroups.com
I currently have no code that i expect to handle that any better.  Perhaps Kyle Crawford has some useful data we can leverage. 

Sent from my iPhone

On Feb 27, 2020, at 8:44 PM, Eric Holtam <eho...@gmail.com> wrote:


--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

Gregory Neagle

unread,
Feb 28, 2020, 12:11:13 AM2/28/20
to munk...@googlegroups.com
Oh: are you looking at upgrading from pre-Catalina to 10.15.4b3, or to use softwareupdate to update from another version of Catalina to 10.15.4b3?

Sent from my iPhone

On Feb 27, 2020, at 9:01 PM, Gregory Neagle <gregn...@mac.com> wrote:

I currently have no code that i expect to handle that any better.  Perhaps Kyle Crawford has some useful data we can leverage. 

Kyle Crawford

unread,
Feb 28, 2020, 12:44:20 AM2/28/20
to munk...@googlegroups.com
For startosinstall I am waiting for more info from Apple but so far they say they have confirmed that nvram variable BOSUpdateStarted is set when a BridgeOS update is pending following an install on 10.13.3 and later.

Kyle

Sent from Mobile

On Feb 28, 2020, at 12:11 AM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

Oh: are you looking at upgrading from pre-Catalina to 10.15.4b3, or to use softwareupdate to update from another version of Catalina to 10.15.4b3?

Kyle Crawford

unread,
Feb 28, 2020, 1:39:42 AM2/28/20
to munk...@googlegroups.com
Regarding softwareupdate -R, I have follow up questions out to Apple.  The man page wording is confusing about using force with restart.  Sounds like it might always restart even if not needed.  And will it shutdown if needed?

Kyle

Sent from Mobile

On Feb 28, 2020, at 12:44 AM, Kyle Crawford <kcr...@gmail.com> wrote:

For startosinstall I am waiting for more info from Apple but so far they say they have confirmed that nvram variable BOSUpdateStarted is set when a BridgeOS update is pending following an install on 10.13.3 and later.

Gregory Neagle

unread,
Feb 28, 2020, 1:41:05 AM2/28/20
to munki-dev
Both are good questions, and important to know the answer to!

-Greg

Kyle Crawford

unread,
Mar 2, 2020, 12:34:10 AM3/2/20
to munk...@googlegroups.com

On softwareupdate --restart with --force: Apple suggests we test to see if it does what we intend regardless of the man page wording.  I tried testing with an update that does require a restart and it restarted.  I attempted to try with an update that doesn't require a restart, but I don't have any so I told it to install Command Line Tools for Xcode by touching the /tmp file.  It installed and didn't restart but it didn't remove the /tmp file and the update still shows in --list so I'm not sure if that was a good test.


If someone could test --restart --force with an update that doesn't require a restart, that would be good.


We will also have to test a T2 update to validate that it shuts down.  That will require a test device with out-of-date BridgeOS.


On startosinstall, it seems like checking for nvram variable BOSUpdateStarted and that the device has a T2 is a passable indicator for whether a shutdown is required.  As long as the munki startosinstall postinstall_script or postflight run before the restart, this shutdown could be handled there without modification to munki itself.


Kyle


To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/CDC81D21-E11E-4F2D-AB80-86F4E17F3BD5%40mac.com.

Mike Solin

unread,
Mar 2, 2020, 1:20:24 AM3/2/20
to munk...@googlegroups.com
Regarding the /tmp file for the command line tools, apparently the file persisting after installation is what's supposed to happen:


To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/CAEc%3DQfssyiCzON2KBZHrJcCsr2o5D%2B8drwXq9uBF8BPnvoEv_A%40mail.gmail.com.

MiqViq

unread,
Mar 5, 2020, 5:41:03 AM3/5/20
to munki-dev
I might be little late for this but this has been working for me with my initial setup script:

#!/bin/bash

echo "* * * Installing all updates available from Apple * * *"
echo
echo "- - - MAKE SURE THIS COMPUTER IS CONNECTED TO A POWER SOURCE - - -"
echo
echo "- - - PLEASE WAIT UNTIL ALL UPDATES ARE INSTALLED - - -"
echo

if ! softwareupdate -l 2>&1 | grep -q 'No new software'
then
 /usr/sbin/softwareupdate -i -a &> /tmp/aswupd_log.txt
 chmod a+rw /tmp/aswupd_log.txt 2>/dev/null
 cat /tmp/aswupd_log.txt 2>/dev/null
 echo
 if grep -q -i 'must shut down' /tmp/aswupd_log.txt
 then
 echo
 echo "* * * UPDATES NEED SHUTDOWN NOW * * *"
 sleep 5
 halt
 else
 echo
 echo "* * * REBOOTING NOW * * *"
 sleep 5
 reboot
 fi
fi

echo "* * * Done with Apple updates * * *"

exit 0


-MiqViq

On Wednesday, February 12, 2020 at 2:06:32 AM UTC+2, Kyle Crawford wrote:
When doing a startosinstall-style upgrade using munki, T2 devices download iBridge OS updates during the prepare phase of the install to meet the BridgeOS version requirement for the upgrade.

These can be seen in /var/log/install.log.

2020-02-05 15:50:33-05 mac osinstallersetupd[55201]: Started downloading package com.apple.pkg.BridgeOSUpdateCustomer (http://swcdn.apple.com/content/downloads/13/03/061-62855-A_I1OL4KN694/q73ftsncfsp5s3ev58sl2u7chcyfep1wca/BridgeOSUpdateCustomer.pkg)



This happens as part of startosinstall, not a normal softwareupdate run.  And I think any configured CatalogURL is ignored.

The issue is that iBridge updates usually require a shutdown.

It after a BridgeOS update, the device is not shut down, but is instead restarted, the BridgeOS update will fail and thereby the OS upgrade will also fail.

munki has support for detecting the need for a shutdown when it is using softwareupdate, but not currently in startosinstall-based installs.

Currently with startosinstall, if munki has PerformAuthRestarts enabled, it will only every try to do a restart.

If PerformAuthRestarts is not enabled, I think munki allows startosinstall to handle the shutdown/restart and it does the right thing.

I'm not sure what can be done to improve this or whether PerformAuthRestarts still adds value.

There is no authshutdown option to fdesetup that I am aware of.

And I am not sure whether it is possible to detect the need for a shutdown during a startosinstall-based run.

If anyone else would like to confirm this behavior it might at least warrant a warning in the munki authrestarts wiki page and perhaps feedback to Apple.

Kyle

Michal Moravec

unread,
Mar 11, 2020, 8:33:41 AM3/11/20
to munki-dev
I did some testing with --force switch in 10.15.2 VM which I tried to update to 10.15.3.

# Start snapshot state

10.15.3 update is downloaded with `softwareupdate --download` and ready to install.
SSH is enabled. I am going to launch softwareupdate command via SSH switched to root shell using sudo su -.

# Test 1 GUI without --force

GUI state: logged in user 
Command: softwareupdate --install --all --restart
Result: Restart initiated. Update starts installing after restart.

# Test 2 GUI with --force

GUI state: logged in user 
Command: softwareupdate --install --all --restart --force
Result: Restart initiated. Update starts installing after restart.

# Test 3 LoginWindow without --force

GUI state: LoginWindow
Command: softwareupdate --install --all --restart
Result: Restart NOT initiated. macOS keep sitting on LoginWindow

# Test 4 LoginWindow with --force

GUI state: LoginWindow
Command: softwareupdate --install --all --restart --force
Result: Restart initiated. Update starts installing after restart.

Behavior of Test 1 and 3 is consistent with previous tests. Result of Test 4 is interesting and might help us.
I'll try again (Test 4 scenario) on real Macs when 10.15.4 hits.

Kyle Crawford

unread,
Apr 19, 2020, 11:18:52 PM4/19/20
to munk...@googlegroups.com
Since using a postflight check for the nvram variable that indicates the need for a T2 shutdown 6 weeks ago, I’ve not heard of any failures.  But we have postponed usual updates for most devices during the pandemic.

Kyle

Sent from Mobile

On Mar 11, 2020, at 8:33 AM, Michal Moravec <micha...@gmail.com> wrote:


--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages