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

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 18 Mar 2023 03:52:28 UTC
On Mar 17, 2023, at 19:04, Mark Millard <marklmi@yahoo.com> wrote:

> On Mar 17, 2023, at 18:24, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
>> upgrade sequence did not go well relative to my being
>> prompted to do the right thing to establish /etc/machine-id .
>> After the last reboot (kernel upgrade, presumably) it had me
>> continue with. . .
>> 
>> # /usr/sbin/freebsd-update install
>> src component not installed, skipped
>> ZFS filesystem version: 5
>> ZFS storage pool version: features support (5000)
>> Installing updates...
>> install: ///var/db/etcupdate/current/etc/rc.d/growfs_fstab: No such file or directory
>> install: ///var/db/etcupdate/current/etc/rc.d/var_run: No such file or directory
>> install: ///var/db/etcupdate/current/etc/rc.d/zpoolreguid: No such file or directory
>> Scanning //usr/share/certs/blacklisted for certificates...
>> Scanning //usr/share/certs/trusted for certificates...
>> rmdir: ///usr/tests/usr.bin/timeout: Directory not empty
>> done.
>> root@generic:~ # cat /etc/hostid /etc/mach*
>> cat: No match.
>> 
>> It did not indicate the need for another reboot to
>> end up with a /etc/machine-id file.
>> 
>> I tried "shutdown -r now" anyway. It did establish
>> an /etc/machine-id file during the reboot:
>> 
>> # ls  -Tld /etc/hostid /etc/machine-id 
>> -rw-r--r--  1 root  wheel  37 May 12 08:46:21 2022 /etc/hostid
>> -rw-r--r--  1 root  wheel  33 May 13 09:46:56 2022 /etc/machine-id
>> 
>> So the basic implementation is operational but just
>> lacks an indication of the need to reboot again.
>> 
>> The date/time is because it is a RPi4B context (no
>> time of its own) and time is not automatically being
>> established via ntp, apparently. (I did not make such
>> adjustments to the snapshot before starting the
>> upgrade.)
>> 
>> I do not know if any of the "install: ///var/db/etcupdate/ . . . "
>> lines or the rmdir line are important.
>> 
>> It earlier indicated 5708 patches were fetched and that 377
>> files were as well.
> 
> Using the likes of:
> 
> http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RC3-arm64-aarch64-RPI.img.xz
> 
> directly seems to produce installations with a constant:
> 
> kenv -q smbios.system.uuid
> 30303031-3030-3030-3265-373238346338
> 
> that ends up being what is used for /etc/hostid .
> 
> It looks like this traces back to the U-Boot
> involvement in the boot sequence:
> 
> # kenv | grep smbios
> hint.smbios.0.mem="0x39c2b000"
> smbios.bios.reldate="10/01/2022"
> smbios.bios.revision="22.10"
> smbios.bios.vendor="U-Boot"
> smbios.bios.version="2022.10"
> smbios.chassis.maker="Unknown"
> smbios.chassis.type="Desktop"
> smbios.planar.maker="Unknown"
> smbios.planar.product="Unknown Product"
> smbios.socket.enabled="1"
> smbios.system.maker="Unknown"
> smbios.system.product="Unknown Product"
> smbios.system.serial="REDACTED"
> smbios.system.uuid="30303031-3030-3030-3265-373238346338"
> smbios.version="3.0"
> 

Looks like if U-Boot ends up with a system
serial number, it uses that as the basis for
the system uuid:

https://github.com/u-boot/u-boot/blob/master/lib/smbios.c

	char *serial_str = env_get("serial#");
. . .
	if (serial_str) {
		t->serial_number = smbios_add_string(ctx, serial_str);
		strncpy((char *)t->uuid, serial_str, sizeof(t->uuid));
	} else {
		t->serial_number = smbios_add_prop(ctx, "serial");
	}

For example (some byte reordering also involved someplace):
smbios.system.serial="100000002e7284c8"
smbios.system.uuid="30303031-3030-3030-3265-373238346338"
#                    0 0 0 1- 0 0- 0 0- 2 e- 7 2 8 4 c 8

This explains my seeing the same uuid from 13.1-RELEASE
installation as I later saw from an independent 13.2-RC3
installation (not upgrade): I reused the same RPi4B.
All media produced on the same RPi4B will get the same
hostid and machine-id files by default, given how
U-Boot works and that smbios.system.uuid "wins" when
present.

This may all be fine. But it still leaves me expecting
that there should be man page(s) covering these hostid
and machine-id files and how they should be handled to
match the usages to which they are put, such as the nfs
use that was referenced. A note/reminder to look up
that material could also be relevant.

===
Mark Millard
marklmi at yahoo.com