I would be very interessed in this. Is there a way I could 'convert to' or replicate Silverblue behaviour after installing the current Fedora in the meantime?

@genesys5 I would be willing to act as a mentor to assist you completing this work, do you have an Apple Silicon Mac machine you are willing to iterate on?

There is no convert to Silverblue functionality, there are drastic differences between a Silverblue image and a non-immutable image. We would have to create a brand new image from scratch.

I don't have sufficient hardware to iterate on and reimage as my sole piece of hardware is actively used for Automotive work.

I recently got this working on another not-so-standard piece of hardware so it's somewhat familiar in my mind.

Whoever completes this would need to have knowledge of (or be willing to learn) osbuild or kiwi, C/Rust, python, yaml, shell scripts, systemd, ostree, rpm-ostree, containers, dracut, git...

We have ported ostree-based Automotive CentOS Stream distribution to quirkier platforms than this so it should not be too bad for someone that has the cycles (have to focus back on Automotive work)

Hi Eric, I'm one of the co-maintainers for Universal Blue's custom Fedora images: https://universal-blue.org/

Thanks for reaching out in our Discord, happy to continue the convo async in this tracker. We are very interested in providing builds of everything we have based on Asahi's work. Here's what we have and what we've tried:

• https://gitlab.com/fedora/ostree/ci-test

This is run by Timothee Ravier, and since don't have an upstream image we figured we would try to build these. We met with him and we were able to successfully build a test image of silverblue. However we were only able to get the build process to use 1 CPU core. We tried a few options, LXC/LXD, and even raw firecracker but this is where we got stuck as we'd need parallel builds.

Our builder is an 80 core Ampere builder via Equinix's Open Source program. Once we got the builds up and running our intent was to just publish upstream vanilla versions of images as well as a community service since it makes more sense to build it all in one go. Our plan was to turn the instance on, build all of the vanilla images, build all of the Universal Blue images with all the desktops, push the images to the registry, then turn it back off on a 24h schedule. We have a great relationship with Equinix and would be totally up for consolidation of resources around a Fedora-run SIG. I'd be happy to make introductions with that team if it helps.

Additionally we don't have the lorax/anaconda technical expertise to get true offline ISOs, we're misusing the kickstart functionality to make online installers. We think we're close to getting it, and I think it's just a matter of having someone who knows the stack telling us what to do.

Hi Eric,

I’m a Universal Blue contributor as well. I am a software engineer at Amazon as my day job and I have many of the skills listed in your previous post. I also happen to own a MacBook Air M2.

I would love to help with any efforts to get this going. I’m not sure I could take on the project due to lack of time but I still want to make myself available as much as possible.

I am currently working on assembling the offline ISOs mentioned by Jorge and with some help to solve this problem I would love to move onto some Asahi work :-)

Additionally we don't have the lorax/anaconda technical expertise to get true offline ISOs, we're misusing the kickstart functionality to make online installers.

This is ok, I think it's ok to treat anaconda and .iso's as a separate effort, we don't have anaconda or .iso support for the other variants yet either.

https://pagure.io/fedora-asahi/project/issue/9

But besides that:

A nice simple example of creating a ostree-based distro using ostree would be our Automotive variants:

git clone https://gitlab.com/CentOS/automotive/sample-images.git
cd sample-images/osbuild-manifests
make cs9-rpi4-minimal-ostree.aarch64.img # makes autocomplete would give you an idea of how many formats we can theoretically build, even "f38" ones

you could fork, use as a reference etc. whatever you want.

Also, recommend examining our existing images and how kiwi builds them.

https://fedora-asahi-remix.org/builds.html

There's a list of packages that are different, alsa-ucm-asahi, asahi-fwextract, dracut-asahi, update-m1n1, kernel, mesa, u-boot, etc.

I would recommend to try stuff and when you get stuck reach out @castrojo and others! We probably will have to make some changes to make things ostree-compatible, but we will get there.

Hi, I started digging into the existing KIWI descriptions for Fedora Asahi Remix

1. I was able to create a Fedora Asahi Remix OSTree image (container and ostree repo) and boot into in a VM running on my Macbook Air M2
2. I don't know how to use KIWI so I just used rpm-ostree compose
3. My next step would be to understand this script so that I can come up with an equivalent to create the installer payload

I put my treefiles in this repo: https://pagure.io/fedora-asahi-remix-ostree/tree/f39

You'll want to switch to the kernel-16k variants of the kernel packages at least.

Which is basically this:

rpm-ostree override replace --experimental --from repo='copr:copr.fedorainfracloud.org:group_asahi:kernel' kernel-16k kernel-16k-core kernel-16k-modules kernel-16k-modules-core kernel-16k-modules-extra
rpm-ostree override replace --experimental --from repo='copr:copr.fedorainfracloud.org:group_asahi:mesa' mesa

If you can boot a vm version:

https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/#_booting_on_a_local_hypervisor_libvirt_example

Then it should be possible to extract those partitions as .img files and flash them into the corresponding block devices on macOS, reboot to see how it goes!

RPM-OSTree will also need to support rpm repo priorities and sticky vendors, or otherwise things will break fairly often.

I have written another "incomplete" version of this:

https://github.com/ericcurtin/silverblue-asahi/blob/main/Containerfile

There's a couple of ways of going about this.

You can survive without repo priorities and sticky vendors if you keep everything in the:

quay.io/fedora-asahi/fedora-silverblue:39

(this namespace doesn't exist of course yet) base layer.

Since you can just rely on the Containerfile order or in the case of akdev's solution the order the packages are installed there.

I finally got a Macbook Pro and did some initial work for this and I now have Kinoite running!