Re: "etcupdate extract" -- Failed to build new tree.

From: Thomas Schweikle <tschweikle_at_gmail.com>
Date: Mon, 03 Nov 2025 22:43:51 UTC
Followed your idea:

# make buildworld
# make buildkernel
# mergemaster
# etcupdate extract
Failed to build new tree.

It is broken. It only works if you unpack installation from CD, DVD or
file. In all other cases it breaks. etcupdate has a "henn and egg" problem.
If you build from sources it wont work. Regardless at which position you'll
try to "etcupdate extract". It only works if you unpacked "/etc" from CD,
DVD, or file. If it was cloned by "git clone
https://github.com/freebsd/freebsd-src.git /usr/src" followed by "git
checkout" or not it will break. It will even break if you first build world
and or not kernel. It goes haywire if you just wipe sources, and start from
scratch.
etcupdate needs something not there, if you build "/usr/src" by "git clone
https://github.com/freebsd/freebsd-src.git /usr/src", then building world,
and kernel but it is there if you unpack sources from tarball.


On Tue, Oct 28, 2025 at 3:30 PM Marek Zarychta <
zarychtam@plan-b.pwste.edu.pl> wrote:

> W dniu 28.10.2025 o 14:37, Thomas Schweikle pisze:
>
>
>
> On Tue, Oct 28, 2025 at 1:35 PM Dag-Erling Smørgrav <des@freebsd.org>
> wrote:
>
>> Thomas Schweikle <tschweikle@gmail.com> writes:
>> > Dag-Erling Smørgrav <des@freebsd.org> writes:
>> > > Thomas Schweikle <tschweikle@gmail.com> writes:
>> > > > Dag-Erling Smørgrav <des@freebsd.org> 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
>


-- 
Thomas