Easiest way to add the ZFS packages from ucore to main?

[ximGBu4cyQss5P]

The kinoite-main image is very close to what I want in a base image. Is there an easy way for users to take the ZFS packages from ucore and add them to a system running one of the main images?

[almereyda]

I am right now looking into the same thing and am generally very interested in exemplifying this with basic ublue (with GNOME) and ZFS 2.2, once the latter is released.

https://github.com/orgs/ublue-os/projects/1/views/1 doesn't mention ZFS in any place, why it appears supporting this scenario currently seems low priority, but it has a related card:

• https://github.com/orgs/ublue-os/projects/1/views/1?pane=issue&itemId=28378878

@castrojo pointed me at this possibility earlier this week, and I'd be interested in a sketched write up of how one could achieve to (1) access ZFS pools from a ublue install and (2) run ublue from ZFS as well, but may be a separate issue depending on this one.

The latter may benefit from taking into consideration ublue-os/main#283

Any further ideas?

[castrojo]

I'd love to have ZFS everywhere but I think the main problem is since new kernels make it into Fedora rather quickly you end up in a situation where you have the potential of not getting working builds at all until openzfs catches up.

If we had centos ostree images from derive from then we'd end up with a slower moving kernel and then I suspect that that would be an awesome setup for us to have.

[almereyda]

Are you suggesting a ublue spin that's based off of ucore, but adds a desktop environment?

Else, I feel there is sufficient reason to support a ublue spin that tracks ZFS-supported Kernel releases, based on the information present in the META file of the last public release.

• https://github.com/openzfs/zfs/releases
• https://github.com/openzfs/zfs/blob/8af8d2abb1ee928beea16e12390dd7b8cf76244f/META#L9

The only danger then would be Fedora ceasing to support a Kernel that is below or equal to Linux-Maximum in META.

People feeling lucky may also have success in raising that property in the META file manually, in case compatibility breaks with a newly introduced Kernel version.

[almereyda]

To continue in both directions, reflecting a bit on the path forward for a ZFS edition of ublue, but also sketching the path towards a slow-rolling, OSTree-native container image, which hopefully would not break the ZFS module.

Is there an easy way for users to take the ZFS packages from ucore and add them to a system running one of the main images?

For the risky path forward, which can break ZFS compatibility upon a Kernel upgrade, it seems legitimate to experiment with a fork of the ublue akmods, add ZFS there in a similar way as with the ucore-kmods, and use that for a custom build in a fork of ublue-os/main. Another way could be to add another file system layer that contains the ZFS RPM artefacts.

There's also work done to further modularize ublue and its akmods:

• Reorganize main builds to better support image flavors: main, nokmods, nvidia, asus, surface main#356
• Create build matrix to support distinct builds for kernel variants akmods#68
• Proposal: reduce the scope of ublue-os/main images main#369

In this vein, ZFS support could be considered an image flavour.

If we had centos ostree images to derive from then we'd end up with a slower moving kernel and then I suspect that that would be an awesome setup for us to have.

Are you suggesting a ublue spin that's based off of ucore, but adds a desktop environment?

I was mistaken by the syntactic proximity of CoreOS and CentOS. Obviously ucore is built on the prior, and not on the latter.

With CentOS Stream being rolling release, and as discussed during ContainerDays, CentOS could here ideally be read as a chiffre for AlmaLinux, which will continue to provide up-to-date, but slow-rolling, RHEL-ABI-compatible Linux releases. They already build the rpm-ostree package.

This would then give us what we could call ucent, ustream or ulma. They already publish an OCI image:

• Containers on AlmaLinux | AlmaLinux Wiki
• AlmaLinux OS Docker Images | AlmaLinux Wiki
• https://quay.io/centos/centos:stream9

Is there a detailed specification of how an OCI OS image needs to be shaped to be recognised as an OSTree-native container, so the AlmaLinux or CentOS stream image could be checked against it? The existing documentation on this experimental feature seems rather sparse:

• ostree native containers | rpm-ostree
• ostree-rs-ext/README.md at main · ostreedev/ostree-rs-ext
• ostree-rs-ext/ostree-and-containers.md at main · ostreedev/ostree-rs-ext

It seems we'll see more of these discussions in the future, with ublue being a well-suited testbed for this new kind of OS delivery mechanism.

• Rpm-ostree-ing other Distros? - Fedora Discussion

Related:

• Investigate bootc usage main#86

[castrojo]

Sorry I missed your last few messages! I believe you are on the right track, a CentOS Stream or Alma ostree container is something I've always wanted because it would give people a known enterprise cadence with all the advantages we have.

I think it's just a matter of attending one of their meetings and seeing if there's interest. There has to be a SIG out there that might be interested in doing this, someone just needs to chase it down and find out who to ask.

[almereyda]

Affirmative.

[almereyda]

Via

• Needs a tutorial or blog on how one would use this. containers/bootc#10

we find

a mailing list thread

• https://lists.centos.org/pipermail/centos-devel/2023-March/142809.html
• https://lists.centos.org/pipermail/centos-devel/2023-March/165128.html
• https://lists.centos.org/pipermail/centos-devel/2023-March/165129.html
• https://lists.centos.org/pipermail/centos-devel/2023-March/165131.html
• https://lists.centos.org/pipermail/centos-devel/2023-March/165130.html
• https://lists.centos.org/pipermail/centos-devel/2023-March/165133.html
• https://lists.centos.org/pipermail/centos-devel/2023-March/165135.html
• https://lists.centos.org/pipermail/centos-devel/2023-March/165162.html

that in its last message leads us to a pull request containers/bootc#75 which further down mentions a commit in a now archived GitHub repository that had been migrated to gitlab.com and further on been moved into the CentOS organisation:

• https://gitlab.com/CentOS/cloud/sagano

which holds an example bootable base image for CentOS Stream 9, and notes at the bottom of the README about the planned phases to maintain this work in the future.

[castrojo]

I had no idea about this, this is what we need! YES!

[castrojo]

Does taking the desktop manifests for fedora: https://gitlab.com/fedora/ostree/ci-test/ but using them in the sagano examples sound like a good approach?

[almereyda]

This is a great suggestion. Ending up with a CentOS Stream spin/flavour of sorts, that resembles what we find in

• https://gitlab.com/fedora/ostree/ci-test/-/blob/main/fedora-silverblue.yaml

for a starter, will be a suitable starting point. Is there a naming convention to differentiate between CentOS Stream flavours that come (1) on ostree, (2) with a GUI and (3) are built to be booted ("Sagano")?

I've also reread the mailing list thread, where they mention desktop use cases a lot, but do not conclude around the appropriate SIG chosen. Yet as Project Sagano is hosted in the gitlab.com/centos/cloud name space, it seems they've opted for Cloud.

Apparently CentOS "Atomic" ostree support is mainly driven by the Automotive SIG (?).

As I see @cgwaters being the main driver behind this, I feel like inviting them to this discussion for a second opinion via Mastodon.

---

For the ZFS ustream kmod layer, I believe it could be good to merge the two approaches from:

• https://github.com/coreos/layering-examples/blob/main/build-zfs-module/Containerfile
• https://github.com/ublue-os/ucore-kmods/blob/main/build-kmod-zfs.sh

[almereyda]

A Mastodon response from cgwaters at Sagano upstream confirmed that desktop is considered "a target use case". With the project being in so early stages, it was kindly suggested not to share the effort widely, yet, and to keep going researching this.

[almereyda]

I will come back to this the earliest end of October, then supposedly with ZFS 2.2 being released.