Macjutsu
Mac OS 15.4 is not installing logs show a authentication error
Is anyone else having issues with installing 15.4? I am experiencing a failure with it. 1 - M3 MacBook Pro 2 - M1 MacBook Pros Digging into the Superman updater logs, all I see is Tue Apr 01 09:27:41 MAC super[52745]: **** TIMESTAMP **** Tue Apr 01 09:27:41 MAC super[52745]: **** TIMESTAMP **** Tue Apr 01 09:27:41 MAC super[52745]: **** S.U.P.E.R.M.A.N. 5.0.0 - UPDATE/UPGRADE MACOS VIA SOFTWAREUPDATE COMPLETED **** Tue Apr 01 11:44:38 MAC super[79473]: **** S.U.P.E.R.M.A.N. 5.0.0 - DOWNLOAD macOS Sequoia VIA SOFTWAREUPDATE START **** Software Update Tool Finding available software Downloading macOS Sequoia 15.4 Downloaded: macOS Sequoia 15.4 Failed to authenticate
I have the same issue. Looking at other error reports, it looks like it's a change to the Apple's softwareupdate system. I've had to pull it back from our production environment, as it keeps prompting the users to install before getting stuck on the "Restart imminent, save your work" screen
We are experiencing the same issues but more similar to this since we are doing scheduled installs. The Failed to authenticate issue is already tracked here
https://github.com/Macjutsu/super/issues/277
However, to me it seems that 15.4 in general is broken because users can't install it through normal software update tool either. Some users can't but not all. Looking at beta reviews the 15.4 rollout seems to have problems on newer macs (like m3, m4) (ref: https://www.reddit.com/r/MacOSBeta/comments/1jdwwey/unable_to_install_macos_154_beta_4/) but my feeling (yeah I know horrible to refer to feelings but haven't found a logical denominator yet) here is that all ranges of releases have issues
Just adding my feedback to this. We are also seeing this and so far only on M1 and M3 Macs. M2 seems fine.
Seems to be an issue with the update itself as opposed to Super as it won't authenticate no matter what account or credentials are used (standard user, admin) or which update method used (Super, System Settings, command line softwareupdate). Installation just fails.
Downloaded macOS: macOS Sequoia 15.4-24E248
We're having issues too, but it really seems like 15.4 is the problem. Even though the normal Software Update it fails. We're seeing this on Intel and M series, but for whatever reason, not all of them... many update just fine.
We are also facing same issues in our environment, does anyone have any work around for this?
I took one of our affected M1's and completely erased it. It then loads Monterey since that is what it came with. I then tried running the full 15.4 installer and failed and reverted back to Monterey. This is really messed up, I don't think I've seen as badly a broken update like this in decades.
Glad this isn't just me. I tried to update from 15.3.2 and did the usual reboot to install. The install progress bar got stuck at some point and eventually the machine seemed to complete the update. I then checked and realised the machine was still on 15.3.2. Now macOS keeps showing me that an update to 15.4 is available. Each time I reboot to install, the machine simply reboots without attempting an install.
The general guideline that seems to work for most is updating through booting in safe mode. There are some theories but nothing confirmed as of yet afaik. It's not really ideal in our set up but might work for you depending on your fleet.
I would recommend joining mac admins slack and checking the #macos-15-sequoia channel
I got my test machine to update by doing a DUF reset with the Universal 15.4 restore. Obviously, that's destructive and not optimal.
The crash log points to dart.c line 535 which is this:
529 static int apple_dart_map_pages(struct iommu_domain *domain, unsigned long iova, 530 phys_addr_t paddr, size_t pgsize, 531 size_t pgcount, int prot, gfp_t gfp, 532 size_t *mapped) 533 { 534 struct apple_dart_domain *dart_domain = to_dart_domain(domain); 535 struct io_pgtable_ops *ops = dart_domain->pgtbl_ops; 536 537 if (!ops) 538 return -ENODEV; 539 540 return ops->map_pages(ops, iova, paddr, pgsize, pgcount, prot, gfp, 541 mapped); 542 } https://codebrowser.dev/linux/linux/drivers/iommu/apple-dart.c.html
ENODEV is a posix error code Operation not supported by device. static var ENODEV: POSIXErrorCode { get } https://developer.apple.com/documentation/foundation/posixerror/enodev
Boot process overview from Apple:
Boot ROM hands off to LLB. LLB loads system-paired firmware and the LocalPolicy for the selected macOS. LLB locks an indication into the Boot Progress Register (BPR) that it’s booting into macOS, and hands off to iBoot. iBoot loads the macOS-paired firmware, the static trust cache, the device tree, and the Boot Kernel Collection. If the LocalPolicy allows it, iBoot loads the Auxiliary Kernel Collection (AuxKC) of third-party kexts. If the LocalPolicy didn’t disable it, iBoot verifies the root signature hash for the signed system volume (SSV). https://support.apple.com/guide/security/boot-modes-sec10869885b/web
The installer goes through the full process for 15.4 but crashes on reboot because of an auth failure (of the OIK?). Entering DFU mode and restoring works because it erases the keys in the secure enclave so there is no key mismatch on reboot.
Secure Key Creation When macOS is first installed in the factory, or when a tethered erase-install is performed, the Mac runs code from temporary restore RAM disk to initialize the default state. During this process, the restore environment creates a new pair of public and private keys which are held in the Secure Enclave. The private key is referred to as the Owner Identity Key (OIK). If any OIK already exists, it’s destroyed as part of this process. The restore environment also initializes the key used for Activation Lock; the User Identity Key (UIK). Part of that process which is unique to a Mac with Apple silicon is when UIK certification is requested for Activation Lock, a set of requested constraints to be enforced at validation-time on the LocalPolicy are included. If the device can’t get a UIK certified for Activation Lock (for example, because the device is currently associated with a Find My Mac account and reported as lost), its unable to proceed further to create a Local Policy. If a device is issued a User identity Certificate (ucrt), that ucrt contains server imposed policy constraints and user requested policy constraints in an X.509 v3 extension. https://support.apple.com/guide/security/localpolicy-signing-key-creation-management-sec1f90fbad1/web
IMO this is an installer bug that fails on the verification of the secure key(OIK?) on M1 Macs (OG MacBook Air and maybe others). You are supposed to be allowed to create a key for external volumes through the Startup disk and sometimes the installer will prompt you to do this but it doesn't stick and ultimately results in the same failure. The only successful workaround is DFU restore (erase and install). That nukes the key in the Secure Enclave and creates a new one. Then restore apps and files from Time Machine.
Yeah 15.4.1 seems to work for our fleet. Haven't tested it fully with superman but should be good 🤞
Is this issue still present with https://github.com/Macjutsu/super/releases/tag/v5.1.0-rc1?
Is this issue still present with https://github.com/Macjutsu/super/releases/tag/v5.1.0-rc1?
For us, once we got past the 5 or 6 having this issue, it has never appeared again in 5.0. Something must have happened to those particular machines at some point that didn't affect the others.
That or the 15.4.1 and subsequent updates solved the issue.