> BTW on the build system side...I did a spike on this: https://gitlab.com/bootc-org/fedora-bootc/fe

BTW on the build system side...I did a spike on this: https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base
it significantly reduces the "rpm-ostree/ostree stuff" for the "base image from scratch" flow and is way more "container native". It's just a rough draft so far, I haven't tried using it "in anger" like to build a desktop with or anything, but I'm much happer with this as a landing spot than what we have with the existing rpm-ostree YAML bits.

GitLab

bootc-org / fedora-bootc / Fedora Bootc Base · GitLab

GitLab.com

Jj0rge https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base

dreamyuki•4/20/24, 4:40 PM

https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base#adding-arbitrary-content-making-arbitrary-changes
this is interesting, so DNF is being used instead of rpm-ostree?

GitLab

bootc-org / fedora-bootc / Fedora Bootc Base · GitLab

GitLab.com

Robert•4/20/24, 4:41 PM

DNF being used in the "builder" container, which is regular Fedora
This is then packaged as an OCI archive somehow and copied to the scratch image

Jj0rge > BTW on the build system side...I did a spike on this: https://gitlab.com/bootc...

Bigpod•4/20/24, 4:45 PM

i can look into this but yea as far as i know he want to achieve the end in which you deploy oci image without any ostree bits at all

Bigpod•4/20/24, 4:45 PM

what im sitll waiting for is bootupd to be able to do any distro

Bigpod•4/20/24, 4:47 PM

i really want to be able to make some other distros not just fedora

EyeCantCU•4/20/24, 4:48 PM

The build rationale is really comprehensive: https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base/-/blob/main/README-build-rationale.md?ref_type=heads

GitLab

README-build-rationale.md · main · bootc-org / fedora-bootc / Fedor...

GitLab.com

EEyeCantCU I'm thinking two features here, but let's start with one: `just powerwash` and ...

fiftydinar•4/20/24, 4:49 PM

Resetting gsetting is also useful & something I do in my image

Bigpod•4/20/24, 4:50 PM

looking at the containerfile its quite genious and works based on fedora:40 image not some special rpm-ostree image

EyeCantCU•4/20/24, 4:55 PM

Looking at the build scripts and it's brilliant

EyeCantCU•4/20/24, 5:03 PM

This reminds me of how we handle -base-base packages in Wolfi

https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base/-/blob/main/bootc-full/bootc-full.spec?ref_type=heads

GitLab

bootc-full/bootc-full.spec · main · bootc-org / fedora-bootc / Fedo...

GitLab.com

EyeCantCU•4/20/24, 5:04 PM

(but obviously not as clean, but it can't be given they have to work with specs)

EyeCantCU•4/20/24, 5:09 PM

They also have inconsistent pulls from Quay

https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base/-/blob/main/plans/main.fmf?ref_type=heads#L30

Jj0rge > BTW on the build system side...I did a spike on this: https://gitlab.com/bootc...

bsherman•4/20/24, 5:23 PM

forget "significantly reduces" this nearly completely removes rpm-ostree from our consciousnesses regarding image builds!

pretty impressive!

and without using rpm-ostree, it's no wonder that bootc wipes out local package layers installed by rpm-ostree, it's just not part of the paradigm

j0rgeOP•4/20/24, 5:25 PM

yeah

Bbsherman forget "significantly reduces" this nearly completely removes rpm-ostree from ou...

fiftydinar•4/20/24, 5:25 PM

how would the local user uninstall the "dnf" package from this experimental image?

j0rgeOP•4/20/24, 5:25 PM

ugh git submodules, don't like that

Ffiftydinar how would the local user uninstall the "dnf" package from this experimental imag...

bsherman•4/20/24, 5:26 PM

the local user would not.

the entire design is to build images ... you want to customize? you build a new image with the changes

j0rgeOP•4/20/24, 5:27 PM

yeah this is the full move to The Final Shape, you're not bringing all that stuff forward, pure cloud native.

EEyeCantCU This reminds me of how we handle `-base` packages in Wolfi 🙂 - https://gitlab.c...

bsherman•4/20/24, 5:27 PM

i actually think the reuse of spec here is pretty nice... it's well definied... rhel/fedora are very much RPM-centric, so resuing that to compose the whole OS image is cool

EyeCantCU•4/20/24, 5:28 PM

No problems there at all!

EyeCantCU•4/20/24, 5:28 PM

I think it's great

j0rgeOP•4/20/24, 5:28 PM

yeah it lets you skip a step

j0rgeOP•4/20/24, 5:28 PM

like imagine if we're just putting the specs in here

Jj0rge ugh git submodules, don't like that

bsherman•4/20/24, 5:29 PM

i don't read that as "git submodules are required" for custom images... just a possible way if you want to rebuild the world

j0rgeOP•4/20/24, 5:29 PM

file issues and leave feedback, the more we give feedback the less work for us in the future.

Bbsherman i don't read that as "git submodules are required" for custom images... just a p...

j0rgeOP•4/20/24, 5:29 PM

yeah I know I was just in the mood to maybe try it now I'm like, ugh every time I run into those things it ruins an afternoon for me

j0rgeOP•4/20/24, 5:29 PM

then I realized ya'll will do a better job playing with it than me

Robert•4/20/24, 5:29 PM

Pretty sure this pattern isn't meant for us. This is how Fedora is hoping to build their silverbluesilverblue, kinoitekinoite etc images which we then consume in the same way we are now

it significantly reduces the "rpm-ostree/ostree stuff" for the "base image from scratch" flow and is way more "container native".
...
I'm much happer with this as a landing spot than what we have with the existing rpm-ostree YAML bits.

bsherman•4/20/24, 5:30 PM

biggest concern i see, this will be a major paradigm shift for existing Fedora Silverblue users... mostly due to the lack of local layering...
so, politically in Fedora, maybe that's a problem..

but for us, it would be awesome...

I'd love to take a bootc Fedora Silverblue/Kinoite as our foundation for our images... MUCH cleaner

j0rgeOP•4/20/24, 5:30 PM

yeah but also that work is taking forever and basically stalled, I wonder if we can combine this with other work

j0rgeOP•4/20/24, 5:31 PM

fedora will keep the rpm-ostree stuff in a while, I wouldn't worry about that, they're thinking what they have for 2028

j0rgeOP•4/20/24, 5:31 PM

but maybe we can get efficiency wins with fedora-ostree-desktops + main / hwe as "ublue 2.0" or something.

EyeCantCU•4/20/24, 5:34 PM

I've tried to word this as best I can but I'm struggling so I'll keep it short... What if we just built the base images ourselves in this instance? We can help improve this as a base and utilize it as a submodule when we go to build our main images. Completely untether ourselves from ostree-desktops/the official images

j0rgeOP•4/20/24, 5:36 PM

Yeah, I can see use cases for that.

j0rgeOP•4/20/24, 5:38 PM

Like what if main/hwe were just all composed in one step and the bazzifinrora was the first FROM

EyeCantCU•4/20/24, 5:38 PM

I certainly can, especially if aarch64 images are indefinitely on the back burner

EyeCantCU•4/20/24, 5:38 PM

That would be amazing

j0rgeOP•4/20/24, 5:38 PM

a person at github who can help us with arm builders just put bluefin on her laptop.

j0rgeOP•4/20/24, 5:39 PM

it's only a matter of time, we'll get our builders, but it would be nice to ensure we got what we need ahead of time so when we do get them we're not stuck

Jj0rge a person at github who can help us with arm builders just put bluefin on her lap...

Robert•4/20/24, 5:40 PM

I'm sure I've asked before, but cannot remember the answer.
We can build ARM docker images already using the arch: arch: parameter in the build workflows. Is this not suitable for us?

j0rgeOP•4/20/24, 5:40 PM

@bsherman colin seemed to resonate with the coreOS kernel idea and a weekly cadence. But when I mentioned recomposing silverblue from the bottom up he was pretty much "yeah that's a lot of work"

EyeCantCU•4/20/24, 5:41 PM

That would be amazing. Definitely want to make sure we're good to go but unfortunately, it sounds like upstream is in limbo with getting ARM images out the door right now (they have everything set up for it but just aren't building them)

RRobert I'm sure I've asked before, but cannot remember the answer. We can build ARM doc...

EyeCantCU•4/20/24, 5:41 PM

Yeah, I have a PR for this

Robert•4/20/24, 5:41 PM

By "yeah" do you mean it doesn't work? Or we're trying to get it merged?

EyeCantCU•4/20/24, 5:42 PM

It doesn't work because aarch64 images aren't being built upstream

Gerblesh•4/20/24, 5:42 PM

# Phase: pre-install
# Populate the initial rootfs directory; the /workdir is a temporary volume defined to not be on overlayfs
# so that we can e.g. set SELinux labels and file capabilities
RUN --mount=type=cache,target=/var/cache/dnf,z --mount=type=cache,target=/workdir rm -rf /workdir/rootfs && /src/build/install-imagedir /src/bootc-${VARIANT} /workdir/rootfs

# Phase: pre-install
# Populate the initial rootfs directory; the /workdir is a temporary volume defined to not be on overlayfs
# so that we can e.g. set SELinux labels and file capabilities
RUN --mount=type=cache,target=/var/cache/dnf,z --mount=type=cache,target=/workdir rm -rf /workdir/rootfs && /src/build/install-imagedir /src/bootc-${VARIANT} /workdir/rootfs

Niklas ⚡•4/20/24, 5:42 PM

whoah, i feel pressured to do it with that headline

Niklas ⚡•4/20/24, 5:42 PM

lmao

Niklas ⚡•4/20/24, 5:42 PM

i love markdown formatting

Gerblesh•4/20/24, 5:42 PM

Yeah...

> BTW on the build system side...I did a spike on this: https://gitlab.com/bootc-org/fedora-bootc/fe

Similar Threads

Similar Threads

Similar Threads