Date: Fri, 17 Mar 2023 20:52:28 -0700 From: Mark Millard <marklmi@yahoo.com> To: Colin Percival <cperciva@freebsd.org> Cc: =?utf-8?Q?T=C4=B3l_Coosemans?= <tijl@FreeBSD.org>, Current FreeBSD <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, Baptiste Daroussin <bapt@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: <ADAA8C68-6154-4DAA-BDC9-BC8B8845E349@yahoo.com> In-Reply-To: <91950753-BDE0-45D5-B0B9-42782BD75C47@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> <20230317181547.4d75e897@hal.tijl.coosemans.org> <C18AED00-6CCF-4140-A0AE-B947521E422A@yahoo.com> <D8F42EA8-6105-4E0A-961F-916D61589B98@yahoo.com> <91950753-BDE0-45D5-B0B9-42782BD75C47@yahoo.com>
index | next in thread | previous in thread | raw e-mail
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.comhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ADAA8C68-6154-4DAA-BDC9-BC8B8845E349>