>>> 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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
