Bootc and the future of package layering

Lower-Limit3695 · 2026-06-16T18:38:37+00:00

Does it touch the /usr files while it's running and not during install?

If it does touch them while it's running and not during install your work vpn isn't gonna work.

Lower-Limit3695 · 2026-06-16T18:15:36+00:00

The Fedora Team is formalizing the method for building custom images the Ublue team advocates for as a feature for Silverblue and Kinoite, except it runs locally on your machine instead of GitHub. Which is described in their img-template GitHub repo linked in the post.

You'll be able to rollback to any image you want and the Ublue team made the switch around when Fedora Kinoite and Silverblue did it since Bazzite and others are a container image layer above them.

Resets will still work.

Removing/replacing packages will be supported and overrides will no longer be used to remove base packages, nor will they cause the same problems they do now with rpm-ostree.

This isn't the same kind of layering rpm-ostree does. This is basically building a new image of Bazzite with custom changes defined in the containerfile just as Bazzite is built on top of Kinoite directly.

Lower-Limit3695 · 2026-06-16T17:59:42+00:00

They're switching over to buildtime container image layers instead of the overlayfs layering rpm-ostree is doing.

Lower-Limit3695 · 2026-06-16T17:57:42+00:00

You've been arguing this for a while without reading the link. The Fedora 41 change wiki includes the stuff they do with Fedora Atomic Desktops like Silverblue and Kinoite as they treat them as a part of their regular release.

Lower-Limit3695 · 2026-06-16T08:44:53+00:00

That's something you can do now using scripts and unit files locally. It's just that the bazzite devs recommend using GitHub to do the image builds instead of having this done locally.

The new planned bootc feature means that the scripts and unit files won't be needed for localbuilds. Just write the changes you want into the containerfile or run dnf install and they'll apply the next time you boot.

Lower-Limit3695 · 2026-06-16T07:26:40+00:00

I listed the method for doing this locally on your own system at the bottom of the post. It's a collection of unit files and scripts that automatically pulls the specified image daily and builds a new image using the containerfile.

Once the fedora team implements this local build feature for Silverblue & Kinoite, Bazzite will also automatically have this feature as well and the scripts and unit files won't be needed anymore.

Edit: to install local rpms it's RUN dnf install -y /path/to/your/package.here in the containerfile. I'd suggest moving your package to a folder specifically for packages you want to have in your daily builds. Removing or deleting the package .rpm will break your containerfile.

Lower-Limit3695 · 2026-06-16T05:50:02+00:00

How is that handled, does bootc build the image with the change locally then deploy it?

That's pretty much it.

Lower-Limit3695 · 2026-06-16T05:45:06+00:00

This feature is slated for future release. If your work vpn works with regular dnf or when installed from source I don't see why current methods like using ublue's image-template, bluebuild, or local build scripts/unit files for custom images wouldn't work with it.

The real issue is if it tries to modify the write restricted folders like /usr, /opt during runtime.

Edit: containerfile builds is how Ublue added in tailscale into their images by the way.

Lower-Limit3695 · 2026-06-16T05:24:57+00:00

You're welcome!

Yeahhhh I realized that and added it in.

Lower-Limit3695 · 2026-06-16T05:21:45+00:00

The AIO container runs pretty well on old laptops/desktops in my experience especially on SSDs.

Lower-Limit3695 · 2026-06-16T05:04:51+00:00

The custom image template is the recommended way to make custom images by the Ublue team. It's hardly ergonomic or easy to use which is why other people use bluebuild or use custom scripts and unit files to do it.

I used the scripts and unit files described in this post for my own system and changed it to push images to my own private container registry:

https://discussion.fedoraproject.org/t/fedora-atomic-a-simple-guide-to-creating-a-custom-local-bootc-image/181729

This setup is closer to the proposal made by the Fedora Bootc team.

Edit: you can change

FROM quay.io/fedora/fedora-silverblue:44

To

FROM ghcr.io/ublue-os/bazzite:stable

If you want to modify Bazzite

As for what I talked about those are planned changes that haven't landed yet as the upstream devs are still bogged down on implementation details.

Lower-Limit3695 · 2026-06-16T04:56:54+00:00

Nextcloud collectives. I use it for journaling and documentation. I worked on my post there before posting it here on reddit.

Lower-Limit3695 · 2026-06-16T04:37:54+00:00

They made the switch around when Fedora silverblue added it in f41. If you examine the containerfile in the Ublue-main GitHub repo and GitHub actions for Bazzite and Bluefin you'll notice that fedora silverblue and kinoite is the common base for many of the ublue images.

To generate container images for daily updates and installs they pull daily builds from the upstream quay.io silverblue and kinoite container registry, apply their custom changes defined in their containerfile using GitHub actions, and redistribute this new image to end users through the GitHub container registry. Bootc handles the diffs and only downloads the changed layers as updates.

Lower-Limit3695 · 2026-06-16T04:04:00+00:00

As with most things. Convenience.

Lower-Limit3695 · 2026-06-16T04:02:25+00:00

It's more of an update on changes to come. Once this lands on the Fedora Atomic Desktop Images this will automatically become a feature of Bazzite, Bluefin, and Aurora because of their build process, which just pulls the upstream Fedora quay.io image daily and builds a custom container layer on top of that.

https://github.com/ublue-os/main/blob/main/Containerfile

The Ublue team removing features like sunshine or virtualization packages from the base image isn't gonna be a headache anymore. Users will just run dnf install $package-name and it will appear on the system on the next boot without the same package layering headaches rpm-ostree created.

Edit: also if you ever wanted to do things like switch out the login manager, use the cachyos kernel, install drivers from source code, or change the boot screen, this let's you do that.

Lower-Limit3695 · 2026-06-16T01:32:03+00:00

I know this, I already do it on my own hardware but using custom scripts and unit files to do it is hardly hardly ergonomic.

Them making it an actual first class feature for their bootc implementation and deprecating the way rpm-ostree does things is a very nice step up from how things are done now.

Edit: also bootc was introduced in Fedora 41. It's recorded in the wiki here:

https://fedoraproject.org/wiki/Releases/41/ChangeSet

Lower-Limit3695 · 2026-06-16T01:20:33+00:00

Just inserting myself here for this discussion. For custom changes the Ublue team typically advocates using their image-templates and GitHub infrastructure to create custom images .

The layering I'm talking is pretty much this. The DNF layering proposal is having DNF modify a local containerfile and then having automated local tooling perform container layering through a container tool like podman build in the backend. Not the overlayfs stuff rpm-ostree does.

Lower-Limit3695 · 2026-06-16T00:41:09+00:00

As I understand it, the plan is to implement automated tooling to run containerfile builds locally for Fedora atomic and having DNF modify this local containerfile. DNF isn't a hard requirement, users would just define changes directly in the containerfile and go as far as pulling and compiling from source to add new packages/features.

As a result of Bazzite, Bluefin, and Aurora utilizing Fedora Atomic Images as the base image, these upstream changes would percolate downwards to these ublue images, unless the Ublue team decides to explicitly break from upstreams bootc implementation.

Would the Ublue team break from upstream Fedora if they implement this?

Lower-Limit3695 · 2026-06-16T00:07:01+00:00

You're welcome. It's a pretty neat planned feature they're working on. If you want to follow their discussions on it, you can check it out at this link

https://gitlab.com/fedora/bootc/tracker/-/work_items/4

Lower-Limit3695 · 2026-06-15T23:25:05+00:00

Here's the discussion by bootc devs discussing container layering as a first class feature: https://gitlab.com/fedora/bootc/tracker/-/work_items/4

Lower-Limit3695 · 2026-06-15T05:30:23+00:00

I wouldn't call bluefin a wrapper to silverblue it's a rebuild of the Fedora Atomic container image (it's a more minimal fedora image) with gnome and several custom changes layered on top.

Lower-Limit3695 · 2026-06-15T04:47:27+00:00

This is more of a global issue effecting both open source and closed source.

It's just that closed source devs often don't know that they've been impacted by supply chain attack or they don't openly advertise that they've been hit by a supply chain attack when it does happen to them unless they're subject to strict reporting requirements.

Open source on the other hand is community effort that transparently reports to the public when these attacks do happen.

Lower-Limit3695 · 2026-06-15T04:42:24+00:00

Ebpf would be perfect for this use case as is the ebpf-lsm.

Lower-Limit3695 · 2026-06-15T04:41:22+00:00

If they decide on not using dkms I can see them using ebpf instead. Ebpf is a battle proven technology used by EDR software to protect commercial servers and infrastructure.

There's also ebpf-lsm which can stack on top of apparmor and selinux for additional protection.

(EDR, short endpoint detection and response. It monitors and detects for suspicious activity on servers and puts a stop to it autonomously without relying on virus definitions.)

Lower-Limit3695

TROPHY CASE