Thanks for sharing your experience, do you mind sharing your dockerfile somewhere? I’m planning on doing this myself with a github action to see how it goes!
1 Like
I have the containerfile available in a GitHub repo (link below). It also has a mechanism for triggering new builds in quay.io. Although it works, it’s a real hack job and would really benefit from an “official” build trigger.
1 Like
@jlebon blazed a trail with a “pet” toolbox container that is updated every week via GitHub Actions - GitHub - jlebon/pet: Pet container for hacking on CoreOS
I took that idea for updating the container regularly and make a custom FCOS build using the ostree native containers to layer on an Image Builder install. The image is updated weekly and pushed to quay.io
The more I play with this the more I am thinking the opposite direction, it commoditizes custom builds!
I had been struggling with getting ostree-pitti-workstation going because I had never used anything like that before. Now I can reuse all my existing cloud knowledge (and existing documentation!) all the way to my client. My image built on the first try and I haven’t written a dockerfile in years. I’m looking forward to seeing how people customize stuff.
2 Likes
Follow on question for the folks working on this (If I should split this into a new topic please let me know):
I’m thinking if someone did a:
FROM silverblue:37
RUN "install rpmfusion and nvidia drivers"
And then just published the image, would that work how I would expect it to? Am I correct in assuming that if there was skew in whatever the nvidia driver and the kernel are would just result in a failed CI build, there wouldn’t need to have any of this ever hit my client, it would just stay on the last working build?
Also are there any limitations to what I can put in there? What happens if I slurp in a random ansible “set up my desktop” playbook? (Sorry been on the road with spotty internet so haven’t had a chance to go as deep as I’d like just yet!)
The official images produced by the Fedora infra are time based: they are composed everyday.
The temporary CI that have setup is also time based.
1 Like
That should work. You would also probably want to include the fedora archive repo to get older kernels to keep NVIDIA drivers working.
That would get you an updated system excepted the kernel.
1 Like
But not every input (mostly RPM) to those images change every day. rpm-ostree compose image (what we are/should be using to generate base images) has correct change detection.
1 Like
Yes! That’s really a big part of the idea. See layering-examples/build-zfs-module at main · coreos/layering-examples · GitHub which is an example of building custom kernel drivers. Or, one could directly install pre-built drivers too!
If you can dream of it, we’ll try to support it 
1 Like
Worth passing along that @walters is maintaining a Silverblue container image via this repo GitHub - cgwalters/sync-fedora-ostree-containers
Anyone interested in deriving from Silverblue can do FROM ghcr.io/cgwalters/fedora-silverblue:37
I hope that we start publishing more “official” Silverblue container images on the Fedora registry or the like.
1 Like
Right, that’s Issue #11047: generate ostree containers for silverblue, iot - releng - Pagure.io and I did PR#11120: Preparatory cleanup bits for work on https://pagure.io/releng/issue/11047 - releng - Pagure.io to try to get some momentum here, but…no review after a month 
1 Like
Thanks everyone for the links, here’s my workflow file if it helps someone else, I was looking to just keep everything in github:
3 Likes
Inspired by Jorges stuff I also tried this and it works nicely (this from a guy that has never even touched docker etc).
One thing I am having problems is using a specific “custom kernel” for my Asus laptop.
For this specific model to get all the “bells and whistles” working, I would need to use this kernel: lukenukem/asus-kernel Copr until 6.1 lands in near future.
I have been trying to look at the layering example for replacing the kernel. I can get the image to build fine on github but after ostree update, I get stuck in a black screen during boot.
I have used these commands previously to replace the kernel in “normal” Silverblue:
sudo wget https://copr.fedorainfracloud.org/coprs/lukenukem/asus-kernel/repo/fedora-37/lukenukem-asus-kernel-fedora-37.repo
sudo rpm-ostree override replace --experimental --from repo=copr:copr.fedorainfracloud.org:lukenukem:asus-kernel kernel kernel-core kernel-modules kernel-modules-extra
1 Like
akdev posted this in the fedora discord doing nvidia drivers:
after creating a couple custom images we realized /usr/bin/ld seems to be missing from any of them
I double checked our upstream image and it seems that it is also missing from there.
$ podman run --rm -it --entrypoint /bin/bash ghcr.io/cgwalters/fedora-silverblue:37
bash-5.2# ld
bash: ld: command not found
bash-5.2#
unsure where to report this issue so pinging here for awareness
It’s a development tool so it’s not included in the OS images by default.
ah that explains it for the stock image (I assumed binutils was installed by default), but it is still missing when I explicitly install binutils in my custom image
$ podman run --rm -it --entrypoint /bin/bash ghcr.io/akdev1l/ostree-images/fedora-nvsb:latest
bash-5.2# rpm -qf /usr/bin/ld
binutils-2.38-25.fc37.x86_64
bash-5.2# /usr/bin/ld
bash: /usr/bin/ld: No such file or directory
binutils is installed so /usr/bin/ld should be present but it isn’t. Is it unsupported to have /usr/bin/ld in all images? A user tried to rebase to my image and it broke their other unrelated kmod packages as they can’t build if there is no linker (if someone can guide me to the right place for this discussion if this isn’t it, I would appreciate it!)
This is unexpected indeed. Can you file an rpm-ostree issue with a reproducer?
I would use either Tracker for ostree native container conversion · Issue #359 · fedora-silverblue/issue-tracker · GitHub or individual issues in the Silverblue issue tracker: GitHub - fedora-silverblue/issue-tracker: Fedora Silverblue issue tracker
2 Likes