release: create pkgbase VM and cloud images

[ifreund_freebsdfoundation.org]

Summary

VM and cloud images are now built as packaged base systems by default,
matching the default for installation media.

Setting -DNOPKGBASE allows building as non-pkgbase systems.

Sponsored by: The FreeBSD Foundation

[ifreund_freebsdfoundation.org]

Update documentation for -DPKGBASE option

[ifreund_freebsdfoundation.org]

Install FreeBSD-kernel-man

[ifreund_freebsdfoundation.org]

Git branch: https://github.com/ifreund/freebsd-src/tree/pkgbase-vm-images

[cperciva]

release/tools/vmimage.subr

97

Do we want INSTALL_AS_USER here? Presumably we will want it *eventually* as part of no-root builds but I don't think we're at that point quite yet?

[cperciva]

release/tools/ec2-small.conf

27

Is removing FreeBSD-kernel.* and then adding these back necessary? I would have assumed we could just exclude FreeBSD-kernel-.*-dbg... or for that matter not mention the kernel at all since we're already excluding .*-dbg packages earlier.

release/tools/vmimage.subr

83

Likewise I'm a bit confused here about why we're excluding the kernel and then adding it back?

[ivy]

release/tools/ec2-small.conf

27

i believe the intent here is to only include the generic kernel. it's possible to have quite a few different kernel packages:

26!rose ~# pkg search FreeBSD-kernel
FreeBSD-kernel-generic-15.snap20250723060537 FreeBSD GENERIC Kernel
FreeBSD-kernel-generic-dbg-15.snap20250723060537 FreeBSD GENERIC Kernel -dbg (debugging symbols)
FreeBSD-kernel-lf-15.snap20250723060537 FreeBSD lf Kernel
FreeBSD-kernel-lf-bhyve-15.snap20250723060537 FreeBSD lf-bhyve Kernel
FreeBSD-kernel-lf-bhyve-dbg-15.snap20250723060537 FreeBSD lf-bhyve Kernel -dbg (debugging symbols)
FreeBSD-kernel-lf-dbg-15.snap20250723060537 FreeBSD lf Kernel -dbg (debugging symbols)
FreeBSD-kernel-lf-debug-15.snap20250723060537 FreeBSD lf-debug Kernel
FreeBSD-kernel-lf-debug-dbg-15.snap20250723060537 FreeBSD lf-debug Kernel -dbg (debugging symbols)
FreeBSD-kernel-lf-pf-15.snap20250723060537 FreeBSD lf-pf Kernel
FreeBSD-kernel-lf-pf-dbg-15.snap20250723060537 FreeBSD lf-pf Kernel -dbg (debugging symbols)

but on the install media, you (probably) only want generic.

[emaste]

release/tools/vmimage.subr

97

We use env INSTALL_AS_USER=yes for pkg installation in release/Makefile and, as long as it is functional we should do so for any new pkg use in the release bits rather than adding new tech debt.

[ifreund_freebsdfoundation.org]

release/tools/ec2-small.conf

27

@ivy is exactly correct about my intent here. I'll add a comment explaining this to avoid future confusion.

If someone can come up with a cleaner way to do this package selection I'd be happy to change the approach here. This is the best way I came up with without calling into lua or similar.

[cperciva]

release/tools/ec2-small.conf

27

Ah, got it. I forgot about multiple kernels. I wonder if we should instead have KERNCONFS=GENERIC in vmimage.subr (which could be overridden in release/tools/*.conf) and then have vm_install_base produce the list of "base system with just the kernel we asked for" and then pipe that through vm_filter_base_packages (which in the default case would just be cat).

Having the messy logic of "figure out which kernel packages we need" happen in multiple places seems a recipe for bugs getting introduced.

release/tools/vmimage.subr

97

Hmm, ok. I'm a bit concerned that this may result in non-root "successfully" building an image which is broken, but I'll defer to your experience here.

[ifreund_freebsdfoundation.org]

Always do an initial default package filtering

This avoids duplicating the logic for selecting the correct kernel package for
cloud images that require further filtering.

[ifreund_freebsdfoundation.org]

release/tools/ec2-small.conf

27

I split this into vm_filter_base_packages() and vm_extra_filter_base_packages() to deduplicate the kernel selection logic.

I don't think there's any need to make the kernel selection configurable currently?

[cperciva]

In D51483#1178220, @ifreund_freebsdfoundation.org wrote:

Always do an initial default package filtering

This avoids duplicating the logic for selecting the correct kernel package for
cloud images that require further filtering.

Thanks, that looks much cleaner. I can imagine scenarios where we (or downstream users) might want a different kernel, but hard-coding GENERIC in here is fine for now; we can add that additional functionality if and when needed.

release/tools/vmimage.subr

89

Why the explicit < /dev/stdin? The only effect this has is to break things if we somehow don't have /dev mounted.

[ifreund_freebsdfoundation.org]

release/tools/vmimage.subr

89

I guess I found it more explicit when I originally wrote the grep above and copied it here for symmetry. I'll remove all the superfluous /dev/stdin usage, I think it's better without.

[ifreund_freebsdfoundation.org]

Remove superfluous /dev/stdin usage

[emaste]

release/tools/ec2-small.conf

18

Would it be reasonable to provide an implementation for this in vmimage.subr? The default there is no filtering, but we could have a routine that the overrides in both *ec2*.conf files could call?

[ifreund_freebsdfoundation.org]

release/tools/ec2-small.conf

18

I don't think so? We don't have any other helpers for writing overrides of the "extra" functions in vmimage.subr and I don't think the code duplication here is that bad. Effectively the same duplication is already present for the INSTALLOPTS just above for example...

On the other hand I do understand wanting to de-duplicate fragile regex-based matching as much as possible. Really this is just another example of why things would be better if we had meta packages or groups or similar for the base system.

[cperciva]

@ifreund_freebsdfoundation.org Can we land this soon?

release/Makefile.vm

129

s/PKGBASE_REPO_DIR/PKGBASE_REPO/

[cperciva]

Actually, this is going to need some changes now that PKGBASE is the default and there's a new NOPKGBASE option. Should I just take over this patch?

[ifreund_freebsdfoundation.org]

In D51483#1203665, @cperciva wrote:

Actually, this is going to need some changes now that PKGBASE is the default and there's a new NOPKGBASE option. Should I just take over this patch?

If that's easiest for you, feel free to do so! (And ping me for a review if you like).

Otherwise I can rebase and test this again tomorrow morning.

[ifreund_freebsdfoundation.org]

I think this patch could use a bit more work than just updating for the -DNOPKGBASE change. It was written before package sets were added and it would be nice if we could leverage those rather than doing fragile regex-based matching.

[ifreund_freebsdfoundation.org]

release/Makefile.vm

129

This patch depends on https://reviews.freebsd.org/D51482, which has not yet been landed and renames that variable.

https://reviews.freebsd.org/D51482 could be landed right now as far as I'm concerned, it's generally a cleanup and will be necessary even if this patch is reworked.

[ifreund_freebsdfoundation.org]

rebase, resolve conflicts with change to -DNOPKGBASE

[emaste]

release/Makefile

27

release/Makefile.vm

129

Is now landed.

release/tools/vmimage.subr

97

My intent is that we have only one code path that works as non-root, so that we can't have a case where one path is broken and one is not.

[emaste]

release/Makefile

27

err, not correct. Probably "build VM/cloud images using make installkernel installworld"

[emaste]

release/Makefile

27

#  NOPKGBASE:  if set, include dist tarballs rather than pkgbase packages in
#            disc1 and dvd1 installation media and build VM/cloud images using
#            make installkernel installworld.

[ifreund_freebsdfoundation.org]

release/Makefile

27

Thanks for the catch!

[ifreund_freebsdfoundation.org]

Fix documentation of NOPKGBASE (this got inverted by the rebase)