Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more

On Mar 17, 2023, at 10:15, Tijl Coosemans <tijl@FreeBSD.org> wrote:

> On Thu, 16 Mar 2023 16:48:40 -0700 Colin Percival <cperciva@freebsd.org> wrote:
>> I think the current situation should be sorted out aside from potential issues
>> for people who upgraded to a "broken" version before updating to the latest
>> code -- CCing bapt and tijl just in case since they're more familiar with this
>> than I am.
>> 
>> Colin Percival
>> 
>> On 3/16/23 15:55, Mark Millard wrote:
>>> # cat /etc/hostid /etc/machine-id /var/db/machine-id
>>> a4f7fbeb-f668-11de-b280-ebb65474e619
>>> a4f7fbebf66811deb280ebb65474e619
>>> 7227cd89727a462186e3ba680d0ee142
>>> 
>>> (I'll not be keeping these values for the example system.)
>>> 
>>> # ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id
>>> -rw-r--r--  1 root  wheel  37 Dec 31 16:00:18 2009 /etc/hostid
>>> -rw-r--r--  1 root  wheel  33 Mar 16 15:16:18 2023 /etc/machine-id
>>> -r--r--r--  1 root  wheel  33 Mar  3 23:03:25 2023 /var/db/machine-id
>>> 
>>> I observed the delete-old-files deleting
>>> /etc/machine-id during the upgrade. It did
>>> nothing with /var/db/machine-id .
> 
> delete-old deletes /etc/rc.d/machine-id, etcupdate deletes
> /etc/machine-id.  I suppose delete-old could also delete
> /var/db/machine-id but the file is harmless so I don't think this is
> important for 13.2.

Good to know. I'll remove the /var/db/machine-id that
hte machines happen to have around.

>>> Also, modern hostid generation was switched to
>>> random to avoid an exposure. But the update kept
>>> the old hostid and propogated it (not "-"s) into
>>> /etc/machine-id . So /etc/machine-id now has the
>>> same exposure.
> 
> These files are meant to remain constant across reboots, so the update
> process cannot change an existing /etc/hostid.  For example, it is used
> by NFS servers to restore state when a client crashes and reboots.

Good to know.

Absent man page(s) describing the princples for handling
the hostid and machine-id file(s) (and why), what to
report vs. not was unclear. So, for example, historical
hostid value takes default precedence over potential
adjustment to be random-based instead. That was not
obvious to me prior to the explanation. I'm not aware of
any place to find that in the man pages or other
documentation.

> If nothing relies on the old ID you can generate a new one by running
> "uuidgen -r > /etc/hostid" and rebooting the machine.

Yea, in my context, it appears that I can freely update
the files.

>>> Later I'll see if stable/13 also got such behavior
>>> for its upgrade.
>>> 
>>> I've not been dealing with releng/13.2 but upgrades
>>> from releng/13.1 and before likely have the same
>>> questions for what the handling should be vs. what it
>>> might actually be. Different ways of upgrading might
>>> not be in agreement, for all I know.

Thanks for the notes.

===
Mark Millard
marklmi at yahoo.com