El Cap 10.11.3 shipped a day or so ago, and I promptly installed on my Mac Pro. Often I counsel a day or two delay in such updates in case of problems, but in this case 10.11.2 was causing me such annoyance that I didn’t think it could get worse – I was badly hit by a bug which affected waking high-res screens from sleep.

Anyway, so far 11.3 seems OK. The monitor wake issue is fixed. Apparently the problem removing receipt files which was introduced in 11.2 is fixed, so that makes Munki happy again. And Mail.app has not obviously started using 150% CPU while sitting doing nothing. So that’s all good, and maybe it’s time to think about updating to El Cap if you haven’t already done so.

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!

Migration Assistant is one of those things which will either work perfectly (most of the time) and save you much effort, or else will fail in interesting and subtle manners and annoy the heck out of you until you fathom what it did wrong.

Most recently I was migrating someone from a 2007 iMac to a nice new 27″ 5K iMac – quite the update. I only migrated their user account – I tend to reinstall apps from scratch, especially with such a significant migration. All seemed OK at first, but a few issues came up:

• Google Drive would not sync – when double-clicking the App icon it would only open the sync directory, but not actually run
• Latexian could not export a PDF if it involved overwriting an existing file
• The Trash was not working – if you tried to drag something to it the only option was to delete immediately

The first problem turned out to be due to Google Drive having installed various things in ~/Library/Application Support/Google/Drive which were apparently out of date. Deleting this folder and re-running the Drive app sorted that problem out.

The second problem was more subtle, but turned out to be down to incorrect ownership of the user directory. While the username was the same for the new account, the userID number was different. It looks like Migration Assistant created the new account, gave it UID number 502, but created the home directory with the UID 503, which was the UID for the old Mac. All folders within the home directory had the correct ownership, so you were able to read/write properly below that, but nothing new could be created in the home folder, like the .Trashes/ folder. Once I figured this out a quick ‘sudo chown’ fixed things right up.

In summary, to paraphrase President Reagan, one may trust Migration Assistant, but always verify…

This message sponsored by Ming the Merciless…

An interesting story from Ars Technica. Hackers took control of a site which site authors use to inject anti-adblock code to their pages. They then injected code into the site which popped up a window telling users their Flash install was out of date, and offering a link to a download which was – of course – malware.

A few lessons from this –

• It’s still best to have no Flash installed, as then you know it’s a malicious popup
• I’m still going to run AdBlock to avoid compromises of ad servers
• I’m still going to remove Flash on any computer I see

Being a list of things which make me want to throw a computer out the window

• On my MacBook Mail.app got thoroughly confused, and was unable to send mail, change SMTP server, or edit the SMTP server list – the popup menu had several blank lines instead. In the end nuking ~/Library/Accounts/ (via another admin account) seemed to restore things, though I had to reconfigure all my accounts.
• On my Mac Pro the SMTP server settings were OK, but various other Mail settings were reset, such as loading remote images, default composing as Rich Text, turning on the Junk Mail filter… And ‘conversation view’ on one of my accounts is broken, but OK on the others.
  
• Command line printing to the MFD queues seems dead. While it seems merely vexing on older OS X releases (one has to manually authenticate each job) on El Cap it just hangs the print queue app. Since I’ve not used ‘lp’ in about 10 years I mostly missed this. Probably some sort of sandboxing or keychain thing; I filed a radar about it… [30/10 – this turned out to be a corrupted pref file on my Mac, the PrinterProxy.plist, though one still has to individually authenticate lpr jobs]
• (added 27/10) Time Machine does not work on desktop Macs connected to a UPS over USB. On MacBooks OS X does not run Time Machine when on battery power unless a checkbox in the TM preferences is checked. Looks like El Cap is assuming that the Mac is on permanent battery power, but of course does not reveal the option to tell it to back up anyway. Workaround – unplug the USB cable and do without auto-shutdown on power out.

More to be added as discovered.

With the release of El Capitan .1 last week I decided it was time to take the plunge and update. Everything on the Munki server side is now in place for the upgrade – to their credit Symantec were prompt to issue an update for SEP, and updates for other apps came out pretty quickly too. With the .1 update supposedly fixing the Office 2016 issues I figured it was time to move.

First I made sure I had good backups, using Time Machine and also Carbon Copy Cloner. Then I just ran the installer and let it do its thing. Afterwards I ran Managed Software Centre to update SEP, etc, and all seemed fine. Of course I’m now about 2 hours in, so there is plenty of time to regret this…

A few points to note

• The MacPorts update was very slow. I’m not sure of the cause but the self-update step took at least 10 minutes, which seems a lot. I don’t think this is an El Cap issue, just coincidental server slowness.
• GoodSync needs updates to quash various bugs.
• Anyone using GoodSync to backup their local mailboxes needs to note that under El Cap the local mailboxes have moved from ~/Library/Mail/V2/Mailboxes to ~/Library/Mail/V3/Mailboxes and update their backups accordingly.

I’ve still not done much with an actual install of El Capitan, though I have it on an old MacBook Pro for testing. I have been working on some back-end things to make sure that machines using my Munki service should upgrade OK, and I think I’m about there – a test install of Yosemite with packages like Symantec EndPoint, Latex, etc upgraded OK, though with various caveats.

• You need to be running MacTeX 2015 for a smooth update due to restrictions on what can be installed in the ‘unix’ directories under El Cap.
• Symantec had an update for SEP out within a few days, and that seems OK. On my Munki service I have set things so the update is only pushed to machines running El Cap as the previous version seems to be fine on Yosemite, and I don’t see the point in fixing what ain’t broke.
• MS Office 2016 seems to be badly broken, and according to Microsoft the fixes will be coming from Apple in an OS X update. How much this affects you depends on how much you use Office. Me – not at all.
• MacPorts has been updated and supports El Cap, though as always a reinstall of all ports is needed for a major OS update.
• IDL 8.5 seems to be OK, though it does not officially support El Cap.
• Ureka (IRAF) already explicitly supports El Cap in the latest release – 1.5.2.
• X11 seems OK under xquartz 2.77 but 2.78 seems close to release with some bug fixes.

At the moment I still don’t recommend installing El Cap on a ‘work’ machine which you can’t afford to lose. Maybe once 10.11.1 is out – though I have some new incoming Macs which I assume will ship with El Cap now, so they’ll be ‘volunteering’ to test.