Macbook Pro (late 2011; OS X 10.8.2) fails to boot (verbose mode shows "FIPS USER SPACE POST SUCCESS" last)

can you show a photo from screen in verbose mode? Not only last string is interesting.

Read here:

http://support.apple.com/kb/HT5396

The problem has nothing to do with FIPS. It's a hardware fault. Make a "Genius" appointment at an Apple Store to have the machine tested.

Back up all data on the internal drive(s) before you hand over your computer to anyone. If privacy is a concern, erase the data partition(s) with the option to write zeros* (do this only if you have at least two complete, independent backups, and you know how to restore to bare metal from any of them.) Don’t erase the recovery partition, if present.

*An SSD doesn't need to be zeroed.

If you want to preserve the data on the internal drive(s), you must try to back up now, before you do anything else. It may or may not be possible. If you don't care about the data, you can skip this step.

There are several ways to back up a Mac that is unable to fully boot. You need an external hard drive to hold the backup data.

1. Boot into Recovery (command-R at startup) or from a local Time Machine backup volume (option key at startup.) Launch Disk Utility and follow the instructions in the support article linked below, under “Instructions for backing up to an external hard disk via Disk Utility.”

How to back up and restore your files

2. If you have access to a working Mac, and both it and the non-working Mac have FireWire or Thunderbolt ports, boot the non-working Mac in target disk mode by holding down the key combination command-T at the startup chime. Connect the two Macs with a FireWire or Thunderbolt cable. The internal drive of the machine running in target mode will mount as an external drive on the other machine. Copy the data to another drive. This technique won't work with USB, Ethernet, Wi-Fi, or Bluetooth.

How to use and troubleshoot FireWire target disk mode

3. If the internal drive of the non-working Mac is user-replaceable, remove it and mount it in an external enclosure or drive dock. Use another Mac to copy the data.

The step in the boot process that comes after FIPS initialization is the one that's failing. That would be "waitForSystemMapper." I can't find documentation of what that does, but if you can't get past it even in single-user mode after a reinstallation, there isn't much else it can be but a hardware fault. Third-party software would have no effect in single-user mode.

after FIPS initialization is the one that's failing. That would be "waitForSystemMapper."

independent kexts and services start asyncronously, so there are no warranty of some constant order of initialisation.

I met (and not once) weird thing - kext with incorrect permissions of internal parts(like different NIC plugins), but correct permissions of package itself, will not be permission-repaired.

And of cos incorrectly owned part will not load, and things can go really strange, including silent lockup.

I don't want to tell that it is it, but i'd give it a try.

like this:

$ sudo chown -R 0:0 /System/Library/Extensions

$ sudo chmod -R 755 /System/Library/Extensions

The second time where I did a fresh install (transferred data afterwards from the backup though) it at least worked for a day, so I would guess that this makes a hardware fault less likely, quite apart from the guy in the store finding none.

I'd think the opposite. Hardware faults are often intermittent in their effects. I also think that failure of "Geniuses" to detect such faults is a common occurrence. They have a software test suite that's a cut above the almost worthless Apple Hardware Test in accuracy, but still far from perfect.

When I ran the cc_fips_test -v command using safe mode, it indeed came up with an unsuccessful module integrity check

I get the same thing, and my Mac isn't failing to boot.

BSD root : disk0s2

....

/dev/rdisk0s2 (NO WRITE)

tells us that root FS mounted read-only

executing fsck_hfs

tells us that FS repair invoked - that is normal after unusual reboot, but should be invoked on RW filesystem....

.... and there are no traces of actual fsck execution, no even error messages about RO mode.

something is wrong with filesystem.

Looks like something of what you're using sets root FS attributes to RO.

Do you use any third-party system-related tools? Optimizers, preventers, backupers, syncronizers, data lockers, encryption - I don't know what is it?

I have run in to the same issue you seem to have had, after having installed a new ssd disk. Did a clean install resolve your issue?

Just wanted to post an update here because I was having the same problem as Ivo Nicola. Verbose stops just after FIPS.

I took it to an Apple Genius who could not find anything wrong with my machine too (all hardware checked out).

Macbook Pro

15-inch, Late 2011

Processor 2.4 GHz Intel Core i7

Memory 8 GB 1333 MHz DDR3

Graphics AMD Radeon HD 6770M 1024 MB

Software OS X 10.8.2 (12C60)

Long story short, I deleted nearly all of the apps I'd installed over the last few months. Ran a disc check. Restarted, and voilà! Started up normally.

Here's a screenshot of my verbose check now. You'll notice that it's NOT 'waitForSystemMapper' that comes directly after FIPS on my machine but rather 'Ethernet address', 'Waiting for DSMOS', and 'macx_swapon':

So just want to confirm that it's not a hardware problem.

+1

Same thing happend to me on an iMac late 2009 running OS X 10.8.2. It appeared short after a fresh install. Until than I only had a few high-level applications and VirusBarrier Express (as a low-level application) installed. So I already had a suspicion that it would be VirusBarrier Express' fault.

After reading about VirusBarrier Express here, I'm almost certain that VirusBarrier Express is causing this problem.

If you are reading this, it's likely that you also have this issue. So I would like to bring up some hints to bring you back on track:

Since your Mac isn't starting up any more (in my case even Safe Boot didn't work) you may be concerned about your un-backuped data (such data surely shouldn't exist ;-) ). Don't panic - chances are high you can still access your files.

If you are in the nice position to have a bootable USB-stick with (Mountain) Lion prepared (http://arstechnica.com/apple/2012/07/how-to-create-a-bootable-backup-mountain-li on-install-disk/), just plug it in and restart your Mac hitting "alt"-key until you reach the startup-volume-selection and move on to the "OS X Utilities". (If you don't have it prepared you can do it on another Mac running (Mountain) Lion.)

Sure you can try an install-process from here, but if you prefer being better safe than sorry you can copy files from your HD to an external drive at this stage. Open "Utilities | Terminal" and cd to "/Volumes". Here you find your HD and external drives. You can copy your stuff with something like this:

cp -R /Volumes/yourMacHD/Users/yourUsername /Volumes/yourExternalUSB

If you do not have an USB-stick and no other Mac to create one, you can still enter the single-user mode (hit command-s with startup). Maybe you have to mount your external drive manually (didn't try it out) - something like "mount -t auto /dev/disk1s2 /your-mountpoint". In this situaltion your HD should be mounted on "/", so you do not need to copy from "/Volumes":

cp -R /Users/yourUsername /your-mountpoint

After backup you have a lot of options. Try to repair your system or do a fresh install. Good luck!

My machine 13 inch macbook pro 10.8.2 stucks after FIPS USER SPACE POST for around 50 minutes. It used to stuck for 10-15 minutes earler. The very next output seen on screen after FIPS USER SPACE POST is Synced /var/db/. So I think it's taking time on this step. What might have caused this?