Re: git: 7b936eee18 - main - 15.0/errata: Begin listing known open regressions

On 1/6/26 09:44, Alexander Ziaee wrote:
> On 2026-01-06 09:30 -05:00 EST, "John Baldwin" <[email protected]> wrote:
>> On 1/5/26 01:21, Alexander Ziaee wrote:
>>> The branch main has been updated by ziaee:
>>>> URL: https://cgit.FreeBSD.org/doc/commit/?id=7b936eee18f57cb2b1f05d5120b9dc45275a163b
>>>> commit 7b936eee18f57cb2b1f05d5120b9dc45275a163b
>>> Author:     Alexander Ziaee <[email protected]>
>>> AuthorDate: 2026-01-05 03:52:54 +0000
>>> Commit:     Alexander Ziaee <[email protected]>
>>> CommitDate: 2026-01-05 06:20:04 +0000
>>>>       15.0/errata: Begin listing known open regressions
>>>       >      List three known traps upgrading to 15.0R in the release errata.
>>>       >      Noting:                 this is 34 days late, but first time since 12.0R
>>>       Discussed with:         adrian, imp, jhb, jrtc27, ngie
>>>       Reviewed by:            adrian
>>> ---
>>>    website/content/en/releases/15.0R/errata.adoc | 12 +++++++++++-
>>>    1 file changed, 11 insertions(+), 1 deletion(-)
>>>> diff --git a/website/content/en/releases/15.0R/errata.adoc b/website/content/en/releases/15.0R/errata.adoc
>>> index 16f41d1129..17a881b824 100644
>>> --- a/website/content/en/releases/15.0R/errata.adoc
>>> +++ b/website/content/en/releases/15.0R/errata.adoc
>>> @@ -60,7 +60,17 @@ For a list of all FreeBSD CERT security advisories, see https://www.FreeBSD.org/
>>>    [[open-issues]]
>>>    == Open Issues
>>>    > -No open issues.
>>> +1. **man:ipfw[8]** denies networking when booting a 15.0 kernel with 14.3 userland +
>>> +**Workaround**: upgrade completely before rebooting man:ipfw[8] systems +
>>> +**State**: open - https://bugs.freebsd.org/291562 +
>>
>> How do you upgrade completely when freebsd-update refuses to install the world
>> until you've booted into the new kernel?
> 
> I do not know, I upgrade with make.

In the recent case I had, I was using freebsd-update, not make.  It's not clear to me
if you can force freebsd-update to update the world while the old kernel is still
running.

>> I think the other viable workaround is to disable ipfw for the intial reboot
>> as sucky as that is.  Ideally though the kernel would still support the older
>> ipfw binary.
> 
> I thought about that, and thought "I can't tell them that". I suspect that this only matters
> in a remote only environment, where that is not an option.

Well, I think we have to let users make the tradeoff decision of which workaround
to use.

>> We probably should have just reverted all the ipfw changes in
>> stable/15 (if not main) if this issue was discovered prior to the release as
>> bricking boxes on upgrade is a pretty drastic failure mode.
> 
> I think maybe in the future we need to make this list sooner, like during the release candidate
> phase, and then we can revert or fix these issues before shipping.
> 
> This is just my first take at starting to get things written down in this section. Nobody has done
> it since FreeBSD 12.0, and it needs to be done so we can have these kinds of conversations.
> 
> Do you want me to write something different?

I think the only thing might be to expand the list of workarounds.

-- 
John Baldwin