install ZFS from ucore-kmods

[bsherman]

This changes ucore image builds such that kmods (zfs) are no longer built in this repo's workflows... instead they are built in https://github.com/ublue-os/ucore-kmods/actions and installed from that repo's resulting image.

[ahjohannessen]

@bsherman Hi :) This looks interesting. So, if I wish a clean fedora coreos with zfs installed that I otherwise can customize myself via butane / ignition, I should follow guidelines in https://github.com/ublue-os/ucore-kmods ?

[bsherman]

So, if I wish a clean fedora coreos with zfs installed that I otherwise can customize myself via butane / ignition, I should follow guidelines in https://github.com/ublue-os/ucore-kmods ?

Yep, you are understanding correctly!

However, today I'll also be adding a fedora-coreos-zfs image which is stock Fedora CoreOS with one addition, the latest stable ZFS.

[ahjohannessen]

However, today I'll also be adding a fedora-coreos-zfs image which is stock Fedora CoreOS with one addition, the latest stable ZFS.

Great :) How would I go about using that?

[bsherman]

Please take a look at https://github.com/ublue-os/ucore

The new image which is stock CoreOS+ZFS is listed there, including available tags and how to install.

[ahjohannessen]

@bsherman I tried doing

sudo rpm-ostree --bypass-driver rebase ostree-unverified-registry:ghcr.io/ublue-os/fedora-coreos-zfs:stable

Did a reboot and tried modprobe zfs - But no zfs, just:

modprobe: FATAL: Module zfs not found in directory /lib/modules/6.3.12-200.fc38.x86_64

Not sure what I did wrong.

[bsherman]

Not sure what I did wrong.

oh my! It seems you did it correctly, but I had a copy/paste error in the build workflow.

That has been corrected ( #63 ) and I have verified that ghcr.io/ublue-os/fedora-coreos-zfs:stable now contains the ZFS module.

Performing an rpm-ostree update on the system should resolve your issue.

Thank you for letting me know about the problem!

[ahjohannessen]

@bsherman got zfs working :) Do I need to do anything other than: sudo rpm-ostree --bypass-driver rebase ostree-unverified-registry:ghcr.io/ublue-os/fedora-coreos-zfs:stable with respect to zincati and otherwise in general?

[bsherman]

@bsherman got zfs working :)
🎉

Do I need to do anything other than: sudo rpm-ostree --bypass-driver rebase ostree-unverified-registry:ghcr.io/ublue-os/fedora-coreos-zfs:stable with respect to zincati and otherwise in general?

I don't think so.

1. I've never used --bypass-driver so I'm not sure if that is required.

2. Zincati is known to not work with rpm-ostree OCI images... I have an issue tracking the upstream issues here update documentation and config once zincati works with ostree containers #54

I do have this noticed in the repo README:

• Disables Zincati auto upgrade/reboot service
  NOTE: currently, zincati fails to start on systems with OCI based deployments (like uCore). Upstream efforts are active to correct this.

I've tried to keep all major information such as the zincati issue on the README... other than zincati, I'm not aware of any significant differences between rpm-ostree and rpm-ostree native containers.

[ahjohannessen]

I've never used --bypass-driver so I'm not sure if that is required.

I cannot execute the rpm-ostree command unless I specify --bypass-driver when doing it manually. I get this message:

error: Updates and deployments are driven by Zincati (zincati.service)
See Zincati's documentation at https://github.com/coreos/zincati
Use --bypass-driver to bypass Zincati and perform the operation anyways

[bsherman]

Ah! Yes, I have seen that before; thank you for the reminder.

I always disable the zincati service. Once disabled, it is not required.

[ahjohannessen]

I always disable the zincati service.

Interesting. When and how often do you update your CoreOS instances then?

[bsherman]

I use the ucore image :-) which (per the README) adds several "nice to have" features, but also:

Enables staging of automatic system updates via rpm-ostreed

This method is what Fedora Silverblue uses by default ... though our default configuration is to daily download and stage any updates.

It is less refined than zincati, certainly, but one can configure the rpm-ostreed-automatic.timer to run weekly and override the service to also reboot by adding an ExecStartPost=

Personally, I let my systems stage updates continually, and reboot them manually when desired... But I don't have a large fleet.