MBPr frozen after beta 6

The past few seeds all caused my MBPr (early 2012) to freeze at the black and white progress bar around 50-66%. After waiting each time about an hour, I forced it to reboot and it just went in, got the recovered from a crash screen, submitted logs to Apple and went on my merry way. Now last night it is refusing to get in. I tried holding Shift during boot, tried single user mode, but I really didn't know what I look for in why this is crashing/freezing. I see others having similar issues too but couldn't find any solutions so I apologise in advance if this is a duplicate.


Verbose boot log:


AirPort: RSN handshake completed on en0
Unexpected payload found for message 9, dataLen 0
Can't get kextd port.
Can't get kextd port.
Can't get kextd port.
VBoxFltDrv: version 4.3.28 r100309
Can't get kextd port.
VBoxFltDrv: version 4.3.28 r100309
Can't get kextd port.
Can't get kextd port.
Can't get kextd port.
Can't get kextd port.
Can't get kextd port.
Can't get kextd port.
AppleUSBMultitouchDriver::checkStatus - received Status Paclet, Payload 2: device was reinitialized
Can't get kextd port.
Can't get kextd port.
IOBluetoothUSBDFU::probe
IOBluetoothUSBDFU::probe ProductID - 0x8296 FirmwareVersion - 0x0151
Can't get kextd port.
Can't get kextd port.
Can't get kextd port.
**** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x2008 ****
**** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed (matched on Device) -- 0x2000 ****
pci pause: SDXC
en1: promiscuous mode enable succeeded
en2: promiscuous mode enable succeeded
IO80211AWDPeerManager::setAwdlOperatingMode Setting the AWDL operation mode from SUSPENDED to AUTO
IO80211AWDPeerManager::setAwdlAutoMode Resuming AWDL
IO80211AWDPeerManager::setAwdlOperatingMode Setting the AWDL operation mode from AUTO to SUSPENDED
IO80211AWDPeerManager::setAwdlSuspendedMode() Suspending AWDL, enterQuietMode(true)
IO80211AWDPeerManager::setAwdlOperatingMode Setting the AWDL operation mode from SUSPENDED to AUTO
IO80211AWDPeerManager::setAwdlAutoMode Resuming AWDL
Can't get kextd port.

Replies

Yes, it could be. I've heard of putting a card in for a sdxc related hang - worth a shot.


The only non-system kexts I could see in the photo were the VBox ones - so I would not suggest removing any others. Did you ever install Eltima SyncMate? That's been the other culprit these last couple of days.


And just to double-check: there's no longer any mention of VBoxFltDrv for VBoxAdpDrv in Verbose?

At least not on the bottom.. I see VirtualInterface::init but that's it really, and just the pause on the sdxc still. Then it resumes, and it just seems to stop at AWDLPeerManager::(various class functions here) for some time and eventually shows one last kext. I will try the sd card.

VirtualInterface and AWDLPeerManager are both Apple processes.

During bootup various things are loading in parallel and so the fact that they appear close to the end is not as significant as it might seem.


However, the final kext is interesting - it prompted me to double check your photo and, right at the tippy-top, I could make out supdrvDTraceInit.


This is related to another of the VBox kexts and is one we might have missed.

Please look out for it on a current Verbose boot and let me know...

I placed an sd card... seems like the sdxc pause no longer occurs but it still stops right after the awdl part... though there is a minute or two pause before the last kext port is displayed, as before.

And supdrvDTraceInit? I think it's the most promising lead we've got at the moment.

this is latest screen shot, with the sd card in it.


i [dot] imgur [dot] com [slash] eHuM5io [dot] jpg

in /Library/Extensions


ACS6.kext

TTOCelerityFC8.kext

ATTOExpressSASHBA2.kext

ATTOExpressSASSRAID22.kext

ArcNSR.kext

CalDigtiHDProDrv.kext

HighPointIOP.kext

HighPointRR.kext

PromiseSTEX.kext

SoftRAID.kext

hp_io_enabler_compound.kext

I've looked the latest over thoroughly and, aside for the "Can't find kextd port." messages - which tend to be tell-tale sign of an incompatible kext gumming up the works - nothing I can see is cause for boot fail. It still seems some unknown kext is responsible.


As for your /Library/Extensions folder, all is good there - all native except "hp_io_enabler_compound.kext", which is benign I think.


One thing though: TTOCelerityFC8.kext should be ATTOCelerityFC8.kext, but I'm guessing that was a copy-paste error.

The following is a link to a script that does a thorough cleanout of VirtualBox.

virtualbox.org/svn/vbox/trunk/src/VBox/Installer/darwin/DiskImage/VirtualBox_Uninstall.tool


You should be able to run it by copying it out of Safari while in Recovery Mode.

Yeah I typed it very fast and didnt know I can use safari in recovery mode, since i been using SUM.

I tried to manually run the commands by copying it manually the main keypoints. None of the kext from the for each loop resulted in naything found.


But I ran the script it said it got rid of things but made no difference it stopped at the same point.

With nothing else to go on, I'd say your best bet is to use Recovery Mode to re-install. It will put you back to DP1 but will leave your data intact. You could attempt to install back up through to DB6 again then - there's at least a 50/50 chance that it would install successfully next time around having already removed VirtualBox. Alternatively you could wait for DB7, which I would guess will be a combo, allowing you to skip DB6 altogether.

I am reading /var/log/system.log and just see pretty much the same thing as the verbose startup.

The very last lines show


kernel[0]: Can;t get kext port.

apsd[100]: CFnetwork SSLHandshake failed (-9807)

--- last mesage repeated 1 time ---

watchdog[214]: [watchdog_daemon] @(_wd_daemon_service_thread) - service (com.apple.WindowServer) reported as non responsive.

It's useful that the system log nearly mirrors verbose boot.


I double checked all 3 processes and the service mentioned at the end of it though - I'm afraid there's nothing there to indicate what the issue is.

I still think the likelihood is that it's a kext though - you could find the first "Can't get kextd port" (of the latest boot) and post the lines in system.log that precede it (starting at the first timestamp following powerup)

I will try to mount a flash drive in recovery or single user so I can copy the entire log and read it on an external monitor. The text is so small from the retina display and standard vi/grepping commands makes it more difficult to see. Plus I am unable to update the locate db. And I am so used to my colour highlighting with grep/find makes it even more hard to see anything. Plus, the dates are all 3 Jan for some reason. Any specific of what you want to see, like I did a tail -100 on the log. Would you want the beginning part of that? Or I should flush the log so I can start it fresh since by now there is a tonne of duplicated entries from doing this repeatidly.

Interesting about the time. That itself can cause boot issues - It has progressed from 00:00 on the 1st Jan (probably 1981) to some time on the 3rd - that's how much time has gone by since the kernel time got reset with the original crash (this doesn't happen through SMC or NVRAM resets). To fix it from SUM or the Terminal in RM, type:


date 0807162715

  • (that sets the date to Aug 07, 2015, 4:27 PM - you can improve it)


See if that fixes it.


Failing that, flush the log and start fresh as you described.