Q: Will not boot into Safe Mode

Sure. Someone had posted that he had done a verbose safe boot and had seen the hang happened while fsck was checking the disk. So I wanted to make safe boot skip this step to see if that allowed the safe boot to complete, and to see if that then cured the log message issue. I did this by replacing the fsck binary that is called as part of a safe boot with something else.

cd /sbin

Go to where the fsck_hfs binary is. I found this by doing 'which fsck' and then by knowing that fsck calls another binary specific to the type of filesystem that is being checked. OSX uses HFS, so I needed to disable fsck_hfs.

sudo mv fsck_hfs fsck_hfs_orig

Move it to a new filename so that we keep a copy.

sudo cp ~/true fsck_hfs

Put a new binary in it's place. This is a simple bit of code that just returns the value zero. This is what fsck does if the disk was OK. So here we are setting up a trick that makes the safe boot process think that the disk has been checked and it was OK.

For reference, the program was:

#include <stdlib.h>

int main( int argc, char* argv[] ) { return 0; }

Standard C code, compiled with gcc.

sudo chmod ugo+rx fsck_hfs

This changes the file permissions to match what they were set to for the real binary.

nvram boot-args="-x -v"

This sets some flags in non-volatile RAM that will cause the machine to always boot with a verbose safe boot until told to do otherwise.

reboot, log in

Reboot the machine to let the safe boot proceed with our trick binary and wait until everything has completed and we can log into the machine.

sudo nvram boot-args=""

Clear the flags that we set earlier so that we get a normal boot next time.

reboot

Get the machine back into the state that we normally have it in.

cd /sbin

sudo mv fsck_hfs_orig fsck_hfs

Clean up after ourselves by putting the original (working) binary for fsck into place.

Thanks Badger!

you're awesome

Thank you laughing_badger

For me too this was very instructive

alright, so if I understand, the following sequence should also work:

cd /sbin

sudo mv fsck_hfs fsck_hfs_orig

sudo cp -p /usr/bin/true fsck_hfs

nvram boot-args="-x -v"

reboot, log in

sudo nvram boot-args=""

reboot

cd /sbin

sudo mv fsck_hfs_orig fsck_hfs

Just in case: changing the boot-args is not strictly necessary to make your computer go through the safe boot process.

You could omit the 'nvram boot-args="-x -v"' command, restart your Mac and hold down any shift key until the safe boot process starts.

Note that with the 'fsck_hfs' command taken out of the picture, the safe boot process can finish very quickly, and you may not even see the grey progress bar which is normally a sign that a safe boot is underway.

Olaf Barthel wrote:

 

Note that with the 'fsck_hfs' command taken out of the picture, the safe boot process can finish very quickly, and you may not even see the grey progress bar which is normally a sign that a safe boot is underway.

This is useful to know because, yes, the boot process finishes very quickly and there is no really obvious way to know you're in safe mode.

I tried again with a new DIMM. If I have the 8 RAM slots in my MacPro 5.1 populated I can't start in safe mode because the boot process gets stuck at "checking extranded attributes file". If I remove on of the DIMM, I can safe boot without problems.

I can't understand it.

If your Mac is set up to require that you enter a password before you can use it, there will be a message in the top right corner of the login screen (in red) to notify you that safe boot is in effect.

I do not know if there is any similar hint message visible if your Mac is set up to log you in automatically.

Truth be told, I triggered safe boot three times in a row before I noticed the message and realized that the first attempt was successful after all.

My guess is that there is a bug in the code for fsck_hfs that is only triggered with large amounts of memory available, and in the specific memory layout that occurs in safe boot. The next step would be to get a debuggable version of the code and have the safe boot process drop into the debugger before it does the disk check. More work than I have the time to go into at present, sadly.

Many thanks badger on the great workaround for fsck. Works like a charm. You'd think a "safe" boot should be safer.

(Sadly, it didn't end up curing my mdimport / lsboxd bug that I have been trying to cure by doing a safe boot to begin with, but it was good to know how to get it to work.)

Fwiw, if it makes things easier for anyone, to make "true", all you need is this one line of code:

     int main(){}

If you save that as true.c, compile it like this:

     clang -o true true.c

(Clang knows to have the program return 0 by default. The import and the arguments to main aren't needed.)

It is simple enough if you have the software development tools installed

Simpler still is just copying the existing "true" command from "/usr/bin/true", like so:

     sudo cp -pn /usr/bin/true fsck_hfs

The "-pn" options make sure that the access rights to the command are preserved and that no existing file is overwritten (you need to move the original "fsck_hfs" command out of the way before you can plug in the dummy replacement).

In January I wrote:

> I may have a workaround but it's too early to disclose.

About the OS X Mountain Lion v10.8.3 Update does not mention safe boot, but safe boot began working for me whilst I tested a pre-release build of the update.

To any user of OS X 10.8.2 who can not boot in safe mode, please:

1) update to 10.8.3

2) let us know whether 10.8.3 resolves the bug for you.

If not resolved by 10.8.3, I'll offer my workaround.

Hello Graham,

unfortunately the released v.10.8.3 didn't solve this safe boot issue

Hi Graham, No progress for me either on 10.8.3. Stalls at the same step.

Hi Graham,

Seem here, installed 10.8.3, but safe boot still stalls.