Page MenuHomeFreeBSD

freebsd-update: Error for -b basedir without UNAME_r set
ClosedPublic

Authored by emaste on Dec 10 2024, 1:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 7 2026, 10:08 PM
Unknown Object (File)
Dec 26 2025, 1:30 PM
Unknown Object (File)
Nov 19 2025, 5:53 AM
Unknown Object (File)
Nov 10 2025, 11:19 PM
Unknown Object (File)
Nov 8 2025, 2:38 AM
Unknown Object (File)
Nov 6 2025, 5:36 PM
Unknown Object (File)
Nov 6 2025, 4:20 AM
Unknown Object (File)
Nov 5 2025, 9:36 PM

Details

Summary
freebsd-update sets the currently running release from UNAME -r, which
can be overridden via the --currently-running commandline option (or by
setting UNAME_r in the environment).  This is not valid if -b is used to
specify a basedir other than /, so error out if -b is specified without
setting the currently running version.

PR:             283229

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

emaste created this revision.

seems reasonable to me, but we should check with @cperciva

jrtc27 added inline comments.
usr.sbin/freebsd-update/freebsd-update.sh
759
emaste marked an inline comment as done.

typo fix from @jrtc27

You can use -b basedir just fine without setting --currently-running if it's the same version as the base system.

This seatbelt is probably useful but it's not strictly *necessary*.

To me it seems reasonable to require an explicitly specified --basedir. The PR that prompted this review at least had a fairly straightforward error, but I imagine that someone trying to update a 14.1-RELEASE basedir on a 14.2-RELEASE system would fail in even more surprising ways, as it wouldn't trigger the "can't update other than a release" error.

If you think this is a use case we need to accommodate I could make this a warning instead, e.g. WARNING: -b basedir set without --currently-running and perhaps also basedir must contain the same version as installed on the host. But I would rather have the user specify the version rather than supporting a case that may or may not work.

To me it seems reasonable to require an explicitly specified --basedir. The PR that prompted this review at least had a fairly straightforward error, but I imagine that someone trying to update a 14.1-RELEASE basedir on a 14.2-RELEASE system would fail in even more surprising ways, as it wouldn't trigger the "can't update other than a release" error.

If you think this is a use case we need to accommodate I could make this a warning instead, e.g. WARNING: -b basedir set without --currently-running and perhaps also basedir must contain the same version as installed on the host. But I would rather require that the user specify the version than supporting a case that may or may not work.

Is there a reason to not do the right thing automatically via ROOT=... freebsd-version?

Is there a reason to not do the right thing automatically via ROOT=... freebsd-version?

Mmm, we do that for -j already, that sounds like a good idea. I'd probably emit a notice about the detected version to make it clear.

ROOT=... freebsd-version?

It doesn't look like that would work -- we'd have to execute $BASEDIR/freebsd-version as USERLAND_VERSION is baked into the script. I'll take a look at that, but as a subsequent commit.

I'm not convinced that it's strictly necessary, but I guess that's the nature of seat belts. Certainly seems harmless enough.

This revision is now accepted and ready to land.Jun 18 2025, 3:21 PM