Page MenuHomeFreeBSD

release: create pkgbase VM and cloud images
ClosedPublic

Authored by ifreund_freebsdfoundation.org on Jul 24 2025, 8:46 AM.
Referenced Files
Unknown Object (File)
Sun, Oct 12, 5:07 PM
Unknown Object (File)
Thu, Oct 9, 10:43 PM
Unknown Object (File)
Thu, Oct 9, 7:13 PM
Unknown Object (File)
Thu, Oct 9, 4:45 PM
Unknown Object (File)
Thu, Oct 9, 4:45 PM
Unknown Object (File)
Thu, Oct 9, 4:45 PM
Unknown Object (File)
Thu, Oct 9, 4:45 PM
Unknown Object (File)
Thu, Oct 9, 4:45 PM

Details

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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Update documentation for -DPKGBASE option

cperciva added inline comments.
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?

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 added inline comments.
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.

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.

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.

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.

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.

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?

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.

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.

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?

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.

@ifreund_freebsdfoundation.org Can we land this soon?

release/Makefile.vm
129

s/PKGBASE_REPO_DIR/PKGBASE_REPO/

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?

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.

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.

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.

rebase, resolve conflicts with change to -DNOPKGBASE

ifreund_freebsdfoundation.org retitled this revision from release: support -DPKGBASE for VM and cloud images to release: create pkgbase VM and cloud images.Thu, Sep 25, 11:28 AM
ifreund_freebsdfoundation.org edited the summary of this revision. (Show Details)
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.

release/Makefile
27

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

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.
release/Makefile
27

Thanks for the catch!

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

This revision was not accepted when it landed; it landed in state Needs Review.Thu, Sep 25, 1:12 PM
This revision was automatically updated to reflect the committed changes.