Mojave – Install Crashes After Power On Login

firewallmacbook promacosmojave

I have a mid 2012 MBA (4GB ram, 128GB SSD) that I have upgraded from High Sierra to Mojave 10.14. the upgrade finished successfully.

When I power on I am presented with the initial logon screen, and on entering the password the machine starts to load up but barely the progress bar moves before the machine crashes, and I am presented with the ‘Your computer restarted because of a problem’ screen, and then straight back to the logon.

In addition the logon screen is incorrect and all the text and buttons are in a hard to read grey against the logon wallpaper of mountains. It’s as though dark mode is prematurely active. I might add, this photo was taken on a camera, it’s not a screenshot.

Greyed out logon prompt and buttons in fresh Mojave install

I am able to restore from a bootable CCC backup successfully. I have tried this upgrade a couple of times, with a fresh download of the installer from MAS each time.

I have seen similar issues reported elsewhere, and users claiming that 3rd party Audio HAL components cause an error due to incorrect signing. I have no 3rd party audio products. They were also able to SSH in to view the dmesg to establish which extension was failing. I cannot SSH in, as I don’t believe the relevant servers are started at that point in the boot. I get no response when I try.

I’m prepared to give this another go if anyone has a solid explanation. I have yet to try a clean install but I’d rather sort out the upgrade install problem first. I’m not interested in a debate of the merits of either method.

Otherwise I’ll wait it out until the first patch release and try again.

Thanks

.

Best Answer

Found both old Coriolis iDefrag and Little Snitch 3 kexts present in the system. Uninstalled LS3 and deleted the iDefrag stuff which I had deleted the app for ages ago.

MBA now boots.

In more detail.

Checked the system reports in Console.app and found kernel panics by time. I'm no expert in reading trace files, but that this showed up caused some concern.

0xffffff80b4c1bfa0 : 0xffffff80213590ce 
  Kernel Extensions in backtrace:
     com.coriolis-systems.driver.Snapshot(113.0)[B6C0FE6D-76C9-3C71-A43A-2D67ED604116]@0xffffff7fa1ffe000->0xffffff7fa2075fff
        dependency: com.apple.iokit.IOStorageFamily(2.1)[499E27C9-AC4D-3239-9FC4-754C7699FA76]@0xffffff7fa1fce000

After doing a check to remind me what this was from I found it was an old installation of iDefrag from the pre-SSD days. Although I had removed iDefrag a long time ago when moving to SSD it seems the kexts did not cause an issue up to Mojave.

I checked to see what other items had been quarantined by the Mojave install process, going by what had been reported in the syslog I searched for The Coriolis kexts and found them in the following folder (the migration folder name has been anonymised here...)

$ cd /Library/SystemMigration/History/Migration-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/QuarantineRoot/Library/StagedExtensions/Library/Extensions
$ ls -l
total 0
drwxr-xr-x  3 root  wheel  96 12 Jun  2014 ACS6x.kext
drwxr-xr-x  3 root  wheel  96 27 Jun  2016 ATTOCelerityFC8.kext
drwxr-xr-x  3 root  wheel  96 27 Jun  2016 ATTOExpressSASHBA2.kext
drwxr-xr-x  3 root  wheel  96 27 Jun  2016 ATTOExpressSASRAID2.kext
drwxr-xr-x  3 root  wheel  96 20 Aug  2013 ArcMSR.kext
drwxr-xr-x  3 root  wheel  96  1 Sep  2013 CalDigitHDProDrv.kext
drwxr-xr-x  3 root  wheel  96 11 Apr  2017 CoriolisOnlineHelper.kext
drwxr-xr-x  3 root  wheel  96 11 Apr  2017 CoriolisSnapshot.kext
drwxr-xr-x  3 root  wheel  96 15 Aug  2014 HighPointIOP.kext   
drwxr-xr-x  3 root  wheel  96 15 Aug  2014 HighPointRR.kext
drwxr-xr-x  3 root  wheel  96  5 Dec  2017 LittleSnitch.kext
drwxr-xr-x  3 root  wheel  96 31 Mar  2017 PromiseSTEX.kext
drwxr-xr-x  3 root  wheel  96 22 Aug  2017 SoftRAID.kext

That the LittleSnitch.kext was also present here gave me the clue that Little Snitch 3 was possibly incompatible. After verifying this on the OBDev website I removed LS3 using the uninstaller https://www.obdev.at/support/index.html?product=LS&topic=faq&entry=245442241039726

Although kexts get quarantined it appears they are still present in the system somewhere, so the uninstall seemed the best approach. Indeed the LS3 uninstaller rebuilt boot caches.

The normal boot now succeeds.

Related Question