W dniu 28.10.2025 o 14:37, Thomas Schweikle pisze:
On Tue, Oct 28, 2025 at 1:35 PM Dag-Erling Smørgrav <[email protected]>
wrote:
Thomas Schweikle <[email protected]> writes:
> Dag-Erling Smørgrav <[email protected]> writes:
> > Thomas Schweikle <[email protected]> writes:
> > > Dag-Erling Smørgrav <[email protected]> writes:
> > > > How was this system installed?
> > > By compiling 15-STABLE from latest available 14.3 getting
sources via
> > How did you install 14.3?
> Same way. It was Upgraded from 13-STABLE. And this was upgraded from
> 12-STABLE. If I remember it right, the system installed from
> disquettes was 5.0-RELEASE some way back in time ...
Do you understand the difference between the words “install” and
“upgrade”?
What did you use prior to etcupdate? When was /etc last updated?
The last time mergemaster was available. Later on it was done
manually, since etcupdate did not work.
My findings: etcupdate just does not work, because right after cloning
etc is not in a working state. It is, after running
make _legacy
in "/usr/src". Then it runs
etcupdate extract
etcupdate diff
without this "Failed to build new tree.", but it then fails run
etcupdate -p
right after building world, kernel and installkernel, exhausting: "No
previous tree to compare against, a sane comparison is not possible."
just because there is no tree to compare against, or better:
"etcupdate extract" created an empty tree without any files within.It
is just "make _legacy" creates all the folders, etcupdate expects, but
not the files. It seems all those advices given within the handbook or
at various places within the internet all give it the wrong way:
clone
ettupdate extract
etcupdate diff
make buildworld
make buildkernel
make installkernel
etcupdate -p
reboot
make installworld
etcupdate -B
reboot
But
clone
make buildworld
make buildkernel
etcupdate extract
etcupdate diff
make installkernel
etcupdate -p
make installworld
etcupdate -B
reboot
because you will never have a working etc before building world and
kernel. And in tune you'd never will have anything you could extract.
You are assuming something to extract, but there isn't anything before
building. mergemaster did get this right (comparing the fresh build
/usr/src etc against /etc). etcupdate does not -- at least if it is
used the way the handbook advises. It would only work this way, if you
did not clone the working tree right fresh into an empty directory (or
after "git reset hard" -- removing anything from /usr/src what was
created after the last "git pull" simulating "git clone" as far as
possible).
--
Thomas
Hello Thomas,
that’s splendid - it’s impressive that you’ve managed to upgrade FreeBSD
from version 5.0! FreeBSD truly is an amazing operating system; being
able to upgrade continuously for 25+ years without ever needing to
reinstall is a real achievement. Well done; my oldest installations that
are still being upgraded date back only to the FreeBSD 6.x era.
Anyway, it’s time to say goodbye to mergemaster - you won’t regret it.
The FreeBSD Handbook covers this transition in detail [1]. To perform
the upgrade correctly, you should run mergemaster(8) for the last time
under FreeBSD 14, and before rebooting, you’ll also need to run
etcupdate(8) too.
Here’s the sequence that worked for me many times in recent weeks:
# make buildworld
# make buildkernel
# mergemaster
# etcupdate extract
# etcupdate diff
# etcupdate -B
# make installkernel
# make installworld
# reboot
# pkg upgrade
# make delete-old
# make delete-old-libs
bootloader upgrade
# zpool upgrade
# reboot
It’s a bit risky and not entirely in line with the Handbook to skip the
first reboot, but if you’re upgrading from a relatively recent
14.3-STABLE and your root filesystem is on ZFS, you can create a backup
Boot Environment (BE) as a safeguard in case something goes wrong.
Even better, you can create a testing BE and perform the installation
into that BE after mounting it by using DESTDIR. Just remember that both
mergemaster and etcupdate must also be executed with respect to this
DESTDIR path.
If you’ve used etcupdate in the past and weren’t satisfied with its
behavior, and therefore continued using mergemaster, I recommend
cleaning the cruft by running the following command before starting the
final transition to etcupdate:
# rm -rf /var/db/etcupdate/
1.
https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-quick-start
Cheers
Marek
