Date: Thu, 16 Mar 2023 17:59:25 -0700 From: Mark Millard <marklmi@yahoo.com> To: Colin Percival <cperciva@freebsd.org> Cc: Current FreeBSD <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, Baptiste Daroussin <bapt@FreeBSD.org>, Tijl Coosemans <tijl@FreeBSD.org> Subject: Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more Message-ID: <8DCCBDC3-3E00-48DD-A501-AC89448E8FDB@yahoo.com> In-Reply-To: <F439940E-7F2E-4DFB-8D68-BE52019E5BF9@yahoo.com> References: <DCAD189B-1CBA-4D5B-B6DB-948A77AC723D.ref@yahoo.com> <DCAD189B-1CBA-4D5B-B6DB-948A77AC723D@yahoo.com> <2cf7d953-2493-9673-5ea3-fba22c694015@freebsd.org> <F439940E-7F2E-4DFB-8D68-BE52019E5BF9@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 16, 2023, at 17:27, Mark Millard <marklmi@yahoo.com> wrote:
> On Mar 16, 2023, at 16:48, Colin Percival <cperciva@freebsd.org> =
wrote:
>=20
>> 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.
>=20
> 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":
>=20
> Before upgrade:
> /etc/hostid (old style)
> /var/db/machine-id (via port)
Looks like var/db/machine-id is not a dbus default
place:
# find /var -name machine-id -print | more
# dbus-uuidgen --ensure
# find /var -name machine-id -print | more
/var/lib/dbus/machine-id
So the path in my analogy may not be the right one
for overall question.
> After binary or source upgrade to releng/13.2 . . . ?
>=20
> 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)?
>=20
> 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 ).
>=20
>> Colin Percival
>>=20
>> 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.
The above is wrong: it was etcupdate activity,
not delete-old-files activity, that did the delete
("D") and did nothing with /var/???/machine-id .
>>> 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.
>=20
It might just be that there should be notes someplace
about checking and possibly fixing the various
machine-id related file relationships, especially
if "dbus-uuidgen --ensure" (default path) was part of
the prior context.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8DCCBDC3-3E00-48DD-A501-AC89448E8FDB>