Will not boot into Safe Mode

FWIW, I'm having the same problem with a brand spanking new Mac Pro running 10.8.3. It came running 10.8.3, but for good measure, I re-installed it with no success. As with everyone else, I tried booting into safe mode holding down the shift key and got stalled at abt 1/3 of the way through the progress bar. I left it overnight, to no avail. I followed the instructions to remove the fsck_hfs from the safemode boot, and that got me into safe mode. Sadly for me, the reason I was trying to get to safemode is because Preview was crashing on me. It still crashes in safemode, so that problem isn't fixed. But at least I was able to test it in safemode.

I do have a ton of Crucial RAM installed on this machine (it's my research computing machine, so I've got 52 GB of RAM. Perhaps I shouldn't be surprised that fsck stalled for so long. I haven't bothered trying to remove the RAM. I could probably be nudged to if anyone was interested, but this isn't my primary problem.

Thanks, laughing_badger. And no thanks to Apple. My next research machine is going to be cheaper, more powerful, and less kludgy than this gold plated hunk of s**t.

You can also, on reboot, hold down the Command-Option-P-R keys to reset the PRam. See: http://support.apple.com/kb/ht1379

From the discussions, what I gather are some of the problems people encounter:

1. There is an issue with the disk and fsck_hfs hangs during the safe boot.
   1. Resolve this by: Disk Warrior, or by running fsck_hfs -fy from the terminal in a recovery mode boot. Occasionally the diskutility can also fix this issue.
   2. Usually after that the safe boot works.
2. There is a hardware issue, related to memory or some other component. It would probably be a good idea to run a full hardware test, though I haven't seen too many people do this. Instructions are at: http://support.apple.com/kb/ht1509
3. There is something else having to do with other installation issues. Sometime here a complete reinstall on an erased partition will fix the problem:
   1. Boot into recovery mode.
   2. Use disk utility to erase your system partition.
   3. Re-install Lion on the clean partition.
   4. Reboot, and immediately see if safe-mode now works.

My case seems to be the 3rd case. After the clean install I could do a safe-mode boot. I then went to my timemachine backup and restored all my files, however, after the restore, my problem with safemode boot was back. I would conclude that the issue is some kernel module that has a unresolved dependency when it boots in safe-mode and thus hangs.

Does anyone know how to debug the order in which the kernel modules get loaded in safe mode?

Mine hangs right after:

IOThunderboltSwitch(0x0)::listenerCallback - Thunderbolt HPD packet for route = 0x0 port = 12 unplus=0

AppleUSBMultitouchDriver::checkStatus - received Status Packet, Payload 2: device was reinitialized

So how do I find out what module gets loaded after the AppleUSBMultiTouchDriver is started?

PhotoMau wrote:

You can also, on reboot, hold down the Command-Option-P-R keys to reset the PRam. See: http://support.apple.com/kb/ht1379

It does nothing for the issue, which is already covered in this thread.

PhotoMau wrote:

There is a hardware issue, related to memory or some other component. It would probably be a good idea to run a full hardware test, though I haven't seen too many people do this. Instructions are at: http://support.apple.com/kb/ht1509

I did both the basic and extended hardware tests. They found nothing. This was after Apple "techs" had put me through all sorts of other exercises—including zapping PRAM, as someone suggested above—using DiskUtility in recovery mode, and reinstalling Mountain Lion, which consumed hours of wasted time. DiskUtility, predictably, had found nothing wrong with the system disk, either.

None of these Mac 101 fixes has resolved the issue. There is some underlying system-level BUG that, inexcusably, is preventing users from booting into safe mode, while giving absolutely zero indication or identifiable symptom of what is causing it to hang.

Thank you for narrowing down which kernal module loaded last before yours hung. I pray that leads to some kind of actual fix—but it won't come from hapless users pokiong around in the dark trying to find workarounds.

I fully agree and have since just made sure I have good backups because I won't be using safe mode anymore. The bigger problem is APPLE NEEDS A REAL ISSUE TRACKING SYSTEM where actual Apple technicians can at least acknowledge issues instead of users filling up the discussion board.

I did both the basic and extended hardware tests. They found nothing. This was after Apple "techs" had put me through all sorts of other exercises—including zapping PRAM, as someone suggested above—using DiskUtility in recovery mode, and reinstalling Mountain Lion, which consumed hours of wasted time. DiskUtility, predictably, had found nothing wrong with the system disk, either.

I find this approach puzzling. It appears to imply that there is no known defect in the safe boot procedure and the software it uses, and the tests you performed were intended to coax the system into revealing that there is a hardware issue, or file system defect causing safe boot to fail.

As was discussed here before, none of these steps taken has managed to shed any light on what is going on when the file system check (run as part of the safe boot process; it's what makes the progress bar appear, and updates it while it runs) becomes stuck. laughing_badger demonstrated that if you substitute the file system check command (/sbin/fsck_hfs) with a dummy (e.g. /usr/bin/true) then the safe boot will run its course, although without performing a file system check.

I expect that Apple QA will take an interest in fsck_hfs, eventually. The problem may be difficult to reproduce in-house, and Apple may be reluctant to share diagnostic/debug builds of fsck_hfs with 3rd parties, even if these third parties could reproduce the problem at will.

It was recommended I do this hardware test in another forum on my MBP 2009 and no issues were found. If this is a hradware issue, it sure is eluding many people who have stock Mac machines or have returned the mac machine to stock such as reducing ram to original chips supplied with thier machines.

I still think there is a major QA hole somewhere in Apple's system. And more to the point regression testing on the sleep/power sleep - shutdown and startup is required at Apple's labs... IMHO.

Off-topic from this bug

> … ISSUE TRACKING SYSTEM where actual Apple technicians

> can at least acknowledge issues instead of users filling up the discussion board.

Please see answers to a popular question, Can I browse other people's (Apple) bug reports?

This bug

My own report is one of a number that I refrain from sharing in Open Radar at this time.

For this one, I share relevant information in this topic.

Gregg Green1, have you sent feedback to Apple?

Earlier I suggested:

> less content in the OS X startup volume.

Has anyone tried methodically reducing the content until safe boot succeeds?

A methodical approach might include at least:

1. beginning with a well optimised disk – in particular, more than enough contiguous free space for a rebuilt catalog B-tree to be contiguous
2. after each significant reduction in the content of the volume, a rebuild of the catalog B-tree and/or attributes B-tree.

Graham Perrin wrote:

Earlier I suggested:

> less content in the OS X startup volume.

Has anyone tried methodically reducing the content until safe boot succeeds?

A methodical approach might include at least:

1. beginning with a well optimised disk – in particular, more than enough contiguous free space for a rebuilt catalog B-tree to be contiguous
2. after each significant reduction in the content of the volume, a rebuild of the catalog B-tree and/or attributes B-tree.

I hope you won't mind if I speak candidly with you, but if I'd wanted to be a hard drive technician, I would have invested my education to become one. I didn't, and don't intend to change careers at this stage of life.

I work in creative arts, not arcane computer arts. I pay handsomely for hardware and software that ostensibly has been designed to work by people who claim superior training and know-how in those disciplines.

I wouldn't know a B-tree from a pear tree, or a partridge in either, and I don't want to find out. I have neither the time nor the inclination to be a lab rat for Apple, after paying them the amount I did for this computer. Nor should I have to. They promote that their computers can boot into safe mode. This one can't. It is not even 60 days out of the box. It is defective, and it is their responsibility, not mine, to find out why and correct it.

fsck_hfs(8) OS X Manual Page

> … a quick reference for people who already understand a technology …

– includes the option and flags for rebuilding B-trees.

i wonder how many people have actually installed a virgin system on a different drive to run a genuine test....or for that matter how many of these new complainers have actually read the entire thread so we dont have to keep repeating ourselves.

Installing a separate system doesn't involve a lot of time (remember to hide an extra copy of the 10.8.3 installer in a new location so it doesn't delete itself after download)

Have you sent feedback to Apple?

> … more than enough contiguous free space for a rebuilt catalog B-tree to be contiguous …

The freely available demo version of iDefrag can:

a) easily show the size, in GB, of the catalog B-tree (shown as the Catalog File)

b) offer a rough guide, with its layout representation of the disk, to the sizes of contiguous free spaces.