FreeBSD support

[paigeadelethompson]

I cant seem to figure out who cares about this. It matters a lot to me but I feel like I might be the only person. My question is is there some plant to make podman generally available for FreeBSD? Because I can't get it to work and as near as I can tell it's perhaps a problem with ocijail (maybe a version mismatch but I really can't imagine why that would be unless somebody is actually just using and developing ocijail, to be used on it's own. I could maybe contribute to this some but I need to understand a few things about how this is supposed to work. Ideally one wouldn't ever use Linux binary compatibility for anything because otherwise why not just use Linux but admittedly I want it to work and I don't want to have to figure out how to make it work for every new install of FreeBSD and in general running native FreeBSD containers with it would be ideal. Are you supposed to have runc or crun or something for Linux containers ? Because it's not installed and I'm wondering if that has something to with why it's not working.

[paigeadelethompson]

I tried bumping the ports version to 5.3.5 but still get the same error:

podman run --rm docker.io/dougrabson/hello
Trying to pull docker.io/dougrabson/hello:latest...
Getting image source signatures
Copying blob b13a5ec7f3d2 done   |
Copying config f81c971736 done   |
Writing manifest to image destination
Error: OCI runtime error: ocijail: error calling jail_attach: Invalid argument

thats with ocijail 0.4.0 I DONT KNOW WHY, I asked freebsd-jails, freebsd-hackers, nobody knows .... I compiled podman from head and ran bin/podman and I get a different non-descript error:

podman/bin/podman run --rm docker.io/dougrabson/hello
Error: not supported

no logs.

[paigeadelethompson]

@dfr hey I just figured out that you're the maintainer for this port. Did this hit a wall? I'm at a loss for how to ascertain the cause of this error jail_attach: Invalid argument looking at the source for ocijail it seems there could only be one argument that it's unhappy with being the jail id: https://github.com/dfr/ocijail/blob/50ee0b899945b06e6295e7f1cfce26f0d2f37de5/ocijail/jail.cpp#L54

Happy to help here I'd really like to see this succeed, I'd appreciate the help though if this problem is more obvious to you ..

EDIT: Im looking at the man page for this https://man.freebsd.org/cgi/man.cgi?query=jail_attach I don't know what status that would be . I thought maybe I could use truss but that only shows calls in the current process and I think it must be running ocijail via exec or something so .. I dont know how to use ocijail really .... otherwise I'd test this and see if it does the same thing

[dfr]

I use both truss and ktrace for debugging these types of problem. With truss, I usually tell it to trace through forks and be verbose about execve calls using something like truss -faed. Sometimes truss gets confused and I drop down to ktrace -i and use kdump to examine the trace.

[afbjorklund]

Are you supposed to have runc or crun or something for Linux containers ?

There is "runj", which is an OCI runtime - supposed to work with the Linuxulator

https://samuel.karp.dev/blog/2021/03/runj-a-new-oci-runtime-for-freebsd-jails/

https://samuel.karp.dev/blog/2021/05/running-freebsd-jails-with-containerd-1-5/

For Podman, I would assume that it would rather use some variant of crun.

But I stopped experimenting 2023... (lima-vm/lima#1508) 👿

Both the VM images and the containers were pretty huge.

[afbjorklund]

This was the instructions that I was following at the time, ZFS was a pain

https://productionwithscissors.run/2022/09/04/containerd-linux-on-freebsd/

[afbjorklund]

It matters a lot to me but I feel like I might be the only person.

I don't think we ever found a valid use case for it (BSD), though

[paigeadelethompson]

It matters a lot to me but I feel like I might be the only person.

I don't think we ever found a valid use case for it (BSD), though

Yeah its not for everybody I suppose

[afbjorklund]

Regarding FreeBSD for podman machine, this was discussed here:

• Allow specifying a guest OS in podman machine init. #19939

[afbjorklund]

https://github.com/oci-playground/freebsd-podman-testing

https://podman.io/docs/installation#installing-on-freebsd-140

[afbjorklund]

This was the official update, as far as I know. "development will continue with planned further advancements throughout 2024"

https://freebsdfoundation.org/blog/advancing-cloud-native-containers-on-freebsd-podman-testing-highlights/ (dfr's ocijail)

[paigeadelethompson]

Yeah, I will try to get ahold of dfr and see if he'd be down to chat sometime thank you for that :) If I can manage to have a chat with him I'll definitely follow up because I want this to work, I'm not going back if I can go forward 😂

[rhatdan]

@dfr is the one working on this.

[dfr]

Sorry everyone. I haven't been paying attention here due to the seasonal family visits and festive TV etc.

To try to answer @paigeadelethompson 's question, I am the person who maintains the the FreeBSD Podman port. As I think you found, you can install this from the FreeBSD ports collection with something like 'pkg install podman' and this will install all the required support, including ocijail.

I'm not sure where your error is coming from - this is what I get with the latest port installed:

$ sudo podman run --rm docker.io/dougrabson/hello
Trying to pull docker.io/dougrabson/hello:latest...
Getting image source signatures
Copying blob b13a5ec7f3d2 done   |
Copying config f81c971736 done   |
Writing manifest to image destination
!... Hello Podman World ...!

         .--"--.
       / -     - \
      / (O)   (O) \
   ~~~| -=(,Y,)=- |
    .---. /`  \   |~~
 ~/  o  o \~~~~.----. ~~
  | =(X)= |~  / (O (O) \
   ~~~~~~~  ~| =(Y_)=-  |
  ~~~~    ~~~|   U      |~~

Project:   https://github.com/containers/podman
Website:   https://podman.io
Documents: https://docs.podman.io
Twitter:   @Podman_io
$ sudo podman version
Client:       Podman Engine
Version:      5.2.5
API Version:  5.2.5
Go Version:   go1.21.13
Built:        Thu Jan  2 01:50:58 2025
OS/Arch:      freebsd/amd64

Lets try to chat sometime soon and try to solve your problem. For now, you should probably avoid Podman 5.3 - I think there are some. FreeBSD-only problems there that we need to debug before we can update the port.

[paigeadelethompson]

That would be cool, I was going to ask if maybe we could catch up on a jitsi call or something. I tried to reach out by e-mail but not sure if it reached you, I sent it from [email protected]?

[dfr]

That would be cool, I was going to ask if maybe we could catch up on a jitsi call or something. I tried to reach out by e-mail but not sure if it reached you, I sent it from [email protected]?

It did reach me - I'll reply there.

[koobs]

we're keen to dovetail with you guys too on podman/ocijail, were hitting the following:

[freebsd@vnic-20250424-1029 ~]$ sudo podman run --network=host -it c6ebb1f0b447
Error: ocijail:  not found in $PATH: No such file or directory: OCI runtime attempted to invoke a command that was not found

No further info on what the command attempting to be run is, but ocijail itself is in /usr/local/bin and that usr/local/bin is on $PATH, so im guessing its something ocijail is trying to run

Will investigate code to see what that might be, but some advice and a catchup at some point convenient for you @dfr @paigeadelethompson would be great. Our long term goal is to test/QA contgribute to FreeBSD OCI spec, ocijail and/or runj where necessary, and dogfood it for our own use to help it progress.

[koobs]

Thanks for the ack Doug, output of podman image inspect below:

[
     {
          "Id": "c6ebb1f0b44706fab520a004ae657fe508a0958c89d3d6eec71f02f95f115e1d",
          "Digest": "sha256:df24ddb2729da2b1ee0cf6806ec4e23813f998fb24aa3870091f1220eec07c79",
          "RepoTags": [
               "localhost/freebsd:14.3-RELEASE"
          ],
          "RepoDigests": [
               "localhost/freebsd@sha256:df24ddb2729da2b1ee0cf6806ec4e23813f998fb24aa3870091f1220eec07c79"
          ],
          "Parent": "",
          "Comment": "imported from tarball",
          "Created": "2025-07-12T03:46:50.467495Z",
          "Config": {},
          "Version": "",
          "Author": "",
          "Architecture": "arm64",
          "Os": "freebsd",
          "Size": 10615877,
          "VirtualSize": 10615877,
          "GraphDriver": {
               "Name": "vfs",
               "Data": null
          },
          "RootFS": {
               "Type": "layers",
               "Layers": [
                    "sha256:87d598b8324b4091c78f6bef146f2372048537a30d1e449274a265d8804d3277"
               ]
          },
          "Labels": null,
          "Annotations": {},
          "ManifestType": "application/vnd.oci.image.manifest.v1+json",
          "User": "",
          "History": [
               {
                    "created": "2025-07-12T03:46:50.467495Z",
                    "created_by": "/bin/sh -c #(nop) ADD file:87d598b8324b4091c78f6bef146f2372048537a30d1e449274a265d8804d3277 in /",
                    "comment": "imported from tarball"
               }
          ],
          "NamesHistory": [
               "localhost/freebsd:14.3-RELEASE"
          ]
     }
]

I'm not sure what the UX is like or supposed to be for podman run (beyond say running default command as you say, if one is set), but we were certainly confused by the output to say the least :)

Would improving the UX of the error messaging be the responsibility of the runtime or podman itself here?

IF the former, how do runc, crun et al handle this case?

[koobs]

P.S I tried to truss the podman command to isolate, but it spun on CPU and the processes couldn't be kill -9'd (fwiw)

[dfr]

The error message is coming from the ocijail runtime - I will try to improve that. As you say, the UX is quite confusing.

I'm guessing you imported base.txz from FreeBSD-14.3-RELEASE - you could also try using ghcr.io/freebsd/freebsd-runtime:14.3 which is an image built and published as part of the FreeBSD release process. This is a small image which contains a shell and just enough functionality to install packages.

Truss seems to get confused with Podman and Buildah when they create containers. I usually use ktrace -d and kdump to debug problems when there is a lot of forking, execing and jail stuff happening.

[koobs]

The error message is coming from the ocijail runtime - I will try to improve that. As you say, the UX is quite confusing.

I'm guessing you imported base.txz from FreeBSD-14.3-RELEASE - you could also try using ghcr.io/freebsd/freebsd-runtime:14.3 which is an image built and published as part of the FreeBSD release process. This is a small image which contains a shell and just enough functionality to install packages.

roger that doug, thank you. our immediate goal is to get any freebsd container image running such that we can configure it with basic networking and a test app. will use the image you mentioned and report back. if there's anything we can help with (particularly on the testing, or ports side of things), please let us know (we're on discord too).

I've already updated the ocijail port locally to latest commit and am testing with that against latest podman from ports.

[dfr]

IF the former, how do runc, crun et al handle this case?

For crun, if I run an image without a default command it looks like this:

sudo podman run -ti --rm 19f
Error: crun: executable file `` not found in $PATH: No such file or directory: OCI runtime attempted to invoke a command that was not found

[koobs]

@paigeadelethompson apologies for somewhat hijacking your discussion. I added my report here to +1 your "hey i'm trying to get this running too" signal

[koobs]

Here's what i've been able to do so far. I'm not sure if im missing something conceptual, but im expecting jails to be created when container is 'created' (from image), and if not at that stage, then after being 'started'.

Things are showing up in ps -a output, but not in container list output.

Maybe what's possible at create/start stage is limited by the features provided by the image, or maybe i need to do some other setup to get me to what would traditionally be known as a 'base jail' that i could then 'login to' (either by interactive shell or otherwise).

Any hints here? I'm happy to document our setup for others once we get the gist of things.

root@vnic-20250424-1029:~ # podman image rm ghcr.io/freebsd/freebsd-runtime:14.3
Untagged: ghcr.io/freebsd/freebsd-runtime:14.3
Deleted: d82ba489df5ffba5a4fbebf421fc1bd194509d65c41e9dec0d8ab7420fd2b526
root@vnic-20250424-1029:~ # podman pull ghcr.io/freebsd/freebsd-runtime:14.3
Trying to pull ghcr.io/freebsd/freebsd-runtime:14.3...
ERRO[0000] Couldn't get cpu architecture: getCPUInfo for OS freebsd not implemented
ERRO[0001] Couldn't get cpu architecture: getCPUInfo for OS freebsd not implemented
Getting image source signatures
Copying blob 5696b577b2f7 done   |
Copying config d82ba489df done   |
Writing manifest to image destination
d82ba489df5ffba5a4fbebf421fc1bd194509d65c41e9dec0d8ab7420fd2b526
root@vnic-20250424-1029:~ # podman ps -a
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES
root@vnic-20250424-1029:~ # podman create --name test-container freebsd-runtime:14.3
423ee7cf2b0519ee5c563ff02faf89b71f0d427802281ad7e0a6911726e39ec7
root@vnic-20250424-1029:~ # podman ps -a
CONTAINER ID  IMAGE                                 COMMAND     CREATED        STATUS      PORTS       NAMES
423ee7cf2b05  ghcr.io/freebsd/freebsd-runtime:14.3  /bin/sh     5 seconds ago  Created                 test-container
root@vnic-20250424-1029:~ # podman container list
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES
root@vnic-20250424-1029:~ # podman start test-container
test-container
root@vnic-20250424-1029:~ # podman container list
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES
root@vnic-20250424-1029:~ # jls
   JID  IP Address      Hostname                      Path

[dfr]

This is expected. The container jail is created by podman init (which also happens implicitly for podman run).

[dfr]

This is expected. The container jail is created by podman init (which also happens implicitly for podman run).

Rewind - I just saw the call to podman start in your example. What is happening here is that because the container is not interactive, its stdin is closed and the image command (/bin/sh in this case) exits immediatly, triggering the container to stop - you should be able to see the exited container with podman ps -a.

[koobs]

we're good now, now playing with bootstrapping apps with only -runtime (minimum base packages possible), and then moving onto networking into jail via oci. thank you for your assistance @dfr, let us know how/where we can help OCI move forward