Idea is to have SUSE system with OpenZFS as root FS.

Why ZFS

Ways in which ZFS is better than BTRFS

Main goal

Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install

Goals

  • synergy of ZFS with dracut, so snapshots are correctly added to the grub
  • synergy of zedenv with zypper
    • before every update snapshot is created
    • when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
  • integrate Root on ZFS as install option to the YaST
  • configure Kiwi for the ZFS install images

Completed goals

  • prepare ZFS pool compatible with openSUSE installation ✓
  • install openSUSE with root on ZFS ✓
  • boot to the prepared and installed system ✓

Current progress

Resources:

Looking for hackers with the skills:

dracut yast yastui zfs packaging systemd

This project is part of:

Hack Week 17 Hack Week 19 Hack Week 21 Hack Week 23 Hack Week 25

Activity

  • 5 days ago: dheidler liked this project.
  • 11 days ago: jkohoutek added keyword "systemd" to this project.
  • about 2 years ago: uncomfyhalomacro liked this project.
  • over 3 years ago: ph03nix liked this project.
  • over 3 years ago: jkohoutek added keyword "packaging" to this project.
  • almost 4 years ago: averyfreeman liked this project.
  • over 4 years ago: MilesBHuff liked this project.
  • over 4 years ago: dfaggioli liked this project.
  • almost 6 years ago: lkocman liked this project.
  • almost 6 years ago: jkohoutek liked this project.
  • almost 6 years ago: jkohoutek added keyword "zfs" to this project.
  • almost 6 years ago: jkohoutek added keyword "yast" to this project.
  • almost 6 years ago: jkohoutek added keyword "yastui" to this project.
  • almost 6 years ago: jkohoutek added keyword "dracut" to this project.
  • over 7 years ago: michalnowak liked this project.
  • over 7 years ago: lproven liked this project.
  • over 7 years ago: jochenbreuer liked this project.
  • over 7 years ago: jkohoutek started this project.
  • over 7 years ago: jkohoutek originated this project.

  • Comments

    • pluskalm
      over 7 years ago by pluskalm | Reply

      zfs itself is already packaged in https://build.opensuse.org/package/show/filesystems/zfs , not sure about rest of required stuff

    • firstyear
      almost 6 years ago by firstyear | Reply

      This looks awesome, I wish you all the best on this!

    • lkocman
      almost 6 years ago by lkocman | Reply

      I did something like our snapper for zfs / grub2 / opensolaris about 10 years ago :-) It was a high school project, but it might be fun just to try it out.

      • jkohoutek
        almost 6 years ago by jkohoutek | Reply

        You mean something like Time slider? add-emoji It would be great to i implement it :-)

    • jkohoutek
      almost 6 years ago by jkohoutek | Reply

      Project update - Tumbleweed is able to boot from ZoL root! Check current progress

      • bobafetthotmail
        over 5 years ago by bobafetthotmail | Reply

        can't log in to see the "current progress", is there a repo or a more accesible place with some instructions to make Tumbleweed run/boot on ZFS root?

      • MilesBHuff
        over 4 years ago by MilesBHuff | Reply

        Hi! Can you please post how to do this publicly? The link you said to click on in the post is inaccessible to us normies.

    Similar Projects

    GHC-9.14 and split Hadrian from GHC build by osukup

    Description

    Prepare openSUSE Tumbleweed project for new GHC Haskell compiler and separate builder (Hadrian) from GHC build

    Goals

    • have GHC-9.14 project with working compiler and if possible filled with packageset
    • have Hadrian in own package built with bootstrap compiler to separate Hadrian bootstrap from ghc bootstrap

    Resources

    devel:languages:haskell

    d:l:h:ghc-9.12.x

    opensuse Haskell rpm macros

    opensuse haskell package gen project


    OpenRC in openSUSE by jimedrand

    Description

    I have been using openSUSE for 3 years and I am just seen the systemd as init system. Actually, I want to make openSUSE with supports to another init such as OpenRC init that I'm always using it in another distros, and I was think, "what about if I'm including OpenRC init in openSUSE and give anyone as second way for them who don't want to use systemd?", and I'm curious about that. That's why I'm opening these.

    Goals

    Giving OpenRC support for Tumbleweed first, then going in Leap in future if possible.


    Work on some systemd upstream RFEs by afeijoo

    Description

    There are more than 1000 issues labelled as RFE in systemd, so this is not a common one-week project with a defined task.

    Example from Hack Week 23: Allow to group entries with the same sort-key in systemd-boot

    Goals

    Gain a deeper understanding of some areas of systemd while working on some useful tasks. I'd be great to be able to upstream all the work, but that's not the main goal.

    Resources

    https://github.com/systemd/systemd/issues (RFE)


    Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy

    Description

    The Mission: Decentralized & Sovereign Messaging

    FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com

    In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.

    However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.

    Why This Matters

    A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:

    • Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
    • Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
    • Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.

    By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.

    Goals

    As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.

    Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:

    • Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
    • Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
    • Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
    • Allow the use of bind or remote mounted volumes for shared data (/var/vmail, DKIM keys, TLS certs, etc.).
    • Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.

    By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol

    Resources