diskutil in Single-user mode
 

Howdy folks,
I've been racking my brains and searching every forum I come across to get an answer here, but haven't found one yet. Either I'm not typing my search criteria correctly, or it just hasn't been posted yet.

I'm attempting to run diskutil via a single-user boot in OS 10.4.8
I don't know all that much about running command scripts in a Unix shell, but here's where I am:

/sbin/fsck -fy
.....
/sbin/mount -uw /
(returns localhost... starting line)
diskutil list /
(does nothing. Nor do any other diskutil commands. Also have tried with "/sbin/" and "/usr/sbin/")

I've booted into single user mode and run fsck; everything is fine and no changes were made. I've figured that I have to mount the drive in read/write mode but am stuck after that. I know that the following command works in 10.3... but it does not in 10.4:
/usr/libexec/register_mach_bootstrap_servers /etc/mach_init.d

I suppose what I'm asking for are the precise command lines that I need to run in order to get diskutil up and running in single-user mode. I had imagined this would be a simple matter... though it's proving to be quite frustrating.

Thank you!

Probably because things that diskutil are dependant upon aren't loaded.

Of course, these instructions are for 10.3, so who knows what has changed in 10.4:

http://www.afp548.com/article.php?st...04080413321761

Life has gotten easier in "Tiger" - it says so among the prompts that appear in single user mode, but after 'fsck' and 'mount', you can continue to boot the system but stay in single user mode using:Off topic, but NetInfo is up and running after this as well so you don't have to work in "raw" mode.

Well, that boots into aqua.... and I did get that far before... but it just sits and won't let me enter or edit anything. All I have is the mouse pointer.

What exactly are you trying to do? I.e. what is your higher-level goal?
If you just want to mount a drive, you can do it with: 'mount'
See for example, this older thread:
http://forums.macosxhints.com/showthread.php?t=22516
and this macosxhints article:
http://www.macosxhints.com/article.p...30714194313542

My end-goal is to get diskutil to run in Single-user mode in OS 10.4

You are either being obtuse or deliberately uncooperative.
Note that I asked what is your higher-level goal?
If it's just idle curiosity, then you can stop wasting our time.

Excuse me for being obtuse. I had *thought* that getting diskutil and it's processes to run was enough of a higher-level goal; but I guess not. I am trying to repair disk permissions in single-user mode. In order to do that, I have to get diskutil to run. In order to do THAT, I understand that I have to mount the drive and launch certain processes. I do not know which need to be launched or how to launch them.
And excuse me for I believe I am about to over-step my bounds, but what is the point of a HELP forum for UNIX NEWCOMERS if the moderator is going to become impatient when there is miscommunication between someone who is NEW to the subject matter, and someone who is knowledgeable?

Sorry if you merely didn't understand what I meant by a "higher-level" goal but I would have thought it was clear when I asked you what you were trying to accomplish.
I get impatient if someone doesn't respond to requests for clarification when asking for help.

It isn't usual to run 'diskutil' in single-user mode. My instructions for doing so date from the Panther era and originate from that AFP page that yellow referred to above. I have no idea how to do it if that method doesn't work.

But before going much further, let me ask why you want to repair permissions from single-user mode?
What problem are you trying to solve? Maybe there is another solution.

That sounds like what happens when 'sh /etc/rc' is executed on a system running "Panther", in which case the afp548 instructions linked to by yellow can be used.

I was worried enough about having provided out of date advice that I rebooted to test the command under 10.4.8 (I know it worked under 10.4.7 but hadn't tried yet since the update).

For the record, 'diskutil' will definitely run in single user mode after running 'sh /etc/rc', at least on a functional 10.4.8 PPC system.

To cut it a little finer, this (which is alluded to in '/etc/rc') also works, again on a normal system:But that's about as far as I want to take it at this time.

Thank you. I know it's not usual to run diskutil that way, but I figured that it could be done since fsck is a simple command. I didn't realize that fsck is something that runs standard in basically any Unix/Linux shell, and diskutil is an Apple creation.
That said, my goal was to run diskutility without the OS CD or DVD. I know you can run straight DiskUtility in Tiger, but it seems that it does a more complete repair when it's booted from the CD. I had looked into creating a minimum boot image on a flash-drive, but that seemed like more work than it was worth. I had thought that running diskutil in Single-user mode would function like "fsck" and would allow for a more complete repair than in a normal boot of Tiger, and would work in a jam if I didn't have the CD.
Now, it looks like that option is less and less of a practical solution.

I believe you can repair your permissions wtihout entering single-user mode.

If you run this from Terminal.app, enter an administrators password at the prompt, it should do it's thing. Is there any particular reason that you want this done from single-user mode?

Thanks biovizer. But what about on an intel mac? Is the kernel different enough that the commands will be different?

That isn't really the issue. It is more that 'diskutil' is a higher-level utility that bridges the low-level Unix commands and the GUI and thus requires more infrastructure.

I think you are confused about what Disk Utility does. It has two "repair" procedures - "Repair Disk" and "Repair Disk Permissions". These are completely unrelated.
The former just invokes 'fsck' behind the scenes and so there is nothing needed to be done to get that functionality in single-user mode.
The latter compares the permissions of certain selected application files with what is recorded in the files under /Library/Receipts and does 'chown' and 'chmod' to make them accord.
This latter operation is much overrated - it is not usually all that useful except in certain unusual cases.

But more importantly, there is no need to do the latter operation when booted from the Install CD/DVD - you can do it equally well with Disk Utility when booted normally.

It is only the "Repair Disk" which requires booting from the CD/DVD and this (as I've said above) just does 'fsck' so there's no big trick to doing it from single-user mode. In fact this is explained in this Apple doc:
http://docs.info.apple.com/article.html?artnum=106214

Bottom line: had you explained your high-level goal at the beginning of this thread, we could all have saved some time.

As I've said above, repairing permissions is a relatively straightforward (and not usually very useful) procedure that has nothing to do with the kernel or anything else at low-level.

See this article if you want more details on permission repair:
http://forums.macosxhints.com/showthread.php?t=59155

Thank you for all your input and help.
In my case, repairing permissions is helpful, and necessary on an almost daily basis.
I'm stuck testing and using beta software for my company that tends to mess with permissions and make the OS buggy. If I don't run Disk Utility every so often, certain programs stop opening when I launch them, processes lag and the computer freezes up, and then I get Kernel Panic errors.
Booting off of the OS Disc and running DiskUtility has corrected the errors in every case. I've also attempted to run Disk repair (fsck) rather than the permissions repair, but it has no (or negligible) effect.

So, I understand that permissions repair may not be helpful in every case, but it is in mine.
And again, thank you all very much for your help.

When you boot from the Install CD/DVD, you run "Repair Disk Permissions" ?
(as opposed to "Repair Disk")
There shouldn't be any difference in running that when booted from the CD/DVD and when booted normally.
And in either case, it is very mysterious that it fixes something that could cause a kernel panic.
I think it is much more likely that it is something else incidental to this process that is actually fixing your problem.

Have you looked at the log of what permission repairs are done when you do "Repair Disk Permissions" ? Which files are getting their permissions changed?

I'd really like to understand how permission repair could be fixing the sort of problems you mention.

I don't know how it fixes it, all that I know is once I run a permissions repair (this is the kicker) from the Install Disk (doesn't always solve the problem running DiskUtility booted normally) the programs that wouldn't launch previously seem fine, applications stop quitting randomly, the system runs more smoothly and quickly, and I don't get kernel panics.
I don't have repair log on hand, but I'll keep it and post it the next time I run a permissions repair if you'd like.

And so I'm up on my information here, if a Permissions Repair shouldn't be able to fix a Kernel panic, what should? Disk Repair?

Yes - since the kernel is just a software program which is stored on disk like everything else, any corruption in the filesystem might have corrupted the kernel itself. But in addition to that, the kernel (and all other programs) rely on the data received from the filesystem. If that data is corrupted, then all bets are off. A kernel panic is merely the kernel saying "this is something unexpected - I don't know how to deal with this". The kernel expects that it can rely on the filesystem.

The permissions on files are something that the kernel is completely unaffected by. Permissions only apply to "user processes" - i.e. the other programs that run on the computer.
For the kernel to be shutdown by incorrect permissions would be like the government being shutdown because you mistyped your ID number on some form.

AppleJack


It can... but it runs like a dog (a slow one).

It's not Applejack's fault... if/when we do a
diskutil repairPermissions in SU mode, the
same slowness will be seen (an OSX bug?).

But why do it manually anyway? You could
set up a bash script, to be run by launchd.

-HI-

I just want to add that repairing permissions w/ the repair permissions utility resets the file permissions to what apple thinks is a good default. This may not fix a problem if you need to set specific persmissions. It can however, reset permissions back to default and you can reapply them later, like with a script or something.