Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Sep 2023 10:56:53 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Chris <bsd-lists@bsdforge.com>
Cc:        Guido Falsi <mad@madpilot.net>, Jason Bacon <bacon4000@gmail.com>,  FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: Single-user actions on reboot
Message-ID:  <CANCZdfqRzxGHLUZ7RvWc0F4tKtFV6gm-Dkj9ykQOS_EqU4_j2A@mail.gmail.com>
In-Reply-To: <e5a3b651c3e1e6f74b8114ce8822c929@bsdforge.com>
References:  <b70d24e3-ce25-f2fb-1f0f-9526f16173b0@gmail.com> <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> <e5a3b651c3e1e6f74b8114ce8822c929@bsdforge.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000006c24970606825050
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 29, 2023, 10:12 AM Chris <bsd-lists@bsdforge.com> wrote:

> On 2023-09-29 06:49, Guido Falsi wrote:
> > On 29/09/23 15:21, Jason Bacon wrote:
> >>
> >> I'm wondering if there's a canonical way to schedule a command to run
> >> automatically during the next boot cycle, but before going multiuser.
> >>
> >> This would be useful, for example, to run certain tunefs commands on /,
> >> which can only be done in single-user mode, on remotely managed systems.
> >>
> >> Running things after going multiuser is easy, of course, but not
> sufficient
> >> for tunefs commands that cannot be performed on a filesystem mounted rw.
> >>
> >> Thanks...
> >>
> >
> > AFAIK there is no ready made tool in base (or ports) for that.
> >
> > But ezjail uses this trick with rc scripts (removing itself):
> >
> >
> https://erdgeist.org/gitweb/ezjail/tree/examples/example/etc/rc.d/ezjail.flavour.example
> >
> > This is effective but requires the disk mounted r/w which maybe is not
> > enough for you.
> >
> > Problem is, without any writable media mounted, how can any script
> register
> > it has
> > already ran?
> >
> > One idea that comes to mind is adding some hook to the main rc script,
> > before
> > mounting disk r/w, and a second script that removes existing hooks once
> > disks are
> > r/w.
> Indeed. Maybe at the same point the system tastes the disk(s) to see if
> they've been dismounted
> properly and then running fsck(8) if not. Using the same method to perform
> your task(s)?
>

At work we just have a custom rc script to do that for all our content
disks (only os disks are in fstab).

As for writable media... you could set a uefi variable... or create a small
MD partition (call it /once) that an rc script in a later phase could use
to mop up and then free. The latter is easier, but in many environments the
former is more durable and reliable if there's an early crash that happens
before mopup and you can really only run something once...

Warner

>

--0000000000006c24970606825050
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Fri, Sep 29, 2023, 10:12 AM Chris &lt;<a href=3D"ma=
ilto:bsd-lists@bsdforge.com">bsd-lists@bsdforge.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">On 2023-09-29 06:49, Guido Falsi wrote:<br>
&gt; On 29/09/23 15:21, Jason Bacon wrote:<br>
&gt;&gt; <br>
&gt;&gt; I&#39;m wondering if there&#39;s a canonical way to schedule a com=
mand to run <br>
&gt;&gt; automatically during the next boot cycle, but before going multius=
er.<br>
&gt;&gt; <br>
&gt;&gt; This would be useful, for example, to run certain tunefs commands =
on /, <br>
&gt;&gt; which can only be done in single-user mode, on remotely managed sy=
stems.<br>
&gt;&gt; <br>
&gt;&gt; Running things after going multiuser is easy, of course, but not s=
ufficient <br>
&gt;&gt; for tunefs commands that cannot be performed on a filesystem mount=
ed rw.<br>
&gt;&gt; <br>
&gt;&gt; Thanks...<br>
&gt;&gt; <br>
&gt; <br>
&gt; AFAIK there is no ready made tool in base (or ports) for that.<br>
&gt; <br>
&gt; But ezjail uses this trick with rc scripts (removing itself):<br>
&gt; <br>
&gt; <a href=3D"https://erdgeist.org/gitweb/ezjail/tree/examples/example/et=
c/rc.d/ezjail.flavour.example" rel=3D"noreferrer noreferrer" target=3D"_bla=
nk">https://erdgeist.org/gitweb/ezjail/tree/examples/example/etc/rc.d/ezjai=
l.flavour.example</a><br>
&gt; <br>
&gt; This is effective but requires the disk mounted r/w which maybe is not=
 <br>
&gt; enough for you.<br>
&gt; <br>
&gt; Problem is, without any writable media mounted, how can any script reg=
ister <br>
&gt; it has<br>
&gt; already ran?<br>
&gt; <br>
&gt; One idea that comes to mind is adding some hook to the main rc script,=
 <br>
&gt; before<br>
&gt; mounting disk r/w, and a second script that removes existing hooks onc=
e <br>
&gt; disks are<br>
&gt; r/w.<br>
Indeed. Maybe at the same point the system tastes the disk(s) to see if <br=
>
they&#39;ve been dismounted<br>
properly and then running fsck(8) if not. Using the same method to perform =
<br>
your task(s)?<br></blockquote></div></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">At work we just have a custom rc script to do that for all our=
 content disks (only os disks are in fstab).</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">As for writable media... you could set a uefi variable=
... or create a small MD partition (call it /once) that an rc script in a l=
ater phase could use to mop up and then free. The latter is easier, but in =
many environments the former is more durable and reliable if there&#39;s an=
 early crash that happens before mopup and you can really only run somethin=
g once...</div><div dir=3D"auto"><br></div><div dir=3D"auto">Warner</div><d=
iv dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
/blockquote></div></div><div dir=3D"auto"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
</blockquote></div></div></div>

--0000000000006c24970606825050--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqRzxGHLUZ7RvWc0F4tKtFV6gm-Dkj9ykQOS_EqU4_j2A>