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.
... 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".
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?
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.
> 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?
> 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.
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.
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?
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!