etcupdate -- is there a way to get it to delete $FreeBSD$ strings from my files?

[Dan Mahoney (Ports)]

Hey there folks,

I grok that etcupdate is supposed to help me gently merge changes in from a new source tree into my existing tree in /etc. but as of now, most files in /etc don't have the $FreeBSD$ ident strings in them anymore (because we've moved to Git, which doesn't use this (although I miss it and wish it did))

Anyway, most of my stock /etc files still have this string in them, because it started life as a much older system that's been upgraded for a long time.

An "etcupdate diff" still shows these strings, and yes, I can pass -F to ignore those version strings, but at what point will etcupdate be modified to no longer use these strings at all?

Is there a good global way to just tell etcupdate to rip these no-longer-relevant strings out, instead of nicely merging around them?

Alternately, is there a way to just tell etcupdate "blow away changes in most files, I am prepared to have puppet re-apply all my local changes"

-Dan

[Lowell Gilbert]

Revert Mode? Extract mode? They all have some minor inconveniences, but
if you don't have anything you want to keep from the installed versions,
you wouldn't really care...

[Dan Mahoney (Ports)]

"etcupdate extract" still leaves me with an /etc with the old $FreeBSD tags in it.  I'm not sure to where it's extracting, but it doesn't seem to be to my /etc tree.

-Dan

[Sad Clouds]

On Mon, 24 Nov 2025 01:43:21 -0800
"Dan Mahoney (Ports)" <fre...@gushi.org> wrote:

> "etcupdate extract" still leaves me with an /etc with the old $FreeBSD tags in it. I'm not sure to where it's extracting, but it doesn't seem to be to my /etc tree.
>
> -Dan

This is how I've been running updates for jails, etc.

# Root mount point at which update should happen
UPDATE_ROOT="/data/vdom/test/system"

# Extract new updates from base.txz
for i in ${UPDATE_PATHS:?}
do
tar -C ${UPDATE_ROOT:?} --clear-nochange-fflags -xpf base.txz ./${i:?}
done

# Extract kernel updates (not required for jails)
tar -C ${UPDATE_ROOT:?} --clear-nochange-fflags -xpf kernel.txz

# View etc changes prior to update
etcupdate diff -D ${UPDATE_ROOT:?} -d ${UPDATE_ROOT:?}/var/db/etcupdate | less

# Update etc files
# 1) Extract etcupdate current tree from the base archive
tar -xpf base.txz ./var/db/etcupdate/current
# 2) Create etcupdate.tar.bz2 archive
tar -C ./var/db/etcupdate/current -jcf etcupdate.tar.bz2 ./ && rm -rf ./var
# 3) Run etcupdate merging new changes in etcupdate.tar.bz2 into /etc
etcupdate -D ${UPDATE_ROOT:?} -d ${UPDATE_ROOT:?}/var/db/etcupdate -F -t etcupdate.tar.bz2

Whether this still leaves those tags or not, I don't know, as I never
bothered to check.

[Dag-Erling Smørgrav]

`etcupdate extract` does not touch /etc, it populates /var/db/etcupdate.
You should only run it if /var/db/etcupdate is empty or does not match
your installed system. If you ran it with a source tree that does not
match your installed system, you have now lost the ability to correctly
track changes to /etc.

DES
--
Dag-Erling Smørgrav - d...@FreeBSD.org

[Dan Mahoney (ports)]

Dag,

Adding some context, this is from a full buildworld/installworld over the last few days. (I maintain two poudriere systems. One follows 15 via pkgbase, the other follows HEAD and builds via src).

It sounds like when you say /var/db/etcupdate, you're describing what the man page describes as the "work dir" (specified with -d), but it also mentions in the manpage an argument for -D (destdir), which defaults to /etc.

If that's the case, that's a manpage failure. Here's the usage section.

etcupdate extract [-BN] [-d workdir] [-s source | -t tarball]
[-D destdir] [-L logfile] [-M options] [-m make]

The only thing the manpage says about "extract mode" is:

Extract Mode
The extract mode generates a new “current” tree. Unlike the default
mode, it does not save any existing “current” tree and does not modify
any existing “previous” tree. The new “current” tree can either be built
from a source tree or extracted from a tarball.

It's easy to read that as either of "extract updates the workdir" or "extract generates a real, current tree in actual /etc", but it sounds like it only does the former. I'm not sure why there's even a -D in the usage?

It doesn't mention that it's only updating the workdir, and I think when Lowell suggested it to me, it seems he also thought that it would do what I want.

So, as a followon, is there anything wrong with simply copying the files from /var/db/etcupdate/current/etc into /etc (with the exception of things like master.passwd, obviously).

One thing I tried, is:

etcupdate -A \* -I /etc/master.passwd -I /etc/group

Which *seems* like it should take all files except for the two I told it to -Ignore, but no dice. I'm still stuck with something like 338 files in the diff.

-Dan

PS: As another silly example of how things have been polluted (in addition to the $FreeBSD strings), my current diffs for /boot/device.hints look like the below. I forced it to a "current" state by running 'etcupdate -A /boot/device.hints', just as a test.

This is a file I've never modified locally. I get it, that the "diff" program has attempted to gently merge things in, harmlessly leaving in place what it thought was safe, but....this is a VM.

There's no nonstandard hardware here, no floppy controllers to speak of, and no virtual uarts. I get that the goal is not to break a running system, but unless etcupdate finds a conflict, there's no way to say "theirs" for this file as part of the normal process of updating, as put forth in the handbook.

I hope this makes sense.

Index: /boot/device.hints
===================================================================
--- /boot/device.hints (stock)
+++ /boot/device.hints (local)
@@ -1,3 +1,12 @@
+# $FreeBSD$
+hint.fdc.0.at="isa"
+hint.fdc.0.port="0x3F0"
+hint.fdc.0.irq="6"
+hint.fdc.0.drq="2"
+hint.fd.0.at="fdc0"
+hint.fd.0.drive="0"
+hint.fd.1.at="fdc0"
+hint.fd.1.drive="1"
hint.atkbdc.0.at="isa"
hint.atkbdc.0.port="0x060"
hint.atkbd.0.at="atkbdc"
@@ -6,11 +15,15 @@
hint.psm.0.irq="12"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
-hint.uart.0.at="acpi"
+hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
-hint.uart.1.at="acpi"
+hint.uart.0.irq="4"
+hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"
+hint.uart.1.irq="3"
+hint.ppc.0.at="isa"
+hint.ppc.0.irq="7"
hint.atrtc.0.at="isa"
hint.atrtc.0.port="0x70"
hint.atrtc.0.irq="8"

[Dag-Erling Smørgrav]

"Dan Mahoney (ports)" <fre...@gushi.org> writes:

> Dag-Erling Smørgrav <d...@FreeBSD.org> writes:
> > `etcupdate extract` does not touch /etc, it populates /var/db/etcupdate.
> > You should only run it if /var/db/etcupdate is empty or does not match
> > your installed system. If you ran it with a source tree that does not
> > match your installed system, you have now lost the ability to correctly
> > track changes to /etc.
> Dag,

That's not my name, Bob.

> It sounds like when you say /var/db/etcupdate, you're describing what

> the man page describes as the "work dir" [...] If that's the case,

> that's a manpage failure.

No, it's a reader failure. The manual page is perfectly clear, you
just chose not to read it.

> The only thing the manpage says about "extract mode" is:
>
> Extract Mode
> The extract mode generates a new “current” tree. Unlike the default
> mode, it does not save any existing “current” tree and does not modify
> any existing “previous” tree. The new “current” tree can either be built
> from a source tree or extracted from a tarball.
>
> It's easy to read that as either of "extract updates the workdir" or
> "extract generates a real, current tree in actual /etc",

Only if you skip the DESCRIPTION section, which very clearly describes
what is meant by “current” and “previous”.

> So, as a followon, is there anything wrong with simply copying the
> files from /var/db/etcupdate/current/etc into /etc (with the exception
> of things like master.passwd, obviously).

It's your system, you can do whatever you want with it.

> This is a file I've never modified locally. I get it, that the "diff"
> program has attempted to gently merge things in, harmlessly leaving in
> place what it thought was safe, but....this is a VM.

That's not how any of this works. If you have leftovers in /etc it
means you either gave etcupdate the wrong data in the first place or
merged the conflicts incorrectly.

[Dan Mahoney (Ports)]

> On Nov 24, 2025, at 6:46 PM, Dag-Erling Smørgrav <d...@FreeBSD.org> wrote:
>
> "Dan Mahoney (ports)" <fre...@gushi.org> writes:
>> Dag-Erling Smørgrav <d...@FreeBSD.org> writes:
>>> `etcupdate extract` does not touch /etc, it populates /var/db/etcupdate.
>>> You should only run it if /var/db/etcupdate is empty or does not match
>>> your installed system. If you ran it with a source tree that does not
>>> match your installed system, you have now lost the ability to correctly
>>> track changes to /etc.
>> Dag,
>
> That's not my name, Bob.

First, let me apologize for this. It clearly set our communications off on the wrong foot.

>> It sounds like when you say /var/db/etcupdate, you're describing what
>> the man page describes as the "work dir" [...] If that's the case,
>> that's a manpage failure.
>
> No, it's a reader failure. The manual page is perfectly clear, you
> just chose not to read it.
>
>> The only thing the manpage says about "extract mode" is:
>>
>> Extract Mode
>> The extract mode generates a new “current” tree. Unlike the default
>> mode, it does not save any existing “current” tree and does not modify
>> any existing “previous” tree. The new “current” tree can either be built
>> from a source tree or extracted from a tarball.
>>
>> It's easy to read that as either of "extract updates the workdir" or
>> "extract generates a real, current tree in actual /etc",
>

I still don't know how -D plays into the extract command, but in the end, it didn't seem to matter.

What I really missed was that elsewhere in the manpage, the author directly says, in effect, "sure, copy things out of the current directory" until you get to a reasonable point.

Because there's mention *of* the $FreeBSD$ stuff in the manpage, I really thought it was a special case somehow. It's become clear that over the years this system was updated -- first from freebsd-update, then from pkgbase, and later, from source, when pkgbase started breaking things earlier this year, that the steps required to update /etc weren't always properly followed all the way along.

At this point, my `etcupdate diff` is down to only the files you'd expect (passwd, group, and the like), and I feel way better moving forward.

Thanks for the help and the patience.

-Dan