Steve Kargl <kargls_at_comcast.net> wrote on
Date: Wed, 04 Jun 2025 01:45:31 UTC :
> On 6/3/25 16:36, Steve Kargl wrote:
> > On Tue, Jun 03, 2025 at 08:00:00AM -0700, Steve Kargl wrote:
> >> On 6/3/25 02:56, Matthew Seaman wrote:
> >>> On 02/06/2025 23:35, Steve Kargl wrote:
> >>>> How does one use dates to checkout a particular head?
> >>>> If I'm at the top of HEAD and need to got back to
> >>>> mid-february, what's the easiest option for performing
> >>>> a bisection by hand?
> >>>
> >>> Something like:
> >>>
> >>> git checkout 'main@{2025-02-14 12:00:00}'
> >>>
> >>> Or you can say things like:
> >>>
> >>> git checkout 'main@{4 months ago}'
> >>>
> >>> See git-rev-parse(1)
> >>>
> >>>
> >> Matthew, Warner, Jamie,
> >>
> >> Thanks for the pointer for date-based checkouts.
> >>
> >> I've read up a bit on 'git bisect' and it was
> >> not clear to me how to use it. The examples I
> >> saw appeared to be an automated binary search
> >> on a single tree. I fear I may need to revert
> >> src/ and ports/ simultaneously. Using hash
> >> strings would see to be a path to madness.
> >>
> >
> > I've managed to rebuild and re-install world/kernel and gpu-firmware
> > and drm-515-kmod from git checkout 'main@{2025-03-15 12:00:00}'.
> > radeonkms.ko loaded as expected and startx brought up the
> > desktop I was expecting. Onward to next candidate.
> >
> Well, out of the frying pan and into the fire...
>
> Apparently, building world with old src/ on a system
> running a newer world and installing that old world
> over the new world is bad. To start install(1) is
> trying to use a non-existent syscall. Yes, I booted
> the kernel that matches the old world.
Did you ever have the newer world booted with the
older kernel? I cannot tell from the wording.
That always risks the older kernel not having
some of what any active parts of the newer world
needs.
It is newer kernels that allow older worlds
fairly generally: continuing to support what
older worlds needed, going back to some point.
So, I'd expect getting both to be older would
go more like (but I'm ignoring ports/packages
for the most part):
) Starting having booted newer kernel with newer
world (without drm enabled?).
) (Build and) Install the older world. Make sure
no newer drm would be tried on reboot via the
older kernel.
) Reboot so the startup world processes are also
older. This may also be with booting the older
kernel or the newer kernel.
) If it is an older kernel, build and install
a matching drm for the kernel vintage and test
it, for example.
Note that the older world allows testing a range
of kernels because that world will not use newer
kernel functionality. This can be handy when the
expectation is for kernel problems instead of
world problems: just try different kernel versions,
holder the world constant where possible.
I will note that there are pre-built artifacts
under (showing a main context example):
https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D
(but not from every commit). These can be used to
avoid doing builds until the range tested is narrow
enough to have no more artifacts available. There
are multiple artifact builds for most days going
back into early 2024-Dec as stands.
Unfortunately, specific specific artifact tree need
not have examples of every platform and looking
around is somewhat painful. For example, one has
to look in:
https://artifact.ci.freebsd.org/snapshot/main/29f6150256c204a53c6f72a03d3df35ec52ccbf6/arm/?C=M&O=D
to discover that the arm/ is empty for that
"2024-Dec-03 22:16" context. But compared to
doing a bunch of builds, I have found such
handly in exploring history for a problem.
The *-dbg.txz files have the debug symbols for the
matching *.txz . drm is not present, no parts are.
I warn that use of base*.txz and lib32*.txz and
tests.txz are more problematical, replacing more
than just programs/libraries if expanded/copied
over the live materials: configuration files too.
I tend to expand them into an empty chroot
directory tree and get that set up for chroot to
use the newer code. (Reminder: kernel updated and
booted before use of the newer world via chroot.)
But I normally do not deal with drm and my
activities do not normally need jails instead.
Mostly I've not need the base*.txz and lib32*.txz
and tests.txz files.
I normally expand the likes of kernel.txz somewhere
(empty directory) and then mv its boot/kernel to a
/boot/NEWuniqueNAME . Similar issue for
kernel-dbg.txz for its paths involved, matching
NewuniqueNAME . Then I use the name for booting
that specific kernel.
My wording does not get into using zfs to advantage
or the like. [I only use ZFS on the biggest system
configuration (RAM, media capacity, media speed,
FreeBSD-cpus count, and cpu speed combination).]
> Normally, not a problem. Simply rebuild install(1)
> with -static added to CFLAGS. Unfortunately, this
> leads to a bunch of linker errors about relocations
> and rebuilding a few libraries wtih -fPIC.
===
Mark Millard
marklmi at yahoo.com
