I built an amd64 image using podman build --platform linux/amd64 -t fedora-helloworld-test .

I then tried running it with podman-bootc:

▶ podman-bootc run fedora-helloworld-test
WARNING: image platform (linux/amd64) does not match the expected platform (linux/arm64)
ERROR Re-exec in host mountns: setns: EINVAL: Invalid argument
ERROR Installing to disk: Gathering source info from container env: Task podman inspect failed: ExitStatus(unix_wait_status(256))
Error: unable to install bootc image: failed to create disk image: failed to run bootc install

https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/30

The libvirt domain definition is not removed after poweroff:

$ podman-bootc run --background quay.io/centos-bootc/fedora-bootc:eln

$ podman-bootc list
ID            REPO                                   SIZE        CREATED         RUNNING     SSH PORT
d35a6b59649a  quay.io/centos-bootc/fedora-bootc:eln  10.7GB      43 minutes ago  false       40277

$ podman-bootc ssh d35a6b59649a
[root@localhost ~]# poweroff 
[root@localhost ~]# Connection to localhost closed by remote host.

$ podman-bootc run --background quay.io/centos-bootc/fedora-bootc:eln
Booting the VM...
Error: runBootcVM: unable to define virtual machine domain: virError(Code=9, Domain=20, Message='operation failed: domain 'podman-bootc-d35a6b59649a' already exists with uuid dd3eb53d-6900-47c8-8cd9-b61a2d890ca5')

$ virsh list --all
 Id   Name                         State
-------------------------------------------
 -    podman-bootc-d35a6b59649a   shut off

These parameters require a new disk image to be created instead of using the existing cached disk image if there is one.

Currently, there is a 1:1 map between the VM in the cache and the OCI image.

I believe there are valid use cases for wanting to run more than one VM of the same OCI images. The point is, do these use cases fall within the scope of podman-bootc?, What would it look like from the UI POV?, for instance, the user needs to request a new VM:

podman bootc run --new-vm <imagename>

or every run creates a new VM if there is an existent VM already

How that will work when we need to rebuild the disk image, if for instance the disk size changes:

1) podman-bootc run --disk-size 20G image0
...
2) podman-bootc run --disk-size 25G image0

2) should create a new VM?, or only if 1) is still running. Or we replace the previous one unless --new-vm?, or by default is a new vm unless --replace-vm?

If we have more than one VM of the same OCI image, which of those we start on run, should we need to add --vm <vm_id>?

If we don't want to do this "automagically", we will need to manage the VMs as persistent objects with its own IDs.
I want to have this discussion before starting the work on the cache code, because it changes pretty much everything.

We need to add docs and man pages.

I would like to add some integration tests. Running them on all supported platforms (Win, Mac, Linux) will be a herculean task but we could start with Linux.

I am fluent in bats but maybe there are other options/preferences.

@germag @cgwalters WDYT?

We'd like to support Linux without podman machine.

Other discussions:

• #28

See containers/bootc#485

Let's add support for packit so we can run our test on each PR

https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/22

Some container images, especially AI related images, may require more disk space. Also some users might want to use less disk space. I think the 10 GB default makes sense but we should have an option to override it.

I don't think anyone has tested what happens when trying to run on WSL. It might just work, or need some tweaks.

See https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/32

It was requested by the podman team, to change our command flag to be coherent with podman, for instance:
remove --background making it the default, and add -i for an interactive mode.

https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/31

It'd be nice to have podman-bootc run --virtiofs <container> that would set things up to boot via virtiofs root. I think to really make this work sanely, we'd need to move the container storage out of the podman-machine VM and on to the host. That would have all sorts of implications.

Failing that, maybe we could do run --nfs to set up a NFS-backed rootfs talking to a NFS server serving the container storage on the target.
I think composefs will help here in both cases, as we can have all the selinux labels and metadata set up in the composefs, and have the virtiofs/nfs be a lower FS just fetching the backing files.

Either way steps would also include

• Extracting kernel/initramfs from the container
• Setting up qemu to launch things that way

Renovate is failing to update the package

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): update go updates (github.com/BurntSushi/toml, github.com/Microsoft/go-winio, github.com/Microsoft/hcsshim, github.com/adrg/xdg, github.com/bytedance/sonic, github.com/cilium/ebpf, github.com/containerd/containerd, github.com/containerd/typeurl/v2, github.com/containers/buildah, github.com/containers/common, github.com/containers/gvisor-tap-vsock, github.com/containers/image/v5, github.com/containers/libhvee, github.com/containers/ocicrypt, github.com/containers/podman/v5, github.com/containers/storage, github.com/crc-org/crc/v2, github.com/cyphar/filepath-securejoin, github.com/digitalocean/go-libvirt, github.com/distribution/reference, github.com/docker/docker, github.com/docker/docker-credential-helpers, github.com/fsouza/go-dockerclient, github.com/gabriel-vasile/mimetype, github.com/gin-gonic/gin, github.com/go-jose/go-jose/v3, github.com/go-logr/logr, github.com/go-openapi/analysis, github.com/go-openapi/errors, github.com/go-openapi/jsonpointer, github.com/go-openapi/jsonreference, github.com/go-openapi/loads, github.com/go-openapi/runtime, github.com/go-openapi/spec, github.com/go-openapi/strfmt, github.com/go-openapi/swag, github.com/go-openapi/validate, github.com/go-playground/validator/v10, github.com/goccy/go-json, github.com/gofrs/flock, github.com/golang/protobuf, github.com/google/go-containerregistry, github.com/google/pprof, github.com/gorilla/schema, github.com/klauspost/compress, github.com/klauspost/cpuid/v2, github.com/leodido/go-urn, github.com/letsencrypt/boulder, github.com/lufia/plan9stats, github.com/mattn/go-runewidth, github.com/moby/buildkit, github.com/moby/sys/mountinfo, github.com/moby/sys/sequential, github.com/moby/sys/user, github.com/oklog/ulid, github.com/onsi/ginkgo/v2, github.com/onsi/gomega, github.com/opencontainers/runc, github.com/openshift/imagebuilder, github.com/pelletier/go-toml/v2, github.com/power-devops/perfstat, github.com/shirou/gopsutil/v3, github.com/sigstore/fulcio, github.com/sigstore/rekor, github.com/sigstore/sigstore, github.com/spf13/cobra, github.com/stefanberger/go-pkcs11uri, github.com/sylabs/sif/v2, github.com/tklauser/go-sysconf, github.com/tklauser/numcpus, github.com/ulikunitz/xz, github.com/vbauerster/mpb/v8, go.mongodb.org/mongo-driver, go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp, go.opentelemetry.io/otel, go.opentelemetry.io/otel/metric, go.opentelemetry.io/otel/trace, golang.org/x/arch, golang.org/x/crypto, golang.org/x/exp, golang.org/x/mod, golang.org/x/net, golang.org/x/sync, golang.org/x/sys, golang.org/x/term, golang.org/x/text, golang.org/x/time, golang.org/x/tools, google.golang.org/genproto/googleapis/rpc, google.golang.org/grpc, google.golang.org/protobuf, gopkg.in/go-jose/go-jose.v2, libvirt.org/go/libvirt, tags.cncf.io/container-device-interface)

Detected dependencies

https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/10

Currently, the user needs to GC unused/outdated VMs manually.

Let's create an automatic GC, I think we can spawn a goroutine on run command, that removes any disk image
with an outdated digest or if the image doesn't exist anymore.

https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/25

Let's investigate supporting https://github.com/containers/krunvm on MacOS at least. It'd be especially ideal to share Go code for interacting with krunvm with Podman-machine.

When I run for example podman-bootc run quay.io/centos-bootc/centos-bootc:stream9 which is a hosted manifest with multiple arch images, I was unsure if podman-bootc was going to run either arch.

I wasn't sure so I checked out podman-bootc --help and I could not find any options to pass in specifying arm64 or amd64.

$ podman-bootc list
ID            REPO                    SIZE        CREATED         RUNNING     SSH PORT
14ec31aa5da4  localhost/bootc:latest  10.7GB      39 minutes ago  false       33815

VM is RUNNING false, is there any way to start it? podman-bootc doesn't have any start command, is it expected from the user to simply podman-bootc run with the same image (I guess #42 seems related here)?

So this works which is awesome!

But for some reason I am getting a qemu monitor screen appearing too when running it?

I had actually thought that it didn't work for a second because it showed the qemu monitoring screen, so I had closed it.

Running it again and waiting a bit longer, I saw that it connected via SSH fine in the end.

I feel like this is not intentional having the GUI pop up?

When running the pure qemu commands, I do not get a monitor screen, ex:

qemu-system-aarch64 \
    -m 8G \
    -M virt \
    -accel hvf \
    -cpu host \
    -smp 4 \
    -serial mon:stdio \
    -nographic \
    -netdev user,id=usernet,hostfwd=tcp::8080-:80 \
    -device virtio-net,netdev=usernet \
    -drive file=/opt/homebrew/share/qemu/edk2-aarch64-code.fd,format=raw,if=pflash,readonly=on \
    -drive file=$DISK_IMAGE,if=virtio,cache=writethrough,format=raw

It's going to take the fix in containers/bootc#485 a while to propagate so here's a terrible hack that comes to mind:

We can create a wrapper shell script for losetup that just ignores the --direct-io=on argument and bind mount that in when running the container.

https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/8

Currently, to install to container we only have 2 options:

• Set podman machine as rootful
• Work as unprivileged user and then podman save ... and (as root) podman load ..., so copying the image from the user to root to do the installation.

I think we can install the container without copying the image or requiring a rootful podman machine

Commit e7342b8 added a WaitGroup called vmConsoleWg, but I don't see Wait() being called anywhere on it, is this a bug, stale code, or maybe I'm misreading it?

@ckyrouac

Currently, on macos we use QEMU to run bootc VMs. Supporting krunkit will allow us to use virtiofs and GPU sharing.
What was stopping us from using krunkit is the lack of smbios OEM string support, but hopefully that will be sorted out soon[0, 1]

[0] containers/krunkit#9
[1] containers/libkrun#187

https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/26

Let's support a wrapper for https://github.com/osbuild/bootc-image-builder

This would first leverage CentOS/centos-bootc#453 to find the relevant image.

Also with this we should support being passed a config.

I'm envisioning:

podman-bootc run --via-bib

to start to do the disk image install that way to make it ergonomic to test. And that would happen automatically if passed podman-bootc run --image-config /path/to/config.json.

It'd also make sense to have
podman-bootc build-disk just be a direct wrapper for the podman run invocations for bib, allowing generic passthrough of everything there (e.g. could generate an ISO, qcow2 etc. without specifically running it)

https://gitlab.com/bootc-org/podman-bootc-cli/-/issues/14

Currently, port 22 is automatically forwarded to a random port to enable ssh access. I imagine some users will have a container image that starts a web service that they will want to verify is running. This will require forwarding some arbitrary port (e.g. 8080) to enable local access.

I'm getting the error "QEMU binary not found" despite having installed qemu using Homebrew. I see that the instruction set is hard coded as aarch64 for darwin.

Are you open for pull requests to support arm64 on darwin, or is that considered a dead platform? Personally, I'm fine either way. Will use a rejection as evidence to request a new MacBook. :)