Re: August 2025 stabilization week

From: Kyle Evans <kevans_at_FreeBSD.org>
Date: Fri, 29 Aug 2025 03:21:43 UTC
On 8/28/25 22:07, Konstantin Belousov wrote:
> On Thu, Aug 28, 2025 at 06:06:54PM -0500, Kyle Evans wrote:
>> On 8/28/25 17:21, Olivier Cochard-Labbé wrote:
>>>
>>> On Wed, Aug 27, 2025 at 7:26 PM Olivier Cochard-Labbé <olivier@freebsd.org <mailto:olivier@freebsd.org>> wrote:
>>>
>>>
>>>
>>>      I'm still waiting for our contributions about this stabweek before closing the week.
>>>
>>>
>>>
>>>
>>> The "August 2025 stabilization week" is now over.
>>>
>>> This stabweek has been more challenging than usual, so please be aware of the following known issues:
>>>
>>> 1.  OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. Cf an example of regression in PR/273656
>>>
>>> 2.  MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5="yes" in /etc/src.conf.
>>>
>>> 3.  Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source. A bug in the current version of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state.
>>>
>>> 4.  ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt.
>>>
>>
>> At the risk of being both repetitive and pedantic, I note once more that it's important to emphasize that they must be rebuilt
>> *if you are not running a kernel with COMPAT_FREEBSD14*.  The distinction is quite important because if you're not running
>> GENERIC or MINIMAL and you need to rebuild, ok, cool, that's the usual process.  If you're running GENERIC or MINIMAL and
>> you need to rebuild, I really want to hear about it because that means I broke something that wasn't supposed to break.
>>
> 
> To be correct, this is not an ABI breakage.  Old binaries which are linked
> against setgroups@FBSD_1.0/SYS_freebsd14_setgroups#80, get the old behavior.
> The new behavior of setgroups@FBSD_1.8/SYS_setgroups#596 is what hits the
> old unaware code _after recompilation and linking_.
> 

I haven't yet seen any reports of problems after recompilation and linking, but I'm
interested in those as well, of course.  The reports we've seen to-date that I am
aware of have been from getting smacked with a SIGSYS or SIGABRT, and I suspect the
latter may have been something that fork()ed a child that got hit with a SIGSYS, which
effectively asserted in the parent when the child did not exit as expected.  We weren't
able to collect any debug information from the SIGABRT case to confirm, though.

> I.e. while being perfectly ABI compatible there, we get some nuanced new
> behavior that is impossible to detect at the compile time.  I was assured
> that the advantages of this change overcome the inconvinience.
> 
> not assuming egid presence is provided
>>> 5.  ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1].
>>>
>>> Thanks for your reports,
>>>
>>> Olivier
>>>
>>> [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console <https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console>
>>
>