Looking at https://github.com/ublue-os/main/blob/main/Containerfile, the install scripts will need t

Looking at https://github.com/ublue-os/main/blob/main/Containerfile, the install scripts will need to be replaced by bootc configuration such as https://gitlab.com/fedora/bootc/base-images/-/blob/main/tier-0/kernel.yaml for the base images, and regular dnf commands for downstream images

GitLab

tier-0/kernel.yaml · main · fedora / bootc / Base Images · GitLab

GitLab.com

Iimbev Looking at https://github.com/ublue-os/main/blob/main/Containerfile, the install...

antheas•8/15/24, 4:51 PM

https://gitlab.com/fedora/bootc/base-images/-/blob/main/tier-0/kernel.yaml this is rpm-ostree stuff

Aantheas the way they build the base image is very complicated

imbevOP•8/15/24, 4:51 PM

include this.yaml, include that.yaml

antheas•8/15/24, 4:51 PM

youre not meant to use as an end user

antheas•8/15/24, 4:51 PM

because everyone here was like no

antheas•8/15/24, 4:51 PM

i aint using that

antheas•8/15/24, 4:51 PM

lmao

antheas•8/15/24, 4:51 PM

i had suggested it

Aantheas https://gitlab.com/fedora/bootc/base-images/-/blob/main/tier-0/kernel.yaml this ...

imbevOP•8/15/24, 4:51 PM

really? I expect that'll make migration easier

antheas•8/15/24, 4:52 PM

Colin found his niche, people like containers, so everything is a container now

antheas•8/15/24, 4:52 PM

and the treefile stuff went out the window

Robert•8/15/24, 4:52 PM

Timothee currently maintains that rpm-ostree compose stuff, and will eventually move over to the bootc base images when things like local layering is sorted
So the raw compose files will hopefully always be abstracted away from us

KKyle Gospo https://github.com/ublue-os/main/

imbevOP•8/15/24, 4:56 PM

Does that handle all of ublue configuration? Or is that only for base images?

Iimbev Does that handle all of ublue configuration? Or is that only for base images?

Robert•8/15/24, 4:57 PM

This is just the base images. So basic hardware enablement and unopinionated changes.
More opinionated images (Bluefin/Bazzite) use the images built in ublue-os/main as base images in their containerfiles

FROM ghcr.io/ublue-os/silverblue-main:40
COPY <bluefin-files>
RUN rpm-ostree install <bluefin-packages>

FROM ghcr.io/ublue-os/silverblue-main:40
COPY <bluefin-files>
RUN rpm-ostree install <bluefin-packages>

RRobert This is just the base images. So basic hardware enablement and unopinionated ch...

imbevOP•8/15/24, 4:59 PM

Ok. Is there anything preventing usage of dnf within the downstream Containerfiles?

antheas•8/15/24, 4:59 PM

yeah, an error condition

antheas•8/15/24, 4:59 PM

but other than that theoretically nothing

imbevOP•8/15/24, 5:00 PM

A migration to bootc would make that possible instead of using rpm-ostree installrpm-ostree install

antheas•8/15/24, 5:00 PM

something in fedora-bootc enables it

antheas•8/15/24, 5:00 PM

which is not done if the image comes from the other repos

antheas•8/15/24, 5:01 PM

if you do that dnf will work in your image

antheas•8/15/24, 5:02 PM

bootc is broadly a rebrand of the portfolio, rpm-ostree installrpm-ostree install is a reimplementation of dnf installdnf install when running in a container

antheas•8/15/24, 5:03 PM

the problem with building base images using OCI is preserving permissions

antheas•8/15/24, 5:03 PM

until ubuntu 24, containers used to crap on permissions so the image would not work afterwards

antheas•8/15/24, 5:03 PM

but now that is much less of a problem if you use a recent podman

Iimbev Ok. Is there anything preventing usage of dnf within the downstream Containerfil...

fiftydinar•8/15/24, 5:03 PM

dnf5dnf5 appears to work in a Containerfile, but can't guarantee if there are some micro-issues with it, like with missing SeLinux labels, permissions & such

antheas•8/15/24, 5:04 PM

every selinux label you add in a container is thrown away

antheas•8/15/24, 5:04 PM

when it is deployed

antheas•8/15/24, 5:04 PM

permissions-wise, recent podmans are good but there are quirks there

Iimbev Does that handle all of ublue configuration? Or is that only for base images?

j0rge•8/15/24, 5:04 PM

can someone paste in the architecture diagram for imbev? sorry in a call

j0rge•8/15/24, 5:05 PM

@Kyle Gospo jeefy at work is like "aww ublue, how cute."

j0rge•8/15/24, 5:05 PM

^^^ CNCF's runners firing on all cylinders today

imbevOP•8/15/24, 5:06 PM

What I'm seeing as a difference is that ublue is using ostree container commitostree container commit for each layer of the image, while bootc-derived images are able to use the Container's own layers without that step.

Iimbev What I'm seeing as a difference is that ublue is using `ostree container commit`...

Kyle Gospo•8/15/24, 5:07 PM

not required, that was a recent change

Kyle Gospo•8/15/24, 5:07 PM

that just does some cleanup prior to layer generation, such as wiping out temporary files

antheas•8/15/24, 5:08 PM

ostree container commit cleaned var essentially

Jj0rge can someone paste in the architecture diagram for imbev? sorry in a call

AfterStory•8/15/24, 5:08 PM

https://universal-blue.discourse.group/docs?topic=1523

Universal Blue

Architecture Diagram

Hadn’t heard of that specifically, but had herd of similar projects. Didn’t use one, because I didn’t have time to learn one, and I think the results would be less aesthetically pleasing.

antheas•8/15/24, 5:08 PM

if you use rechunk it will also clean var so you dont need it

antheas•8/15/24, 5:09 PM

i should try to build kinoite using "from fedora"

antheas•8/15/24, 5:09 PM

that would be a flex

antheas•8/15/24, 5:09 PM

future plans

imbevOP•8/15/24, 5:17 PM

I'm thinking of the following:

Refactor ublue-os/main to FROM quay.io/fedora/fedora-bootc:VERFROM quay.io/fedora/fedora-bootc:VER, replace rpm-ostree calls with standard dnf calls. There're a few hacks that need to be done with bootc, but it can otherwise be treated like mutable fedora most of the time within the Containerfile
Refactor downstream images in the same way
The rest might be able to be reused as is

imbevOP•8/15/24, 5:18 PM

Would a branch or strangler strategy be preferred?

Iimbev I'm thinking of the following: - Refactor ublue-os/main to `FROM quay.io/fedora...

Robert•8/15/24, 5:18 PM

We could, but then we have the added burden of managing package lists for Gnome, KDE etc, which we don't currently do
Right now, we just FROM quay.io/fedora-ostree-desktops/{silverblue|kinoite|something}:VERFROM quay.io/fedora-ostree-desktops/{silverblue|kinoite|something}:VER and it's all managed by others

imbevOP•8/15/24, 5:20 PM

Is there a significant difference between the atomic desktops and the mutable variants using the corresponding package group other than the immutability?

Iimbev Is there a significant difference between the atomic desktops and the mutable va...

Noel•8/15/24, 5:21 PM

Timothee would be a good one to ask on that. He is in Matrix in the Atomic desktops channel.

Noel•8/15/24, 5:21 PM

I don't see him too often in here.

Iimbev I'm thinking of the following: - Refactor ublue-os/main to `FROM quay.io/fedora...

j0rge•8/15/24, 5:23 PM

hah yeah this is what we're supposed to be doing, we got some repos we cloned as main-bootc, hwe-bootc, etc but I don't think we're using them

j0rge•8/15/24, 5:24 PM

I'm not sure if we need to have a ton of new repos, we could just opportunanistically snag swap the common ones like gnome/kde, as those come online.

Jj0rge I'm not sure if we need to have a ton of new repos, we could just opportunanisti...

imbevOP•8/15/24, 5:26 PM

It'd be simple to switch the base image and remove a dnf groupinstalldnf groupinstall once upstream Fedora produces them

j0rge•8/15/24, 5:27 PM

how's the tool song go? save us from our wanton slumber?

Looking at https://github.com/ublue-os/main/blob/main/Containerfile, the install scripts will need t

Similar Threads

Similar Threads

Similar Threads