On 2021/08/25 10:35, Sebastien Marie wrote:
> On Tue, Aug 24, 2021 at 01:53:41PM +0200, Paul de Weerd wrote:
> > I have a new machine where I'd like to use IPMI.  Of course, doing
> > `config -e -f /bsd` will break KARL, so I tried to find a minimal way
> > of supporting this.  Done by introducing a new config file,
> > /etc/kernel.conf, which gets applied to the kernel reorder_kernel
> > builds and installs.
> 
> I like it: it is simple.
> 
> but here are some thoughts (with questions and some answers, but it is
> open):
> 
> - does it integrate well with syspatch ?
> 
>   yes, syspatch will call /usr/libexec/reorder_kernel (and the
>   configuration will be applied)
> 
> 
> - after install or upgrade, does the installed kernel (by installer)
>   has the configuration applied ?
> 
>   it seems not: install.sub has it owns logic and is directly calling
>   "make newbsd ; make install" and do not use reorder_kernel script.
>   
> 
>   I could see reason to avoid it, and reason to requiring it.
> 
> 
>   For install, no problem: the file is controlled (it doesn't
>   exist). It doesn't change anything.
> 
>   For upgrade, the file could exists. Should the installer using it or
>   not ?
> 
> 
>   If using it, it makes the upgrade process dependent of the file: how
>   to deal with an invalid file ? should the file ignored (kernel
>   installed but not configured) ?

I don't see a reason why upgrade shouldn't use it.
Invalid file handling is no more or less of a problem for upgrades than reboots.


>   how to deal with a format change in config(8) (file on disk in old
>   format, used config(8) understanding new format) ? but config(8)
>   doesn't change often, and could take care of both formats for one
>   release, and/or current.html could mention some required changes.
> 
> 
>   If not using it, does it is a problem that the first boot will be
>   different from next boot ?
> 
>   I could imagine some changes made to be the machine bootable, so the
>   first boot could lead to unbootable machine (but it isn't different
>   from now).

> Questions are open: I have no problem which using or not using the
> configuration file on upgrade, but I think it should be documented (to
> avoid questions and/or surprises).
> 

Somebody had an earlier method for applying kernel config changes
automatically that IIRC used a bootloader based mechanism passing the
config to the kernel. I think that might actually be better overall
as you could bypass it at the boot loader (rather than requiring a
backup "clean" kernel) though that's more work and I expect difficult
to do within space constraints on some archs.

I would be quite happy to have this problem solved one way or another,
while a "one size fits all" kernel should be the goal, there are
some workarounds needed e.g. for semi-broken hardware and I think that's
always likely to be the case.

Reply via email to