Leopard: What happened to /etc/rc and `id`?

[klktrk]

While doing some testing on a new install of Leopard Server, I noticed a couple big under the hood changes:
1) no /etc/rc: Where does the OS set the location of VM swap file now?
2) If you try to run the id(1) command in single user mode, well… you can’t. There go a whole slew of shell scripts I used to use.

My primary concerns are startup config (where the heck to I set the swap file location now?), and what I can use to replace my trusty old calls to id with.

Any insight? As usual, I’m not finding much (read ANY) docs on this on Apple knowledge base.

[erschmitt]

I too would like to know how to have more control of the system from SUM in leopard. All kinds of fancy utilities I used to run from it are no longer accessible

[klktrk]

In the meantime, I’ve learned the following:

The location of the vm (swap directory) can be read here:
(array) = defaults read /Syste/Library/LaunchDaemons/com.apple.dynamic_pager ProgramArguments

The id utility fails with a “bus error” when run with no parameters. However, if you run it with id -n or id -un, it works. Odd. Gotta love it.

So some of the basic re-jiggering has been solved, but I’ve got a long way to go.

I wish I wish I wish Apple would document their changes, but judging from the last decade or two, that’s never going to happen.

[khiltd]

It’s not much documentation, but it’s documentation nonetheless:

[code]Prior to Mac OS X 10.5, the rc script was used to bootstrap the OS. As of Leop-
ard, the system is self-bootstrapped via launchd(8) which uses the launchctl(1)
bootstrap subcommand to read in launchd jobs from the standard locations. For
compatibility reasons, the rc.local script still continues to work.[/code]

Inspection of the launchctl sources confirms that it’s calling most of the shots these days.

[klktrk]

[QUOTE][u]Quote by: khiltd[/u][p]It’s not much documentation, but it’s documentation nonetheless:

[code]Prior to Mac OS X 10.5, the rc script was used to bootstrap the OS. As of Leop-
ard, the system is self-bootstrapped via launchd(8) which uses the launchctl(1)
bootstrap subcommand to read in launchd jobs from the standard locations. For
compatibility reasons, the rc.local script still continues to work.[/code]

Inspection of the launchctl sources confirms that it’s calling most of the shots these days. [/p][/QUOTE]

Yes, it does appear that launchctl is doing 90% of the work now, which is great. What is harder to determine is what daemons need to be launched in order to get diskutil or dscl working,without loading the whole kit and kaboodle.

I think I’m left to a trial and error on that one.

[khiltd]

[QUOTE][u]Quote by: klktrk[/u]I think I’m left to a trial and error on that one.[/p][/QUOTE]

I’ve tried (I think) every permutation of the undocumented “bootstrap” subcommand and that’s definitely not a good idea. Seems to fire everything up and leave you stuck with no login window.

For diskutil and dscl I imagine you’d want to start with /System/Library/LaunchDaemons/com.apple.diskarbitrationd.pllist and /System/Library/LaunchDaemons/com.apple.DirectoryServicesLocal.pllist and see how far you get.

[klktrk]

[QUOTE][u]Quote by: khiltd[/u]

I’ve tried (I think) every permutation of the undocumented “bootstrap” subcommand and that’s definitely not a good idea. Seems to fire everything up and leave you stuck with no login window. [/QUOTE]
Yes, my experience exactly. I’m trying to pare down what is needed in order to be able to use some basic utilities in SUM, especially because using the bootstrap is a sure road to hanging computer hell.

[QUOTE]For diskutil and dscl I imagine you’d want to start with /System/Library/LaunchDaemons/com.apple.diskarbitrationd.pllist and /System/Library/LaunchDaemons/com.apple.DirectoryServicesLocal.pllist and see how far you get. [/p][/QUOTE]

Yeah, I enabled diskabritation, and that helped me get from using diskutil with a user-friendly “can’t use that, sorry” message to diskutil now sullenly just hanging. I’ll add the directory services and see how far i get.

it’s the interdependencies that kill me.

[khiltd]

Might also want to run otool over the binaries and see what they each link against–could turn up some helpful clues.

There’s also the boot-dev and launchd-dev mailing lists, though I’m not sure how forthcoming one can expect any of the participating engineers to be.

[khiltd]

Some useful and otherwise unavailable information on the subject of launchd “sessions” from the list:

[quote]On Nov 29, 2007, at 5:14 PM, Kevin Van Vechten wrote:

Here’s a summary of sessions:

– LaunchDaemons are only loaded into the “System” session of the root launchd. No per-user launchd has a “System” session.
– Unless otherwise specified by the LimitLoadToSessionType key in the plist, LaunchAgents are loaded into the “Aqua” session.

– The “Aqua” session is the same session all GUI Applications are executed in.
– Logins via SSH, telnet, and others are executed in a “StandardIO” session.
– Each user is given a single “Background” session. Jobs in the “Background” session may live longer than the last logout of the user.[/quote]

[Coco]

Can anyone tell me what the undocumented bootstrap subcommand is? I need to get a command line boot going with at least network running, but I don’t want a gui starting. Any help would be greatly appreciated.

[khiltd]

It’s in the sources, and I wouldn’t recommend using it for that purpose as it definitely kicks off the GUI in addition to leaving it hanging in a completely unusable state.

[Coco]

Sorry, I’m confused by it’s in the sources. I would really like to give this a try. Can you please tell me how. If it hangs on me, then I know I have exhausted this route too.

[Coco]

I had a cool trick under Tiger for imaging new machines. On first boot the machine would obviously enter the Setup Assistant, and so the only practical way to image them was to have them on the same subnet as your netboot server to hold down the N key. Under Tiger I could kickstart the etc/rc script, and as it brought up the network there was just enough time to curl down a remote script that blasted the nvram to reboot and remotely netboot from an imaging server. Now under Leopard the script is gone, and I can’t seem to figure out how to kickstart the network to be able to curl down the script. Obviously with wanting to do this to brand new, out-of-the-box machines, I don’t have any extra options to play with in terms of adding things to the machine. Any help would be greatly appreciated! Thanks

[khiltd]

[QUOTE][u]Quote by: macshome[/u][p]So what is it that people are trying to accomplish here?[/p][/QUOTE]

I believe we’re trying to get AppleJack Leopard compatible so we can reduce the number of hours we have to sit there rebooting machines ad infinitum.

[Author]

Posts