Re: RFC: support for "first boot" rc.d scripts

>>> Yes, it's hard to store state on diskless systems... but I figured
>>> that anyone building a diskless system would know to not create a
>>> "run firstboot scripts" marker.  And not all embedded systems are
>>> diskless...
>> 
>> The embedded systems we create at $work have readonly root and mfs /var,
>> but we do have writable storage on another filesystem.  It would work
>> for us (not that we need this feature right now) if there were an rcvar
>> that pointed to the marker file.  Of course to make it work, something
>> would have to get the alternate filesystem mounted early enough to be
>> useful (that is something we do already with a custom rc script).
> 
> Indeed... the way my patch currently does things, it looks for the
> firstboot sentinel at the start of /etc/rc, which means it *has* to
> be on /.  Making the path an rcvar is a good idea (updated patch
> attached) but we still need some way to re-probe for that file after
> mounting extra filesystems.

In many cases a simple 

	test -f /firstboot && bla_enable='YES' || bla_enable='NO'
	rm -f /firstboot

in your specific rc.d script would suffice. Or for installing packages:

	for pkg in $PKGS; do
		if ! pkg_info $pkg-'[0-9]*' >/dev/null 2>&1; then
			pkg_add /some/dir/$pkg.txz
		fi
	done

I am not quite sure why we need /firstboot handling in /etc/rc.

Perhaps it is a better idea to make this more generic, to move the rc.d script containing a 'runonce' keyword to a subdirectory as the last step in rc (or make that an rc.d script in itself!). That way you could consider moving it back if you need to re-run it. Or have an rc.d script setup something like a database after installing a package by creating a rc.d runonce script.

Default dir could be ./run-once relative to the rc.d dir it is in, configurable through runonce_directory .

Note: The move would need to be done at the very end of rc.d to prevent rcorder returning a different ordering and skipping scripts because of that.

Nick