Is ublue infrastructure compatible with bootc yet?
Is ublue infrastructure compatible with bootc yet?
Xublue actually shipped bootc for a moment a while back, but i believe it caused some issue and had to be reverted
Xin my own testing, though, it worked perfectly
ABroke the ISOs
AAnaconda moment
Jyeah we can move to bootc, the biggest issue is waiting for fedora bootc images but looks like the EL folks got those rolling faster than fedora
IThe main obstacle that I see right now is the lack of integration with GNOME Software and the rest of the GUI package managers
Kwe remove rpm-ostree integration from GNOME software today
Knot really an obstacle
Kit slows it down to a crawl and makes it into a terrible experience when it's present
IIn that case, I don't see why it wouldn't work
IThe Fedora images are being produced, however the F40 image is not regularly built IIRC. There are a few projects building personal Fedora bootc images
IIf you take a look at https://github.com/AlmaLinux/bootc-images, it's not too difficult to build a base image
Atheres no such thing as a "bootc" base image yet, if you look under those images you can see theres a little ostree commit in there made by rpm-ostree
Aunless something changed
A
Ibootc uses ostree under the hood
Ayeah
Abut for building images rpm-ostree is still used
IIt's the delivery method that's different
IBy base image, I mean an image that downstream bootc images can
FROM image fromAyeah but the old ones that we use are bootc images with that definition
NI thought fedora-bootc was building from scratch containers as well? Meaning there is no rpm-ostree step in the process
ICan you send a link to early attempts at ublue bootc?
N@Robert (p5) would for sure have those links.
NHe's also been attending the Fedora bootc initiative meetings more regularly than I have.
NIf you have time on your schedule, it would be cool to get more people going to that!
Acurrently the only projects that can produce base images are rpm-ostree and rechunk
RI don't think we've been doing any ublue-specific investigation for bootc images, but I've got some personal attempts for KDE and GNOME base images here
https://github.com/rsturla/fedora-bootc-base
When I left the repo 3 months ago, they booted into a desktop but had one or two services starting when they shouldn't be.
https://github.com/rsturla/fedora-bootc-base
When I left the repo 3 months ago, they booted into a desktop but had one or two services starting when they shouldn't be.
Athis is what my research lead me to at least
Auntil the podman PR merges for bootc, both bootc and rpm-ostree can only pull images that contain an ostree commit
Aand that commit can only be created by rpm-ostree, if you want it to be chunked
Awell that used to be the case before rechunk at least
IMisclick 
NIt's my understanding that bootc is not replacing OSTree, it's replacing rpm-ostree with itself and DNF?
Arpm-ostree has 2 components in it
IThat's my understanding also
Aan image builder and a deployer
RTo begin with, bootc will call rpm-ostree. Then rpm-ostree should be replaced by dnf
Anobody has replaced the image builder yet
NCan't you just use OSTree to build that object and add it to a scratch container?
NJust OSTree, not rpm-ostree.
IOverall, rpm-ostree is used in several important projects and will continue to be maintained for many years to come.
However, for use cases which want a "pure" image based model, using bootc will be more appealing. bootc also does not e.g. drag in dependencies on libdnf and the RPM stack.
bootc also has the benefit of starting as a pure Rust project; and while it doesn't have an IPC mechanism today, the surface of such an API will be significantly smaller.
Further, bootc does aim to include some of the functionality of zincati.
But all this said: It will be supported to use both bootc and rpm-ostree together; they are not exclusive. For example, bootc status at least will still function even if packages are layered.
N@Robert (p5) what was the issue we were having with anaconda? I thought @M2 and I sorted that out a while back.
NIf bootc and rpm-ostree can live in harmony, we should look at adding it back to the images again.
IYes, although rpm-ostree is the only method currently used that I'm aware of
RIt was Bootc Image Builder was too opinionated, and skipped the interactive installer.
Unless I'm thinking of something else
Edit: Oh, I am thinking of something else. Not sure
Unless I'm thinking of something else
Edit: Oh, I am thinking of something else. Not sure
Aostree-rs-ext is responsible for converting an OSTree commit to an OCI image
Aand right now only rpm-ostree extends it, to a non-trivial degree
Ibootc-image-builder appears to be focused on an automated use case, e.g. VMs
