Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more
- Reply: Warner Losh : "Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more"
- In reply to: Mark Millard : "Re: I just updated to main-n261544-cee09bda03c8 based (via source) and now /etc/machine-id and /var/db/machine-id disagree ; more"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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