bsdinstall: Deal with multiple kernel packages in the pkgbase repository

[np]

Summary

FreeBSD-kernel-generic is still the default but KERNCONF can be set to
something else to install a different kernel. eg.

1. KERNCONF=GENERIC-NODEBUG BSDINSTALL_PKG_REPOS_DIR=/foo/repo bsdinstall

Sponsored by: Chelsio Communications

[jrtc27]

What about release/scripts/pkgbase-stage.lua, which has a bunch of duplicated logic to decide which kernels to put on install media?

Also this should probably be based on whatever the first element of KERNCONF is at build time. I don't think this code works on powerpc64(le), for example, where it's GENERIC64(LE) and I imagine the packages are called FreeBSD-kernel-generic64(le)? That's just a special case of the same problem you're seeing?

(KERNCONF is a build-time variable, and distribution set-based bsdinstall doesn't care about it either, it just grabs kernel.txz, which is whatever the default kernel config built was. The problem comes with pkgbase because there is no FreeBSD-kernel, it's FreeBSD-kernel-${INSTALLKERNEL:tl}.)

[np]

On my use case: I'd like to (net)boot from a mini-memstick or mfsbsd image, run bsdinstall from there and have it install from a local pkgbase repository on the LAN instead of pkg.f.o. My repository has GENERIC-NODEBUG as the first kernel in KERNCONF and this patch is the bare minimum I could come up with to get past this problem.

[kevans]

In D52006#1188034, @np wrote:

On my use case: I'd like to (net)boot from a mini-memstick or mfsbsd image, run bsdinstall from there and have it install from a local pkgbase repository on the LAN instead of pkg.f.o. My repository has GENERIC-NODEBUG as the first kernel in KERNCONF and this patch is the bare minimum I could come up with to get past this problem.

Are you also producing the images that you netboot from? I wonder if we should be using something like kern.bootfile (iirc, I'm mobile at the moment and cannot check) to try and derive a default

[np]

In D52006#1188053, @kevans wrote:

In D52006#1188034, @np wrote:

On my use case: I'd like to (net)boot from a mini-memstick or mfsbsd image, run bsdinstall from there and have it install from a local pkgbase repository on the LAN instead of pkg.f.o. My repository has GENERIC-NODEBUG as the first kernel in KERNCONF and this patch is the bare minimum I could come up with to get past this problem.

Are you also producing the images that you netboot from? I wonder if we should be using something like kern.bootfile (iirc, I'm mobile at the moment and cannot check) to try and derive a default

Some boot images are stock (mini-usbstick) and some I've produced myself (for example a single mfsbsd.efi that is loader.efi with mfsbsd.ufs embedded into it with embed_mfs.sh). The boot media should not even matter -- what matters is that the system is booted into a lightweight FreeBSD environment and standard bsdinstall is available. From there I'd like to be able to point bsdinstall pkgbase at any repo and install a fresh system.

[kevans]

In D52006#1188465, @np wrote:

In D52006#1188053, @kevans wrote:

In D52006#1188034, @np wrote:

On my use case: I'd like to (net)boot from a mini-memstick or mfsbsd image, run bsdinstall from there and have it install from a local pkgbase repository on the LAN instead of pkg.f.o. My repository has GENERIC-NODEBUG as the first kernel in KERNCONF and this patch is the bare minimum I could come up with to get past this problem.

Are you also producing the images that you netboot from? I wonder if we should be using something like kern.bootfile (iirc, I'm mobile at the moment and cannot check) to try and derive a default

Some boot images are stock (mini-usbstick) and some I've produced myself (for example a single mfsbsd.efi that is loader.efi with mfsbsd.ufs embedded into it with embed_mfs.sh). The boot media should not even matter -- what matters is that the system is booted into a lightweight FreeBSD environment and standard bsdinstall is available. From there I'd like to be able to point bsdinstall pkgbase at any repo and install a fresh system.

Right, I'm mostly nitpicking at the (pre-existing) default package name; kern.bootfile on the install media would provide a better indicator of what that package name would be if we would consider a world where the first KERNCONF is only special in that it installs a symlink /boot/kernel -> kernel.$KERNCONF rather than installing directly as /boot/kernel (and that could take care of some subset of your use-cases). I think providing a configurable escape hatch here is perfectly reasonable, though.