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.
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.
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.
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.
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?
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.
> 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?
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.
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.
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?
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.
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.
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!
> nix-build '<nixpkgs/nixos>' -A vm -I nixpkgs=channel:nixos-25.05 -I nixos-config=./configuration.nix
I use nixos btw
https://github.com/nix-community/nixos-generators
`nixos-rebuild build-image --image-variant vmware`
See https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebui...
https://github.com/ublue-os/image-template
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.
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.
Does anyone have experience worth sharing with both?
Also, bootc is a basis for the Universal Blue family of distros, especially Bazzite, which is very popular with gamers.
I thought of the underlying tech for those other distros being ostree more than anything but this is the better interpretation.
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 https://news.ycombinator.com/item?id=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? https://news.ycombinator.com/item?id=39364975 :
> ublue-os/config//build/ublue-os-just/40-nvidia.just defines the `ujust configure-nvidia` and `ujust toggle-nvk` commands
...as long as the images are in the Red Hat family (Fedora, CentOS Stream, RHEL).