Re: Proposal to enhance boot path selections

You're asking for a lot, and I am not prepared to spend the time it
would require.  I have already updated x86/boot(8) and added a Xr
for mk.conf(5), and if someone wants to write a wiki page I will
happily review/edit it.  wiz@ has already created a wiki page (see
https://wiki.netbsd.org/kernel_dir/) that may address some of your
concerns.

I've also done my best here in this thread (and elsewhere) to make it
as clear as I can that this relates to KERNEL_DIR, and that is only
pertains to i386 and amd64.  The option is entirely optional, but the
bootloader needs to cope with both "set" and "unset" environments, to
avoid a proliferation of boot images.

Most of the impact of KERNEL_DIR is already committed; this newest
proposal is minor and has minimal impact.



On Sun, 11 May 2025, Taylor R Campbell wrote:

>> Date: Sun, 11 May 2025 06:39:42 -0700 (PDT)
>> From: Paul Goyette <[email protected]>
>>
>> On Sun, 11 May 2025, Greg Troxel wrote:
>>
>>> Thus I suspect I am missing something.
>>
>> Yup, I think you're missing the fact that all of this relates to the
>> ratther new-ish KERNEL_DIR option, support for which was only recently
>> completed (by myself).  KERNEL_DIR is described briefly in options(4),
>> and it is noted in both CHANGES and UPDATING.
>>
>> In short, KERNEL_DIR provides a mechanism to keep a kernel and its
>> associated modules together, addressing one of the most common
>> complaints about modules.
>>
>> Sorry for not making this more clear.
>
> I think it is important to
>
> (a) make this clear and obvious and intuitive, _and_
> (b) make sure we have tested any plausible transition paths that might
> happen.
>
> To that end, this present proposal aside (I haven't digested it, no
> comments about it), I would strongly suggest that you make a wiki page
> describing everything about the KERNEL_DIR changes (not just the terse
> summary in CHANGES, or the notes in UPDATING which are only for an
> audience of current users to maintain MKUPDATE=yes builds), including
> a systematic table of:
>
> 1. What has changed or will change in the standard bootloader?
> 2. What has changed or will change in a custom bootloader with any new
>   build options?
> 3. What has changed or will change in an unmodified GENERIC kernel?
> 4. What has changed or will change in a custom kernel with any new
>   build options?
> 5. What does/will sysinst do?
> 6. How are transitions/upgrades expected to happen?  What will happen
>   when a stock netbsd-10 installation is updated to a stock netbsd-11
>   installation?
> 7. How have all of these scenarios been tested?
>
> We really need to make sure this doesn't become another /var/db/pkg
> renaming debacle that leaves everyone's machines in confusing
> inconsistent states requiring manual intervention.
>
> This type of change -- substantially altering the semantics of how the
> bootloader finds the kernel -- has an extremely high risk, not just of
> putting machines into confusing states, but of rendering them
> unbootable when you update the bootloader.  And, if we were doing it
> again, I would ask that any changes be proposed to tech-kern and
> port-*, with all this relevant information, _before_ committing
> anything that affects default builds.
>
> (It's likely that there already are good answers to all of these
> questions, and you've already figured all this out -- it's just not
> clear to me from the CHANGES and UPDATING notes and the scattering of
> commit messages I've seen fly by, so I'm just asking for a clear
> picture to be presented in an obvious place to see how this will
> affect users.)
>
> !DSPAM:6820b69e284681540015745!
>
>

+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint:     | E-mail addresses:    |
| (Retired)           | 1B11 1849 721C 56C8 F63A | [email protected]    |
| Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | [email protected]  |
| & Network Engineer  |                          | [email protected] |
+---------------------+--------------------------+----------------------+