pre-RFC: Rebasing Silverblue on CoreOS

Desktop Silverblue
#1

Hi, in the background I’ve slowly been working on

The idea here is that basically CoreOS becomes the base of Silverblue - and ideally IoT as well. More components besides rpm-ostree are shared, including Ignition and zincati (for IoT and maybe Silverblue).

There’s a whole lot of implications to this of course; some things get worse, others get much better. One of those things that IMO is much better is how much easier it is to do custom builds (both for testing fixes and truly custom forks) with https://github.com/coreos/coreos-assembler
which is opinionated tooling that works with rpm-ostree and also knows how to build and test disk images (the most relevant of which is a Live ISO).

Just putting this out there now for more visibility and discussion. I am actually using this locally from local builds; I haven’t uploaded pre-built disk images online yet, though it wouldn’t be hard to do.

5 Likes
Kinoite, a KDE (and now XFCE) version of Fedora Silverblue
Kinoite, a KDE (and now XFCE) version of Fedora Silverblue
#2

In the specific what will/might get worse?

Are there some “for dummies” instructions to test out FCOSB composing?

I see https://github.com/cgwalters/fedora-silverblue-config has instructions to build a Live Image, but how does one compose the tree?

#3

Hello @walters,
Thanks for putting this out for the community to do some testing with. It is relevant to many who have been asking for a live image of SB for some time. I forked your repo about 7 months ago and see that it has a number of changes since then, I think I’m roughly 8 commits behind. It’s time I updated my fork and make a live image for starters.

#4

Glad you posted this. I was not aware of this. To add to the discussion, I see this will support many more desktop environment option, which is a good thing. I am also concerned about the comment that some things will get worse; whatever that may mean. However, I see the the long term benefits that this approach could provide and I am confident rough edges will get worked out eventually. How far along is the build tools to support this? Are you forking COSA to do that? What is the long term vision and time frame expectations? I would love to see a build service provided by Fedora or Red Hat in the future to produce custom images based on user forks of this repo.

#5

I see https://github.com/cgwalters/fedora-silverblue-config has instructions to build a Live Image, but how does one compose the tree?

Just cosa build will do both the ostree commit and a qemu image. (The qemu focus is a CoreOS inheritance; it’s used by cosa run which conveniently spawns a transient VM. There’s some small other details here that become relevant like Workstation/SB don’t enable sshd by default and wouldn’t have a core user)

1 Like
#6

While I’m not directly concerned about this, I am indirectly concerned because the KDE SIG is looking to make a Kinoite flavor (with @Siosm), and a rebase to use cosa instead of the standard stack is a bit disruptive toward that.

Additionally, I’ve heard rumblings that cosa will also be replaced in the next 6 months, and I don’t particularly think it’s a good idea that we should rebase Silverblue onto the CoreOS build toolchain when we’ll be ripping everything out again in a few months.

#7

I don’t think this would be an issue. cosa is mostly a wrapper around common rpm-ostree workflow and should help us de-duplicate the work to create variants. Rebasing on Fedora CoreOS also has other advantages such as benefiting directly from the development and maintenance work done on FCOS.

I work daily with cosa and have not heard of that. Could you explain where this comes from?

#8

For this to be doable on Silverblue, would I need to layer qemu-kvm+libvirt-clients+bridge-utils+libvirt-deamon-system+virt-manager?

#9

No, when running inside a container, cosa comes with it’s own QEMU so no need for anything specific on the host.

#10

Well I can run the container, and use commands like fetch, but I get the error of /dev/kvm not existing.

#11

You need to have hardware support for KVM for some operations done by cosa but no need for libvirt, etc.

#12

Thanks @Siosm,
I must just be doing something wrong. My hardware is fully capable, I have VM’s setup for some of my specific MS needs and they always work fine using virt-manager. I’ll work through it, I’m sure.
Nov 27, 2020. Can get the tools to work, but cosa still errors with …
'Error: host directory cannot be empty

  • rc=125
  • set +x
    ’
    Now, I am thinking I am missing a step, any thoughts?
#13

Does the plan include using Anaconda as the GUI front end for ignition? Or is there an alternate approach for a GUI installer envisioned? And what’s the time frame for this work?

#14

It comes from a lot of strong pushing to rebase our ~6-10 different image building mechanisms onto OSBuild. I believe Fedora IoT already uses this, and there’s been talk about replacing ImageFactory with it for Fedora Cloud images soon.

I’ve had a conversation with the OSBuild team about this, and based on that conversation, we’re probably reasonably looking at an attempt to do this for CoreOS and Silverblue next summer. There’s been a ton of effort toward building RPM-OSTree build pipelines with OSBuild, so I’d caution putting more effort to rebase things on cosa while that is happening.

#15

This is probably surprising news to a bunch of people on this thread that directly work on developing, building, and supporting Fedora CoreOS as part of their $DAYJOB. We’ve not had any discussions about replacing coreos-assembler with osbuild in any foreseeable future. Since cosa serves as the build tool for both Fedora CoreOS and Red Hat CoreOS, it goes without saying that changing the build tooling behind both operating systems would be extremely disruptive and require some significant advance planning.

I think we are straying from the original topic, though. Perhaps it would be useful to split this thread into a new osbuild + coreos-assembler topic?

1 Like