Re: Non-interactive run of `freebsd-update upgrade` possible?

On Thu, Jul 31, 2025 at 03:31:51PM +0200 I heard the voice of
Ronald Klop, and lo! it spake thus:
> Van: "Patrick M. Hausen" <hausen@punkt.de>
> > 
> > It's time to upgrade our ~100 hosts - again - and I would really
> > like to at least partly automate the procedure.
> > 
> > Current issue is that this sequence:
> > 
> >     freebsd-update upgrade -r 14.3 -b /tmp/be_mount.EkJx
> >     freebsd-update install -b /tmp/be_mount.EkJx
> >     freebsd-update install -b /tmp/be_mount.EkJx
> > 
> > in my experience insists on asking "Does this look reasonable? (y/n)"
> > interactively.
>
> Did you check freebsd-rustdate from ports/pkg? [...]

As the author, I am clearly completely unbiased, so my agreement with
such a suggestion is definitely a reliable argument-winner.  Ahem.
With that out of the way...

freebsd-rustdate certainly _should_ do what you need, and I don't know
any reason it wouldn't.  It does work against all the same servers and
data as freebsd-update.  It uses the same config (at least the bits it
supports).  It also shares file storage (i.e., the stuff in
/var/db/freebsd-update/files/), so one would see the files the other
had downloaded.  It doesn't share state, so one wouldn't see any
pending updates to `install` from the other.


A few notes for what seems to be your situation:

- Non-interactivity was specifically a goal in the implementation.
  Obviously things like resolving conflicts need interaction, but
  that's part of why they're moved to a separate command; the basic
  fetch/upgrade/install commands don't take any interaction to run to
  completion.

- The `install` command defaults to being very conservative; like
  freebsd-update, it installs one file at a time, and fsync()'s
  everything before moving on.  That can take a while.  If you're
  installing into something that's not the running system (like a new
  not-yet-active BE, or a subdir or jail or something), you can afford
  a little risk if the system crashes in the middle, so you could use

  - `install -s` to disable fsync(), which wastes way less time along
    the way,

  - `install -j` to use all those cores (and non-5400-rpm hard drive
    IOPS) that are just lying around, which can hide the fsync()
    delays as well, or

  - `install -sj` to get both.

  - (me, I tend to eat the risk even on live systems...)

- Also, the `install` command has a `-a` argument to do all the
  potentially 3 steps (kernel, world, rm old libs) at once instead of
  taking multiple invocations.

- Note that general arguments like `-b` are arguments to the base
  command, not the subcommand, so you'd be doing things like

    % freebsd-rustdate -b /tmp/bs_mount.EkJx upgrade -r 14.3-RELEASE


The program has reasonable --help bits through the various commands.
The webpage has longer docs for the commands, some stuff about
differences from freebsd-update, and whatever other blathering I did
at the time.  And I'm certainly happy to give any help I can.


-- 
Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.