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.
