On 31.01.2022 22.20, Mark Millard wrote:
Mike Karels <mike_at_karels.net> wrote on
Date: Mon, 31 Jan 2022 12:27:41 -0600 :
A bisect
would be rather laborious, building a modified SD card each time,
even if just testing kernel changes. Any other suggestions?
Historically I've used:
https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D
and the likes of kernel.txz (or more) from, for example:
https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c9800a43171da52/arm64/aarch64/?C=M&O=D
to update just the kernel (or whatever) and rebooted.
(It can help to have a somewhat older world that is
left in place instead of running newer worlds on older
kernels. Avoiding needing got update world as well has
been helpful when testing for kernel issues.)
This avoids building the kernels and allows a somewhat
bisect like activity until some subrange has no
arm64/aarch64 artifacts available.
One can sometimes run into the dates for the sort for:
https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D
not matching up well with the dates on the files of
interest in specific sub directoreis. (Some sort of
directory update?) This can make the bisect far more
difficult, given the choice to not have the directory
names prefixed with text that would sort by a
date/time estimate when sorted by name. (Only using
the commit id/hash completely randomizes the naming.)
===
Mark Millard
marklmi at yahoo.com
Hi
My bisect gives:
The latest working is:
dda9847275da79ccbb2f0b7079b250e28b3b3b2a
The excact following commit:
74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is bad.
So 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is where the problem starts
for me.
Hope that someone can explain why
74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 does block entropy/random
seeding on first boot around growfs invocation on arm64
/Jsm
