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 16, 2023, at 16:48, 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.

A question may be if past dbus port related activity might
have established a /var/db/machine-id independent of the
recent FreeBSD activity. That might not be able to be
classified as a "broken version":

Before upgrade:
/etc/hostid (old style)
/var/db/machine-id (via port)

After binary or source upgrade to releng/13.2 . . . ?

For other source(!) upgrades:
Similarly but to a stable/13 (jumping over the middle)?
Similarly but to a main [so: 14] (jumping over the middle)?

To some extent the "broken" context is
somewhat analogous other possible prior
history sequences with /var/db/machine-id
and /etc/hostid ( but not /etc/machine-id ).

> 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 .
>> 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.
>> 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.


===
Mark Millard
marklmi at yahoo.com