Late-breaking FreeBSD 14 breakage

I had the same habit (a single command), can't recall where it was learnt, I'll no longer promote it.
The jails chapter of the handbook prompts us to # freebsd-update -b /usr/local/jails/containers/classic/ fetch install. Is that something that should change to be separate commands?

Edit: nevermind about separating commands, see #81
 
Last edited:
ivanov well spotted. I don't use that method to update jails, but it'll be sensible to change the fetch install instruction in five places in the chapter.

No other matches in English in the doc tree.

Code:
% rg --count --sort path -e 'fetch install' /usr/doc/documentation/content/en
/usr/doc/documentation/content/en/books/handbook/jails/_index.adoc:5
% rg --count --sort path -e 'fetch install' /usr/doc/website/content/en
%
 
This is a command and bound to be the same in every language. Why are you limiting the search to english? Other languages need the fix, too.
 
Other languages need the fix, too.

True in principle, however local results from rg(1) suggest not in practice (at this time).

(I'll rerun the command after my mirrors are updated.)

Postscript: I guess, what's in the FreeBSD Handbook and elsewhere might have been learnt through fortune, through freebsd-tips. And/or the tip might have been learnt from somewhere else.

Code:
% git -C /usr/doc pull --ff-only freebsd main && git -C /usr/ports pull --ff-only freebsd main && git -C /usr/src pull --ff-only freebsd main
From https://git.freebsd.org/doc
 * branch                  main       -> FETCH_HEAD
Already up to date.
From https://git.freebsd.org/ports
 * branch                      main       -> FETCH_HEAD
Already up to date.
From https://git.freebsd.org/src
 * branch                      main       -> FETCH_HEAD
Already up to date.
% rg --count --sort path -e 'fetch install' /usr/doc/
/usr/doc/documentation/content/en/books/handbook/jails/_index.adoc:5
/usr/doc/documentation/content/en/books/handbook/jails/_index.po:5
% rg --count --sort path -e 'fetch install' /usr/ports/
% rg --count --sort path -e 'fetch install' /usr/src/
/usr/src/usr.bin/fortune/datfiles/freebsd-tips:1
% grep -B 4 -A 6 -e 'fetch install' /usr/src/usr.bin/fortune/datfiles/freebsd-tips
%
Do you want to do a binary upgrade of your running FreeBSD installation? Use freebsd-update(8).

To install updates and patches for the running branch use
# freebsd-update fetch install

To upgrade to a newer release use
# freebsd-update upgrade -r ${name_of_release}

                -- Lars Engels <lme@FreeBSD.org>
%
%



Translations are typically way behind, compared to English. <https://docs.freebsd.org/en/books/handbook/jails/> is Chapter 17, <https://docs.freebsd.org/fr/books/handbook/jails/> is Chapitre 15, and so on.

Here's the review that introduced the affected lines, in English:


— one of a number of documentation reviews that omitted the docs group — people who are willing to review documentation changes.

The Doc Committers group in Phabricator is larger (membership plus watchers), however it is:
HTH

Postscript:
 
This is a command and bound to be the same in every language. Why are you limiting the search to english? Other languages need the fix, too.

I still believe this 'fix' to be the result of a mistaken conclusion from one interpretation of one apparent circumstance, but unless anyone other than myself is prepared to actually read the relevant sections of sh() code of freebsd-update to see that it does 'exit 1' on any error and therefore does not proceed to any further commands, it will stand.

Or if I'm mistaken, how so? (I mean in the code)?

Reference: my posts at #64, #66 (especially) and #74.

I'm not well enough to pursue it any further, sorry. Que será.
 
I still believe this 'fix' to be the result of a mistaken conclusion from one interpretation of one apparent circumstance, but unless anyone other than myself is prepared to actually read the relevant sections of sh() code of freebsd-update to see that it does 'exit 1' on any error and therefore does not proceed to any further commands, it will stand.
Hmm, ok, I'm with smithi - having examined the code and also after adding a print of which command is being run just before it is run.
Code:
get_params $@
for COMMAND in ${COMMANDS}; do
        echo running ${COMMAND};
        cmd_${COMMAND}
done

For example, if I do freebsd-update fetch install and have fetch fail (in my case by pointing the various *update*.freebsd.org hosts to an irrelevant IP via /etc/hosts), it does indeed exit with 1, and does not go on to try to run install. I'll strikeout my previous proposal of separating `fetch install` on separate lines.
 
For example, if I do freebsd-update fetch install and have fetch fail (in my case by pointing the various *update*.freebsd.org hosts to an irrelevant IP via /etc/hosts), it does indeed exit with 1, and does not go on to try to run install. I'll strikeout my previous proposal of separating `fetch install` on separate lines.
but why should it 'install' if it couldn't 'fetch' all updates?
This is perfectly good and reasonable behavior and in fact 'install' should NEVER run if 'fetch' failed - even if you ran that 'fetch' as a separate command beforehand.

so it really doesn't matter if you issue 'fetch install' or both commands separately - if fetch fails, 'install' shouldn't run (and possibly spam the console), so a human can investigate the output of the failed 'fetch' command and fix it first.
 
but why should it 'install' if it couldn't 'fetch' all updates?
I never said that it should, it was hypothesized earlier in the thread that this is not the behavior exhibited, which smithi refuted earlier, repeated in #80, and I chimed in to support the refutation.
 
I never said that it should, it was hypothesized earlier in the thread that this is not the behavior exhibited, which smithi refuted earlier, repeated in #80, and I chimed in to support the refutation.
I just read your previous post again and I sincerely don't know where I earlier got the impression you want freebsd-install to run 'install' on a failed 'fetch'. sorry for that.
 
Use freebsd-update fetch install

Instead, from <https://github.com/freebsd/freebsd-...r.bin/fortune/datfiles/freebsd-tips#L532-L542>:

Code:
To install updates and patches for the running branch use
# freebsd-update fetch
# freebsd-update install

Then, to upgrade to a newer release use
# freebsd-update upgrade -r ${name_of_release}

For an unrelated bug, there's now a BUGS section in freebsd-update(8), with one entry:

In patch level situations – for example, 13.2-RELEASE-p1 up to 13.2-RELEASE-p2: if any previous modification to a file in /etc/ will conflict with an available update, then freebsd-update will make no attempt to merge. Instead: freebsd-update will print a list of affected locally-modified files.




Updated, but not marked as updated (the date is unchanged): How to Upgrade to FreeBSD 14 from 13.

Linked from The FreeBSD Project home page, not yet updated – an oversight by the author (I requested changes to two pages): FreeBSD 14: Best New Features. Also, the November-2025 date is wrong.
 
Last edited:
Back
Top