Questions about bootc and rpm-ostree

Hi Fedora Developers,

Some questions about bootc and rpm-ostree:

  1. Will bootc completely replace rpm-ostree or will the work in conjunction?
  2. Is bootc built in such a way that it can work with version controlled systems like rpm-ostree as with A/B systems like systemd-sysupdate?
  3. In rpm-ostree you add a package to the system by layering. Will this replaced by a local containerfile in which you add the package to be installed? In the latter, the system has to be build locally. I guess this is not desirable because it takes a lot of time?
  4. I read that several tools will be integrated in dnf. Will we use dnf commands in the future instead of bootc and rpm-ostree?
  5. And to be sure: with bootc the container image is converted to a (local) disk image so no virtualisation is necessary? Podman-bootc is only used for testing the image/container?
  6. Does bootc download the complete new version of the operating system or does it download some kind of delta file? Or does it download a new layer (but to be honest, I don’t know what a layer really means in this case).

Thanks for clearing things up :slight_smile: !

1 Like

I’m not a Fedora dev, but I’ve been asking similar questions as you. Here’s what I’ve been able to gather:

rpm-ostree will be replaced by bootc and dnf5 for the most part eventually I think. bootc to manage the container management tasks. And dnf5 to manage package layering. Though for now dnf5 doesn’t do layering and bootc can’t manage the containers if there are any packages layered. So rpm-ostree will be needed until these kind of things are worked out.

I don’t think it would take a lot of time. You can basically do this locally by creating a Containerfile with a RUN dnf install foo, and build the container. It should basically take the same time as running the dnf command.

The containers are able to be divided up into chunks and so only the necessary ones are downloaded. So though this reduces the size compared to needing to download the entire container image, I think it still uses more data than the current rpm-ostree upgrade on non-container atomic systems.

$sudo bootc upgrade
layers already present: 43; layers needed: 22 (1.2 GB)
Fetched layers: 1.13 GiB in 2 minutes (8.07 MiB/s)
Queued for next boot: quay.io/fedora-ostree-desktops/kinoite:41
  Version: 41.20240923.0
  Digest: sha256:39e4f04522adcae099caffcea28fd51ce12c78af2ccb5e47d2e6baafa8303626
Total new layers: 65    Size: 2.8 GB
Removed layers:   22    Size: 1.2 GB
Added layers:     22    Size: 1.2 GB
1 Like

I’m also not a Fedora developer, although I have some contributions to the project.

Here are some additions to the answers from the previous post.

I’m not sure what you mean by ā€œ(local) disk imageā€, but to run a container native (bootc) Fedora OS you’ll most likely need to convert a bootable container into a so-called disk image, such as ISO, raw or qcow2 to provision a new system. You can convert a bootable container into a disk image with the bootc-image-builder which itself needs to be executed inside a container. podman-bootc allows you to easily run a local bootc image in a VM and get shell access to it. Under the hood, podman-bootc uses bootc-image-builder to create a disk image that is subsequently used to create and boot a VM.

Hello @guiltydoggy,

Thank you very much of the information!!
1.2 GB for a update is quite large. Hopefully they will be able to bring that number down!

Hello @hricky,

Yes, with a disk image I indeed meant a disk image like iso, raw or qcow2.

ā€˜which itself needs to be executed inside a container’

Sorry, I don’t completely understand what you mean: do you mean that bootc-image-builder runs in it’s own container, or do you mean that it needs to be run in the container that is being downloaded during an upgrade?

Thanks for the information!

bootc-image-builder is a container and must be executed using the sudo podman container run command.

Ah, thanks, that’s clear!!

Hello Everybody,

I have one more question:
Will it be possible with bootc to overlay packages and if so, how?

Will it be something like dnf install [application name] or will the user have to modify a local container file? I guess the first solution is preferable. How will it work in the background? Is this already determined or not? And I guess it will still be needed to reboot the system after the installation of the new package? Will this all work in Fedora 42?

Thanks in advance :slight_smile: !

No, the bootc install command installs the running container to a target.

This has already been basically answered in a previous post.

The bootc and rpm-ostree projects share a significant code base.

Currently, for Fedora CoreOS and Fedora Atomic Desktops, local package layering support is achieved via rpm-ostree. In the longer term, there are plans to extend dnf to support client-side functionality as well.

A top-level goal of bootc is to encourage a default model where Linux systems are built and delivered as (container) images.

Not yet.

Right now, the rpm-ostree install --apply-live command will perform a subsequent apply-live operation to apply changes to the booted deployment. I am not sure if this functionality will be implemented in dnf if such an approach is chosen.

There’s still a lot of work to do, so I’m not sure.

1 Like

As the underlying concept is completely different to a package based variant, the flow differs significantly but lets put the focus at result.

Here is a POC

that allows to install packages (transiently) and it generates locally an image the gets staged and booted then (package persistence). So, under the hood quite ā€œexpensiveā€ but possible.

IIRC, this is what DNF5 should do in the future, but let others that work on this explain this in more detail.

Thanks interesting!

The local layering story is not decided / flushed out yet: Local package layering story with bootc & dnf5 (#4) Ā· Issues Ā· fedora / bootc / Issue Tracker Ā· GitLab

I’m also working on support for systemd sysexts as an alternative that would be bootc managed as well: GitHub - travier/fedora-sysexts: Example sysexts for Fedora image based systems

2 Likes

Ahm thanks, so it’s not clear at the moment!

Do you think this is something that would be solved before Fedora 42?

I think it’s a important use case, because a regular users still needs to layer packages because not everything is or can be delivered as a Flatpak.

We are well aware of that :slight_smile:. rpm-ostree is not going away until we have a solution for that.

2 Likes