From nobody Fri Sep 29 16:56:53 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RxxN36Mlkz4v8mQ for ; Fri, 29 Sep 2023 16:57:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RxxN33wmcz4YRH for ; Fri, 29 Sep 2023 16:57:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-9b1ebc80d0aso1616485266b.0 for ; Fri, 29 Sep 2023 09:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1696006625; x=1696611425; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hC3GDWerFUjciRrEfdX170r37i2w4zEUdUxtbnHfSXc=; b=v/VgSZRHJs64V4RRLH3Av0sF0HwGLiY7tfIWcG6HSSRhgG3OmCOAOQf0ZsOJhBAN9F +H5pg0ImDl55bkST04Lf8DFZIYgBC+7FXOYB84vPBIu22tkZh2+O/YD2+aHDhTjWfIsG tVLztfeAHxIXlRsvmA+0eY78VQJ4Hu35smX0cJAatYGKG2HPrCsxA7zuR0BZahT1+jKq LgHqxOOGoLrzl7P5Fd1tI27yRwxo9rC3Iqv3wQzKP9G/KcDw8X7HXKl5+grQSJUZCL4j QnytQ/oXc+mr9COenwBmSeuxoqGgkkl1nlQXuWmVyZbEwazB7Xzl6TVTbunm+QTjpf04 fGdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696006625; x=1696611425; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hC3GDWerFUjciRrEfdX170r37i2w4zEUdUxtbnHfSXc=; b=lpMfKz8lhMNlQUOxwh7te2ScwPBrIUiMf39NX1BR0wW4gaImKLhNX1Zot1Wtms/lT6 1zDa7HDB+RS8ge5GohWHQWurow2jesuzXljyqptmSgfGQEQH/dra8SfOkG+h7XDw25BN ne/whaRFURta4RXPbzoqrrzHYr3b8V/poJ91XfCPUxmIcHP+IGNauUhaCwksYBJulMWc 4WWFcPTShE8HeDZilnlX6Sg04w5dOYIu4PcDCIXZ8T8hvd1WYF/Uoh/TFE+SFzpFdTOw ebaq9lLE8+0O1ZZ64V2WBm2z+5Vqsnb1Og8zzT1i+jvswBxZRSHMCKwg3kAUGLW3o0vf xIUg== X-Gm-Message-State: AOJu0Yw597n3tRKiiijCW3k4yIDlK5a5KL1yJMr0Ki7z27TO5PT2kWid ViRzw/9BOpZRDzF/FuGmNV79f9C+bTkRJ8if2I/Img== X-Google-Smtp-Source: AGHT+IFQNFfUrhflO2/5gyjdox8b5Sr9sI4tdU6mYG3GWg8PzHxNtpW/KyEFq5dv+NER1rwvHVhn7QbJTrV7O+nawuM= X-Received: by 2002:a17:907:7859:b0:9ad:78b7:29ea with SMTP id lb25-20020a170907785900b009ad78b729eamr4302846ejc.44.1696006625037; Fri, 29 Sep 2023 09:57:05 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> In-Reply-To: From: Warner Losh Date: Fri, 29 Sep 2023 10:56:53 -0600 Message-ID: Subject: Re: Single-user actions on reboot To: Chris Cc: Guido Falsi , Jason Bacon , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000006c24970606825050" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4RxxN33wmcz4YRH --0000000000006c24970606825050 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 29, 2023, 10:12 AM Chris 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


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 com= mand to run
>> automatically during the next boot cycle, but before going multius= er.
>>
>> This would be useful, for example, to run certain tunefs commands = on /,
>> which can only be done in single-user mode, on remotely managed sy= stems.
>>
>> Running things after going multiuser is easy, of course, but not s= ufficient
>> for tunefs commands that cannot be performed on a filesystem mount= ed 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/ezjai= l.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 reg= ister
> 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 onc= e
> 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 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's an= early crash that happens before mopup and you can really only run somethin= g once...

Warner
<= /blockquote>
--0000000000006c24970606825050--