From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 08:58:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5939226; Tue, 15 Oct 2013 08:58:57 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from vps.van-laarhoven.org (www.hibma.org [IPv6:2a02:2308::216:3eff:feec:b1b5]) by mx1.freebsd.org (Postfix) with ESMTP id 845532E27; Tue, 15 Oct 2013 08:58:57 +0000 (UTC) Received: from [IPv6:2001:980:530a:1:ad2b:26d6:5b53:cd53] (unknown [IPv6:2001:980:530a:1:ad2b:26d6:5b53:cd53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by vps.van-laarhoven.org (Postfix) with ESMTPSA id D20C95F2647; Tue, 15 Oct 2013 10:54:56 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: RFC: support for "first boot" rc.d scripts From: Nick Hibma In-Reply-To: <525C41D1.3040204@freebsd.org> Date: Tue, 15 Oct 2013 10:58:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C7D69EB-204B-45B9-AD67-EBC1AB39AB8B@van-laarhoven.org> References: <525B258F.3030403@freebsd.org> <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> <525C210A.2000306@freebsd.org> <1381770007.42859.82.camel@revolution.hippie.lan> <525C41D1.3040204@freebsd.org> To: Colin Percival X-Mailer: Apple Mail (2.1510) Cc: FreeBSD current , freebsd-rc@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:58:57 -0000 >>> 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... >>=20 >> 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). >=20 > 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=20 test -f /firstboot && bla_enable=3D'YES' || bla_enable=3D'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=