I’m publishing this post in the hope that it’s helpful to someone Googling for help. Obviously you should exercise caution when you read anything on the internet, and this involves running your Mac in single-user mode and using the command line. If you’re not comfortable with this then ask someone to assist you. And if this causes your computer to explode then don’t blame me – anyway, you have a backup, yes?

I’ve seen numerous Macs running Yosemite encounter a situation where, for some reason or other, they need a forced reboot but then refuse to start up properly afterwards. Typically this ends up needing an OS reinstall to fix, despite everything appearing to be OK.

The typical sequence of events is that the Mac ‘goes bad’ for some reason or other, and gets powered off forcibly. On reboot things progress OK until the login sequence hangs with the progress bar around 1/3 the way along, generally freezing just after the mouse pointer becomes visible in the top left corner of the screen. The mouse can be moved around, but the machine is never booting, no matter how long it takes.

When booted to recovery mode all checks out OK. The machine can boot in single user mode too and nothing is obviously wrong, though the system logs in /var/log/system.log show rapid turnover and are full of errors about launchd tasks such as mDNSresponder failing to start due to “file or directory not found” errors. However the files in question are all there when one types ‘ls’.

Typically at this point one just gives up and reinstalls OS X, which is thankfully relatively straightforward these days. However today I was poking about some more, and worked out that the problem (for at least this Mac) was not that the files were not present, but that they were not accessible for the daemon users trying to run them – it turned out that the Unix permissions on the root partition were wrong.

The Unix permissions for root portion (/) in OS X should be 755 – or rwxr-xr-x – which means root can read/write/execute and group/other users can only read/execute. For whatever reason – maybe a bad remount after the forced shutdown – the execute bits were no longer set on this machine, so only processes running as root could access the drive properly. Since OS X tries to run most daemons as non-root users, they kept failing and booting stalled. All I had to do was chmod the root partition back to its proper settings and all was well again. To do this

• Boot the Mac in single user mode – hold Command-S at boot until the screen turns into a black background with white text scrolling past
• Make the hard drive writable by typing
  • fsck -fy
  • mount -uw /
• Check the permissions on the root (/) mount by typing
  • ls -ld /
• If the start of the line this command displays is not drwxr-xr-x then type
  • chmod 755 /
• Finally type exit and press return to restart the machine

Hopefully at this point the Mac will reboot and start up properly. Obviously if the permissions on the root partition are drwxr-xr-x already then you have a different problem…

I’m still not having fun with El Capitan, even after 10.11.2 shipped.

First problem – for people who upgrade from 10.10 and earlier using the App Store installer, the contents of /var/db/receipts/ are deleted – this means that Munki, and any other program which depends on installer receipts to keep track of installed software, decides nothing is installed and wants to reinstall everything. This is tedious, but not terminal, I guess. The problem does not arise when updating an existing 10.11 install to 10.11.2, at least.

Second problem – and one which is directly affecting me and is therefore a crisis – is that detection of multiple displays seems flaky. I have a Mac Pro (trashcan model) with two external displays. While I’ve had intermittent issues with display detection, after applying 10.11.2 it’s been hideous – generally only one display will detect reliably, though if I power everything down and up again maybe it will work after a half hour of cable shuffling. Most vexing. Only way around it at the moment seems to be not letting screens go to sleep once they’re working, which is hardly satisfying.

At the moment I think that if Yosemite is working out OK for you, stay there!