Looks good to me, thanks Dave!

Seems reasonable. We don't need to lint the source every time we build it - the upstream CI forces lint checks already.

This issue does not affect the release building process and will resolve itself for me when I update my build host to stable/15

In D52616#1204489, @dch wrote:

In D52617#1201983, @imp wrote:

You might want to look at ~imp/armv7-pkgbase-14.3-exp.sh which generates a bootable image w/o root for armv7 with the correct perms using pkgbase + pkg to create the system.

I'm sure it misses many .conf files, etc that are installed / generated (*pwd.db I found already). I'm surprised I didn't add passwd though.

I wrote the above as PoC for making nanobsd be able to generate images like this, stealing bits and pieces from different places (including your OCI scripts, which acted as one of the kicks in the butt to get my work moving again).

-o INSTALL_AS_USER=yes

My version of the diff which adds all the -dev pacakges {F128913448}

In D51471#1199744, @dch wrote:

I'm very confused about pkgbase -dev packages.

For example, sshd:

$ ldd /usr/sbin/sshd
/usr/sbin/sshd:
        libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x32d96f455000)
...
$ pkg which /usr/lib/libprivatessh.so
/usr/lib/libprivatessh.so was installed by package FreeBSD-ssh-dev-15.0.1.20250906130029

But in practice, sshd doesn't seem to depend on this - I removed the FreeBSD-ssh-dev
package, restarted sshd and can connect -- neither client nor server were broken.

@dfr according to what you say above, all the -dev packages should go in toolchain package.
But if we actually need them in general for running e.g. ssh or whatever, then they need
to be pulled in elsewhere.

TLDR do I add all of these -dev and -man packages to toolchain or full?

I don't have strong opinions on the package list other than to note that clang is fairly useless without the *dev packages. As David notes, we could probably make a case for two images here, 'kitchen sink without toolchain' and another one containing toolchain etc. using kitchen sink as base.

In D51471#1176700, @emaste wrote:

thinking some more, base is probably OK because it mirrors the base system, but should that then be the one including the toolchain? I guess it's fine like this

Colin opened a similar diff: D51481. Since there is some activity there, perhaps focus on that one?

In D51471#1175361, @dch wrote:

I'll also remove:

• ntp
• ppp
• rdma
• syscons-data
• vt-data
• wpa

I'll split this into a compiler & full image as suggested
What should the dependency be? compiler needs full, or other
way around?

We can bikeshed the naming, but first I'll get it working.

I don't have strong opinions on the package list other than to note that clang is fairly useless without the *dev packages. As David notes, we could probably make a case for two images here, 'kitchen sink without toolchain' and another one containing toolchain etc. using kitchen sink as base.

Sorry - I didn't see the notification for this one. I spent some time yesterday trying to do something similar but this version is much nicer. I tested it locally and everything looks right - I had to patch it to run certctl.sh from ${srcdir} instead running the host's certctl.

Set IGNORE_OSVERSION instead of ASSUME_ALWAYS_YES

I think I will re-work this to set IGNORE_OSVERSION instead.

I tried 'pkg bootstrap -y ... && pkg update -f' and got a y/N prompt due to an OSVERSION mismatch:

I would like to get this change into 14.3 if possible - it works around a confusing error message caused by 'pkg update' attempting to get a yes/no response.

Rebase, reword commit, change image path

I'm pretty sure this broke the OCI image build - did you not see my comment above. I don't have time to deal with this in the near future - please either back this out or fix the image build script to use the new certctl feature.

Looks good. What would happen if someone copies the certs and then later links them - will the copies be removed and replaced with links?

In D42095#1173193, @des wrote:

No, certctl is not useless without the caroot package. It can still be used to hash certificates installed from ports or some other source. On the other hand, installing caroot without the tool needed to hash the certificates it contains makes no sense.

In D42095#1173183, @jrtc27 wrote:

In D42095#1173152, @dfr wrote:

I think this is wrong. This makes it impossible to install caroot without pulling in all of FreeBSD-runtime. My though process is 'can I use caroot without certctl' and the answer is a qualified yes - it can be done by running certctl with DESTDIR set. Conversely, 'can I use certctl without caroot' - clearly not since certctl is useless without certs. Therefor (in my mind), certctl should depend on caroot, not the other way around.

The other way round can be defended too: your certctl with DESTDIR means certctl has use even if the host doesn’t have any certs. Maybe neither should depend on the other and there should be a meta package that is both? (Maybe with some renaming of existing packages to make it clear)

I think this is wrong. This makes it impossible to install caroot without pulling in all of FreeBSD-runtime. My though process is 'can I use caroot without certctl' and the answer is a qualified yes - it can be done by running certctl with DESTDIR set. Conversely, 'can I use certctl without caroot' - clearly not since certctl is useless without certs. Therefor (in my mind), certctl should depend on caroot, not the other way around.

Looks good to me - thanks for working on this.

The podman port needs a patch to work around an upstream regression which I'm working to get fixed in https://github.com/containers/podman/pull/26188. We can add a simpler workaround to the port - something like:

In D50847#1161816, @dch wrote:

Let's upstream this first and then I can just bump the port.

What is the branch from your https://github.com/dfr/plugins ?
There's no matching branch compared to what the ports tree fetches

{F120368428}

Looks good to me and works in my testing. It would be helpful if you could also make a pull request for github.com/dfr/plugins which is the upstream for this port (my fork of the CNI plugins).

I would like to get this change into 14.3 if possible - it works around a confusing error message caused by 'pkg update' attempting to get a yes/no response.

In D49821#1136169, @dch wrote:

LGTM, testing with stable/14 today. thanks Doug for tracking this down & explaining it.

This version disables sparse-file handling which is the cause of the incompatibility with Podman

In D49821#1135863, @jlduran wrote:

The GitHub issue should be:
https://github.com/containers/podman/issues/25270

In D15865#1126691, @zlei wrote:

In D15865#1126562, @editor_callfortesting.org wrote:

From the Jails Production User call: This work is still of interest, particularly in the context of OCI jail progress.
DCH: "This needs serious rebasing." Do any developers have interest in this feature?

I think @dfr is interested with this :)

Review feedback

Addressed review feedback.

Review feedback

Committed without remembering to add 'Differential Revision'

Committed without remembering to add 'Differential Revision'

Committed without remembering to add 'Differential Revision'

Committed without remembering to add 'Differential Revision'

Committed without remembering to add 'Differential Revision'

After further testing, I came across a regression in 'podman build' and 'buildah build' which I will get fixed upstream (https://github.com/containers/common/pull/2326). I will add that as patches to the buildah and podman ports and test a bit more before I ship this.

In D48869#1114602, @osa wrote:

Here's the patch{F109555392}

In D48869#1114547, @osa wrote:

The patch introduces new dependency - sysutils/catatonit; the current version in the ports tree is 0.1.7, latest one is 0.2.1. Is there any plans to update the port to the recent version?

I've taken a look on the version 0.2.1 of the catatonit. Your patches in the freebsd branch look good, however there's a small change in the distribution:

--- catatonit.c
+++ catatonit.c
-#ifdef HAVE_CLOSE_RANGE
+#ifdef HAVE_LINUX_CLOSE_RANGE_H

So, I've applied both of your patches, fix the rejection and built new version. Hope that can be updated as well.

Combined your patches into one here.

In D48869#1114547, @osa wrote:

The patch introduces new dependency - sysutils/catatonit; the current version in the ports tree is 0.1.7, latest one is 0.2.1. Is there any plans to update the port to the recent version?

Looks good

Looks good to me. It would also be nice to have something similar for ip6addrctl to make it easier to have different address selection policies in vnet jails (e.g. host is dual stack and prefers IPv6 but jail only has IPv4 and should prefer IPv4 replies to DNS lookups).

This version also sets a default command of "/bin/sh" for the minimal image which is common practice for Linux base images but perhaps that should be separated out.

Are there any other concerms for this one - I would like to land it and move onto the shell-based container image build.

Override PATH for make-oci-image.sh so that we get pwd_mkdb from the cross tools rather than the host.

I tested this for amd64, i386, aarch64 and riscv64 and the metadata is correct.