Getting the diskutil command to work in OSX Mavericks Single User mode

I'm currently writing some single user mode maintenance scripts. My current goal is to be able to perform permission repairs and disk formatting using the diskutil command in Single User Mode. Performing this task in previous versions of OS X was a simple matter of mounting the root partition and launching the following launch daemons:

com.apple.diskmanagementd

com.apple.diskarbitrationd

After that, I only needed to run the following command to successfully repair permissions:

diskutil repairpermissions /

In Mavericks, however, this command no longer works and I can't figure out why. Running the diskutil command (even with no parameters) returns a simple and unhelpful message:

Killed: 9

I can't figure out what's going on here. In addition to the disk arbitration daemons that diskutil requires, my maintenance script also loads the following daemons:

com.apple.notifyd

com.apple.syslogd

com.apple.configd

com.apple.kuncd

com.apple.kextd

com.apple.KernelEventAgent

com.apple.distnoted.xpc.daemon

com.apple.aslmanager

com.apple.opendirectoryd

com.apple.coreservicesd

com.apple.securityd

com.apple.fseventsd

com.apple.cfprefsd.xpc.daemon

I get the same response whether I load all of the above daemons or just the two that were previously required for diskutil to operate. If I choose to boot from single user mode (by loading the entire contents of /System/Library/LaunchDaemons) I can use diskutil after the computer has finished its boot process.

Can someone more knowledgeable about the inner workings of the Mac OS possibly determine what's missing?

Alex Plumb

Posted 2014-01-07T20:14:41.780

Reputation: 1 616

Answers

I'm not sure what's causing the problem, but it doesn't seem to be a missing daemon -- I tried loading everything in /System/Library/LaunchDaemons except com.apple.WindowServer.plist, and it still failed the same way. It even fails just running diskutil, which normally just prints a usage summary. Also, "Killed: 9" suggests it isn't crashing itself, but something else (launchd?) is killing it.

Anyway, there is a bit of good news: diskutil repairpermissions is really just a front end for the repair_packages program, and that seems to run fine in single-user mode (even with no daemons at all loaded):

/usr/libexec/repair_packages --repair --standard-pkgs

Formatting disks will probably be more difficult. You may have to look at using gpt, newfs_hfs, and the like.

Gordon Davisson

Posted 2014-01-07T20:14:41.780

Reputation: 28 538

Awesome! Thanks a bunch. It looks like it's been repair_packages since 10.6. – Alex Plumb – 2014-01-13T14:17:46.227

By the way, do you have any idea how I would go about checking the SMART status from single user mode? The old way of doing this is diskutil info disk0 | grep SMART, but this no longer works. – Alex Plumb – 2014-01-13T15:15:40.780

No idea on SMART, sorry. That may be one diskutil does itself. – Gordon Davisson – 2014-01-13T16:16:16.450

-1

el capitan is now protecting permissions, even with your /usr/libexec/repair_packages --repair --standard-pkgs (thanks for it) it's not more possible to repair permissions - the file systems to repair are read only - any hint ? Best regards and thanks Martin

Martin Rass

Posted 2014-01-07T20:14:41.780

Reputation: 1

I found something - perhaps working with disable system protection – Martin Rass – 2015-10-31T16:45:02.593

You can easily disable SIP with csrutil disable in Recovery mode – TheBro21 – 2016-08-03T20:54:36.187