Re: A possible unintended difference in 13.1-RELEASE vs., for example, 13.1-RELEASE-p3

From: Mark Millard <>
Date: Fri, 04 Nov 2022 21:49:50 UTC
On 2022-Nov-4, at 11:37, Paul Mather <> wrote:

> On Nov 3, 2022, at 11:50 PM, Mark Millard <> wrote:
>> I downloaded and looked at:
>> FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>> # mdconfig -u md0 -f FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>> # mount -onoatime /dev/md0s2a /mnt
>> # strings /mnt/boot/kern*/kernel | grep 13.1-RELEASE
>> @(#)FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC
>> FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC
>> 13.1-RELEASE
>> Note the: releng/13.1-n250148-fc952ac2212
>> Looking at the live system after the freebsd-update to
>> -p3 :
>> # strings /boot/kernel/kernel | grep 13.1-RELEASE
>> @(#)FreeBSD 13.1-RELEASE-p3 GENERIC
>> 13.1-RELEASE-p3
>> No text analogous to: releng/13.1-n250148-fc952ac2212
> I'm just wondering, but could this have anything to reproducible builds?  It's my understanding that setting is standard for -RELEASE branches.  Note this entry in /usr/src/UPDATING:
> =====
> 20180913:
>        Reproducible build mode is now on by default, in preparation for
>        FreeBSD 12.0.  This eliminates build metadata such as the user,
>        host, and time from the kernel (and uname), unless the working tree
>        corresponds to a modified checkout from a version control system.
>        The previous behavior can be obtained by setting the /etc/src.conf
> =====

Could be, but text like releng/13.1-n250148-fc952ac2212 is reproducible
for use of the same commit to do mulitple builds. Use of different
commits across builds should be detectable even for reproducible build
style activity, or so I would expect.

The releng/13.1-n250148-fc952ac2212 type of text does have an issue
if incremental style builds are sometimes used instead of from-scratch
builds: It is for/from the kernel build and if the kernel is not built
but is left at an older build and, say, only part of world is built,
the identification would then be out of date (inaccurate) overall.

I was not really trying to claim that the releng/13.1-n250148-fc952ac2212
text I referenced was the best place to have the identification of the
exact commit used for binary updates. It is just that right now there
is no place and some manual inspection/analysis is required to (hopefully)
identify the right commit. (The mismerge-fix being an example of something
that would need to be noticed.)

Glen, Warner, etc. may well determine that the current status relative to
the build that produced the binary update is sufficient overall. I've
primarily identified related questions for consideration.

Mark Millard
marklmi at