Until recently, it was possible to put arbitrary code into /etc/ rc.server to perform scripted maintenance activities in the early boot context (i.e., system disk still write-only, limited driver access, etc). In the version distributed with 10.5.7, rc.server shows up later in the sequence (i.e., system disk mounted read-write). In any case, adding code to rc.server always was a kludge. Now, the cleanest way to do it seems to be to put code into /.env and use "nvram boot-args=-s ; reboot" to run it. This is actually a much cooler kludge, because /.env (the value of ENV in single-user mode) is normally run only in single-user mode, because otherwise the HOME variable will be set, and for root that will cause ENV normally to be defined as /var/root/.env. Because /.env only gets run in single-user mode, you can put in fairly elaborate checks to make sure you're in in the right place without negatively impacting startup time for normal root shell scripts. But I'm concerned that this method, like rc.server, will someday be seen by the launchd developers as a bug (that is, HOME not being defined in single-user mode); in this case, it too will suddenly disappear and some other kludge will have to be found. So what I'm wondering is whether it might not be a good idea to provide a conventional hook for early-boot maintenance. It could simply be a shell script in a standard location such as /etc/ rc.earlyboot which gets executed by launchd if present, owned by root, and not writable except by root. This would keep people who insist on doing this kind of thing from having to keep finding new and better kludges. Or, of course, the /.env thing and the HOME-less single-user shell could become a feature of launchd that is reserved for this purpose. Thank you, Greg Shenaut