>>twelve+(OP)
We also have a GUI for trying this out!

https://github.com/podman-desktop/extension-bootc

We’re also starting to see other projects adopt a “OS as a Container image” such as Bazzite: https://bazzite.gg/ using bootc :)

Feel free to ask any questions!

>>twelve+(OP)
You can also achieve this with your current system

> nix-build '<nixpkgs/nixos>' -A vm -I nixpkgs=channel:nixos-25.05 -I nixos-config=./configuration.nix

I use nixos btw

>>twelve+(OP)
> A container for deploying bootable container images.

...as long as the images are in the Red Hat family (Fedora, CentOS Stream, RHEL).

>>twelve+(OP)
Does bootc-image-builder build Native Containers?

Do Native Containers work as VM images that can be stored in an OCI Image/Artifact/Package Registry?

I've been mentioning Native Containers since I realized that was how bazzite works now.

Is vagrant necessary anymore if host, vm, and container images can all be signed and stored in an OCI Image store?

From >>44137501 re: Firecracker and Microsandbox VMs :

> ostree native containers are bootable host images that can also be built and signed with a SLSA provenance attestation; https://coreos.github.io/rpm-ostree/container/

ublue-os/image-template: https://github.com/ublue-os/image-template :

> Build your own custom Universal Blue Image

ublue-os/akmods has nvidia GPU drivers, nvidia-open, zfs: https://github.com/ublue-os/akmods :

> A caching layer for pre-built Fedora akmod RPMs

> OCI images providing a set of cached kernel RPMs and extra kernel modules to Universal Blue images. Used for better hardware support and consistent build process.

nvidia-container-toolkit (CDI) is necessary for --gpus=all to do CUDA and libEGL 3D with podman. Is this also already installed in bazzite?

ublue-os/toolboxes: "quadlets and systemd service units for management", boxkit : https://github.com/ublue-os/toolboxes#images

ublue-os/devcontainer .devcontainer/devcontainer.json: https://github.com/ublue-os/devcontainer/blob/main/src/base/...

It looks like the Just Justfile 40-nvidia.just has moved due to image topology simplification? >>39364975 :

> ublue-os/config//build/ublue-os-just/40-nvidia.just defines the `ujust configure-nvidia` and `ujust toggle-nvk` commands

>>twelve+(OP)
Huh, this is kinda wild. So for esxi images, this would seem to beat/potentially be simpler than the traditional Packer + interacting with an ISO on esxi infra, yes?

>>tt7262+6V8
Can this do vmdk format?

>>westur+y09
What does "native containers" mean in this context?

>>yjftsj+8Z8
Is there something about this makes it red hat specific. An OS is just a specific collection of files in the end. Whether things are installed with rpm or Deb shouldn't matter?

>>tayo42+I79
You'd think so:) Unfortunately the current implementation hardcodes calls to dnf: https://github.com/osbuild/bootc-image-builder/issues/869

>>indigo+329
I don't know the answer using the built-in VM attributes (I mean I'd guess probably, but I don't know how if so) but there's always nixos-generators for making VM images. Definitely used this for deploying VMs to cloud providers, haven't tried the VMWare one yet though.

https://github.com/nix-community/nixos-generators

>>twelve+(OP)
I've been very excited on progress on bootc. I've tried to make my own coreos distro and its quite complicated in comparison.

I've used this to start from a minimal base and added what I've needed on top. Best of all, updates are delivered via a container registry.

>>yjftsj+8Z8
The project roadmap actually includes plans to expand beyond Red Hat family distributions - there's active work to add support for Debian/Ubuntu and potentially other distros.

>>twelve+(OP)
Universal Blue (Bluefin etc.) has a reusable GitHub template.

https://github.com/ublue-os/image-template

>>twelve+(OP)
I wonder which gets more actual usage, this project or linuxkit.

Does anyone have experience worth sharing with both?

>>twelve+(OP)
I've used this to bootstrap bootc-based Fedora on my workstations. I've got a CI job that builds updated container images every night, a simple `rpm-ostree upgrade` pulls in the new image and `systemctl reboot` activates it.

What I like about this is always having a known working image I can quickly swap to, particularly for the machine with an nvidia card.

>>twelve+(OP)
I'd love to have something like this for embedded system images, like for Raspberry Pi deployments.

>>twelve+(OP)
Roman Shtylman has an example of using a Dockerfile to produce a rootfs for the Jetson Nano: https://github.com/defunctzombie/jetson-nano-image-maker (2022)

I've always been hesitant to use this method over debootstrap: the Ubuntu container images ("FROM ubuntu:20.04") are created from a tarball that Ubuntu's convoluted CI system spits out and I'm not confident I understand if it's somehow suitable only for a container and not for real hardware.

>>twelve+ZU8
Why swap from the OSTree storage to OCI? Doesn't that negate the space saving offered by OSTree having a content addressable store.

>>indigo+329
Yes, you can target VMDK, AMIs, Azure, ...

`nixos-rebuild build-image --image-variant vmware`

See https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebui...

>>yjftsj+8Z8
I was going to try this to perhaps use it in production. Turns out the RHEL clones like Alma or Rocky doesn't have this thing in production-ready grade. All options you have now are owned by Red Hat themselves.

>>hardwa+em9
If I had to wager a guess, bootc might get more actual use now that it's supported in RHEL 9.6 and 10 as "image mode". It's an exciting piece of technology, especially from the perspective of a platform engineer.

Also, bootc is a basis for the Universal Blue family of distros, especially Bazzite, which is very popular with gamers.

>>yjftsj+8Z8
Booting Docker images is fairly straightforward, I wrote about how to do this manually some years ago: https://blog.davidv.dev/posts/docker-based-images-on-baremet...

>>rgovos+dp9
The alternative is mkosi from systemd developers

https://github.com/systemd/mkosi

However beware that they break backwards compatibility almost every 6 months. This is probably the most backwards-incompable project I know, you can't rely that the minor version update won't break your projects.

>>Chocol+Vq9
By using zstd:chunked, we get those atomic diffs at each layer using an enabled container registry. So diffs are still over the wire.

>>yjftsj+8Z8
Ublue also builds Ubuntu versions of a lot of this.

>>whs+hu9
Just ask Neil Gompa to ship it. He doesn’t love it, but he helps everyone who asks him for advice.

>>Wuzado+Sx9
yeah you're probably right -- going forward the usage is likely going to be a lot higher, at the very least.

I thought of the underlying tech for those other distros being ostree more than anything but this is the better interpretation.

>>lothar+r29
> ostree native containers are bootable host images that can also be built and signed with a SLSA provenance attestation

From https://coreos.github.io/rpm-ostree/container/#ostree-native... :

> rpm-ostree inherits work in ostree-rs-ext to create “container native ostree” functionality. This elevates OCI/docker containers to be natively supported as a transport mechanism for bootable operating systems.

I think it means simplification of complexity and unnecessary re-duplication.

>>tmaier+dl9
... and it works fabulously. I have been running Bluefin (same folks as Bazzite) from one of these templates for about 6 months and it has been a near on flawless experience. I have moved from Fedora 40->41->42 without having to touch a traditional "upgrade".

https://projectbluefin.io/

>>indigo+V19
Arguably yes. I think the big improvement is that an upgrade is really just switching from image A to image B, rather than dozens to hundreds of individual package transactions. Furthermore parts of the system are fully mutable (e.g. /etc) allowing you to run automation against a system post install for more customisation.

>>franga+yo9
Totally. Appliances are perfect candidates for this tech.

>>yjftsj+8Z8
bootc is a CNCF project now, so anybody can get on board.