Intermittent Prohibitory Sign on Startup, Easily Fixed but Recurring

New Contributor

Hey everyone,

I am at my wit's end with this one. Can't figure out what is actually causing this issue, or even how to reproduce it to see it besides with a photograph our students send in to the Helpdesk.

Some (not all) of our publicly available computers are intermittently getting stuck booting to the prohibitory sign. If you select the startup disk as Macintosh HD, they boot with no problems. I'll receive a kernel panic report error, and then I will be unable to reproduce the issue, no matter what I try on the machine.

These machines are configured through JAMF policies and the Apple School Manager, not imaged. They are secured with Deep Freeze, but I don't see any DF kexts in the kernel panic log. They are running MacOS 10.14.6, and the software deployed to them is all pretty standard stuff. (Office, Firefox, Chrome, Adobe software, SPSS, some chemistry programs and a Horizon virtual app client.)

Hardware wise, we're looking at 1 2019 iMac, and 3 2019 13" MacBook Pros, running the same configuration.

Any ideas would be greatly appreciated. Here's one of the panic reports (they're all identical) if that helps too:

Anonymous UUID: CF364081-9CE0-B1E1-59F9-F45A96B82450

Thu Oct 17 16:46:42 2019

Panic Report
panic(cpu 0 caller 0xffffff800ca7e1ca): "root image authentication failed (err = 2) "@/BuildRoot/Library/Caches/
Backtrace (CPU 0), Frame : Return Address
0xffffff80ff053790 : 0xffffff800c5ae6ed 0xffffff80ff0537e0 : 0xffffff800c6ea185 0xffffff80ff053820 : 0xffffff800c6db8ba 0xffffff80ff053890 : 0xffffff800c55bb40 0xffffff80ff0538b0 : 0xffffff800c5ae107 0xffffff80ff0539d0 : 0xffffff800c5adf53 0xffffff80ff053a40 : 0xffffff800ca7e1ca 0xffffff80ff053f80 : 0xffffff800c5d7788 0xffffff80ff053fa0 : 0xffffff800c55b0ce

BSD process name corresponding to current thread: kernel_task
Boot args: -rootdmg-ramdisk auth-root-dmg=file:///macOS%20Install%20Data/Locked%20Files/BaseSystem.dmg

Mac OS version:
Not yet set

Kernel version:
Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
Kernel UUID: C41337A1-0EC3-3896-A954-A1F85E849D53
Kernel slide: 0x000000000c200000
Kernel text base: 0xffffff800c400000
__HIB text base: 0xffffff800c300000
System model name: MacBookPro14,1 (Mac-B4831CEBD52A0C4C)

System uptime in nanoseconds: 1499160481
last loaded kext at 1270469908: 945.275.7 (addr 0xffffff7f8fb17000, size 1130496)
loaded kexts: 945.275.7 3.0.1 407.200.4 40 1.0.0d1 1.0.0 1.0 138.4 1400.1.1 1.0 161.0.0 6.1 2.0 2.1 6.1 1.7 201 8 3 1 2450.1 208 138.4 6.0.14d3 2450.1 2440.2 55.1 5.6.9 5.6.9 2.1.5 3.4.1 3.0.60 55.1 4.7.9 6.8.6 3.0.60 3.0.60 1200.12.2 1.0.1b8 1.0.4 2.1.0 3.0.60 3.0.60 1.2 1.2 1.0 900.4.2 2.1 2.1 1.1 2.0.0 3 300.0 1.0.0d1 2 456.260.3 1.0.5 145.200.2 408.250.3 408.250.3 1 1.0 1 1.0.1 1 28.30 1.0 740.2 3.4 493.0.0 2.1 6.0.14d3 1.2 1.0 1.0 47 6.1 3.1.9 2.9 1.4 1 1 1.0

Model: MacBookPro14,1, BootROM, 2 processors, Intel Core i5, 2.3 GHz, 8 GB, SMC 2.43f6
Graphics: kHW_IntelIrisGraphics640Item, Intel Iris Plus Graphics 640, spdisplays_builtin
Memory Module: BANK 0/DIMM0, 4 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C3531324D3332443250462D3039
Memory Module: BANK 1/DIMM0, 4 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C3531324D3332443250462D3039
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x170), Broadcom BCM43xx 1.0 ( AirPortDriverBrcmNIC-1305.8)
Bluetooth: Version 6.0.14d3, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.0 Bus
Thunderbolt Bus: MacBook Pro, Apple Inc., 41.1


New Contributor

We have been having the same issue with our classroom Macs. COVID-19 forced us to kick the can down the road, but now we are back and it is as well.

This happened on Mojave and is now also occurring with Catalina.

Did this ever get solved?

New Contributor

We also have this issue across our large fleet. Very rare but enough to be an issue.

2019 iMacs rolled back to Mojave running latest Deepfreeze (non-cloud version).

I had worried it was because we rolled back to 10.14 but since @turnerj is getting this on 10.15 that is not the issue.

We have found that simply booting into the recovery partition and performing no actions and a reboot fixes is but it can re-occur, sometimes multiple times a day on the same machine.

I also found re-running the macOS installer manually from recovery seems to fix it for a longer period but it can come back 6 months later on the same machine.

@turnerj are you running deepfreeze as well? If yes then we know where to head next ;)