After having gotten to the point of having over 100 rpm-ostree overlays on my system I’m tinkering for a while with building my own overlay image based on bazzite-nvidia-open. I try to change as little as possible in Bazzite itself, but still add a ton of DevOps and AI/ML related tools and a couple of ujust commands for things like managing podman quadlets and kubernetes cluster.
I’m getting really close to releasing my own Bazzite overlay image into the wild, but there is one thing that needs to be resolved first: When are you allowed to call something Bazzite?
Because calling an image that’s literally bazzite-nvidia-open with a couple of additional layers and rpms from the Bazzite repo anything other then Bazzite-Something feels weird. But as far I as I have seen there are no clear guidelines when your allowed to call something Bazzite or what procedures you’re supposed to follow when you want to create a Bazzite equivalent of a Fedora Spin.
And it would be great to come up with a Bazzite equivalent to Fedora Creating Spins for everyone who wants to create what I personally would call an Bazzite Overlay Image.
well why call smth bazzite if that is just universal blue image? Maybe aurora gaming edition? or maybe universal blue KDE gaming edition? You make smth out of existing components, so name it however you want, but bazzite is a project with set goals and saying “I want to add something” and then name it like “bazzite-nvidia-open-plus-some-AI-tooling-that-fits-a-workflow-of-some-guy” is just weird.
I think it would be healthier to try to upstream some of your work in bazzite-dx or do smth like atrawogOS and in readme specify that it is based on bazzite
Couple of questions, just curious, why are you using Bazzite instead of Bluefin or Aurora for this, since those have more dev/devops/AI tools already there, especially in the DX images? Is this a gaming-focused build?
Also, I’m not sure what you mean by a “Bazzite overlay image.” Are you building your own image from a Containerfile and build scripts, or with Bluebuild? (Which isn’t layering but adding the packages you need directly to the image.)
The short answer is because I’m sharing my computer with my son who’s doing tons of Steam VR and other 3D gaming stuff. Adding any devops tools to an image is pretty easy. The really tough nut to crack is to get the GPU config right. Bazzite is doing a great job at both gaming and things like nvidia container toolkit integration so it’s the obvious starting point for us.
Also, I’m not sure what you mean by a “Bazzite overlay image.” Are you building your own image from a Containerfile and build scripts, or with Bluebuild? (Which isn’t layering but adding the packages you need directly to the image.)The short answer is because I’m sharing my computer with my son. I have a pretty beefy AI workstation my son loves to use for his Steam VR and 3D Stuff whenever he can and Bazzite is the perfect OS for both of us as a starting base.
I’m using the usual Dockerfile with bazzite-ai-nvidia-open as my base image approach and add additional image layers on top of the existing image (that’s why I’m calling it an overlay). Using an approach that’s pretty similar to what bazzite-dx is doing.
I could build my own image from scratch, but for my needs that would be quite a overkill. Because there is almost nothing I want to change in the Bazzite itself.
The point is that I’m using the Bazzite Nividia Open as my base image not Universal Blue. The whole beauty of the Fedora Atomic / Universal Blue / Bazzite approach is that it’s super easy to add additional packages to an existing image and create a new one and places like Docker Hub and the Github registry are full of what you call "some-AI-tooling-that-fits-a-workflow-of-some-guy” images and everyone is happy about it, because it’s saving everyone a ton of time.
The only downside of the immutable image approach is that once your building on top of a Bazzite image it’s almost impossible to remove the Bazzite Logo or other branding and you end up in a situation where you simple have to call a container image that’s e.g. based on Fedora a Fedora Image.
That’s why I’m suggesting some form of policy where you can either use the the bazzite image as is and call the image you build on top of it something else. Or some kind of formal process to apply for building an official Bazzite derivate like bazzite-dx.
Because the only other alternative would be to force everyone who wan’t to add a singe rpm to an bazzite image to create a complete fork of bazzite including a full rebranding of absolutely everything.
Also, our image-template is just made for these kind of things, where you need something for your own use.
It takes under 10 minutes to set it up, and after that you can do whatever you want with it, add anything, modify it your hearts will etc. It will build daily and get all the same updates that regular images would get.
The image us up and running and I think it could be useful to other too. My only question is what exactly am I supposed to do next?
Because as a DevOps guy that’s working for a company that’s doing 100% Open Source I have a habit of releasing all the container images I build and for me the Bazzite image additions I’ve made are just yet another image to publish on Github.
I’ve looked into it and the whole ublue build system is really great. But if it’s somehow possible policy and community wise I would like to avoid building my own ublue image from scratch. Because that would result in a lot of duplicated work and fragmentation with little to no benefits.
There is no “general” policy. The general consensus is that if you need something extra or custom that is not in the “base image” you either build your own for your use or use for others.
The other option is to open PRs for the additions to the base image that your custom image would use (like bazzite-dx etc).
That’s a consensus that’s making a lot of sense. But I’m starting to bump into two issue:
Bazzite is doing such a great job with things like Steam and GPU integration that it’s making sense to build on top of Bazzite instead of building your own ublue image and trying to replicate everything Bazzite is doing from scratch.
I’m a DevOps guy not a Coder. Bazzite-dx is great, but I don’t think many bazzite-dx user are interested in running their own CUDA enabled kubernetes cluster with AI/ML workloads on their computer like I’m.
Yeah, that is way too many packages to layer. Layering anything over a couple of packages is recommended to make your own image. I wouldn’t call it overkill to build your own image. Its actually quite easy. Once you’ve copied the template, it’s as easy as just a single line in a build script or recipe.yml (for bluebuild).
When you build your own image, you are not starting from scratch. Your base image IS the Bazzite image if that is what you want to base off of. You don’t have to base off of the scratch ublue image.
Here is a simple example of a build with one package added on top of aurora-dx base with bluebuild:
---
# yaml-language-server: $schema=https://schema.blue-build.org/recipe-v1.json
# image will be published to ghcr.io/<user>/<name>
name: automatic-parakeet-bluebuild
# description will be included in the image's metadata
description: Custom Aurora-DX with bluebuild
# the base image to build on top of (FROM) and the version tag to use
base-image: ghcr.io/ublue-os/aurora-dx
image-version: stable # latest is also supported if you want new updates ASAP
modules:
- type: dnf
install:
packages:
- webkit2gtk4.1
- type: signing # Sets up signature verification properly
As you can see from the base image, I’ve used aurora-dx; I could just as easily use bazzite-dx. So you don’t have to start from scratch.
Yes and I think the best approach that would fit my needs perfectly is to use the Ublue image-template with bazzite-nvidia-open as base image to build my own image and then hope that nobody is going to complain about the bazzite start button in the image
You can do that as well. For example here is the container file for a traditional build off of uCore, but you can change that to Bazzite:
# Allow build scripts to be referenced without being copied into the final image
FROM scratch AS ctx
COPY build_files /
# Base Image
FROM ghcr.io/ublue-os/ucore
## Other possible base images include:
# FROM ghcr.io/ublue-os/bazzite:latest
# FROM ghcr.io/ublue-os/bluefin-nvidia:stable
#
# ... and so on, here are more base images
# Universal Blue Images: https://github.com/orgs/ublue-os/packages
# Fedora base image: quay.io/fedora/fedora-bootc:41
# CentOS base images: quay.io/centos-bootc/centos-bootc:stream10
### [IM]MUTABLE /opt
## Some bootable images, like Fedora, have /opt symlinked to /var/opt, in order to
## make it mutable/writable for users. However, some packages write files to this directory,
## thus its contents might be wiped out when bootc deploys an image, making it troublesome for
## some packages. Eg, google-chrome, docker-desktop.
##
## Uncomment the following line if one desires to make /opt immutable and be able to be used
## by the package manager.
# RUN rm /opt && mkdir /opt
### MODIFICATIONS
## make modifications desired in your image and install packages by modifying the build.sh script
## the following RUN directive does all the things required to run "build.sh" as recommended.
RUN --mount=type=bind,from=ctx,source=/,target=/ctx \
--mount=type=cache,dst=/var/cache \
--mount=type=cache,dst=/var/log \
--mount=type=tmpfs,dst=/tmp \
/ctx/build.sh
### LINTING
## Verify final image and contents are correct.
RUN bootc container lint
And then the build script (I’ve used tuxracer as an example package)
#!/bin/bash
set -ouex pipefail
### Install packages
# Packages can be installed from any enabled yum repo on the image.
# RPMfusion repos are available by default in ublue main images
# List of rpmfusion packages can be found here:
# https://mirrors.rpmfusion.org/mirrorlist?path=free/fedora/updates/39/x86_64/repoview/index.html&protocol=https&redirect=1
# this installs a package from fedora repos
dnf5 install -y tmux extremetuxracer
# Use a COPR Example:
#
# dnf5 -y copr enable ublue-os/staging
# dnf5 -y install package
# Disable COPRs so they don't end up enabled on the final image:
# dnf5 -y copr disable ublue-os/staging
#### Example for enabling a System Unit File
systemctl enable podman.socket
Anyway, for 100 packages, either would definitely work.
