F45 Change Proposal: Stratis Storage in Anaconda (system-wide)

Project Discussion Change Proposals
,
1

Stratis Storage in Anaconda

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

This change aims to add support for installing Fedora on Stratis filesystems. This includes support in Kickstart for automated installation and manual partitioning in the Anaconda WebUI using Cockpit Storage.

:link: Owner

:link: Detailed Description

Stratis is a local storage management solution that simplifies filesystem feature orchestration by combining the block-layer and XFS filesystem into a unified CLI and D-Bus API control plane. Stratis has robust features such as, thin-provisioning, thin-safeguards, snapshots, cache tiers, and encryption.

This change will make Stratis a bootable, installer-supported solution for Fedora. While Stratis has been available in Fedora for several years, this change integrates native Kickstart support to allow users to configure Stratis as their default, end-to-end storage management implementation for both the primary root (/) filesystem and supplementary filesystems.

:link: Feedback

Stratis has been available in Fedora since Fedora 28 with new versions being added over the years, but support for using Stratis for the root filesystem is not yet available which limits our ability to gather feedback. We’ve seen some interest in using Stratis on Fedora and there is a third-party tool that allows manual installation on Stratis, but without support in the installer, we cannot really judge the popularity or potential of a new storage technology like this.

:link: Benefit to Fedora

Stratis provides modern storage features such as thin provisioning, snapshots, cache tiers, and encryption, through a single, unified management layer. Achieving a comparable feature set requires manually layering multiple technologies, each with its own tooling and configuration. Stratis simplifies this into a single tool.

While Stratis has been available in Fedora since Fedora 28, the lack of installer support has been a significant barrier to adoption: users could not use Stratis for their root filesystem without resorting to manual, unsupported workarounds. This change removes this barrier making Stratis a first-class installation option alongside Btrfs and LVM.

:link: Scope

  • Proposal owners:

    • Kickstart: New kickstart commands for creating Stratis pools and filesystems will be added. Similar to the existing volgroup and logvol commands for creating LVM Volume Groups and Logical Volumes.
    • Anaconda: New automatic partitioning “type” will be added for Stratis.
    • Blivet: Blivet already supports Stratis, some small changes might be needed for the automatic partitioning support.

  • Other developers:

    • The scope of this change is limited to the installer and its dependencies (Blivet and pykickstart). We are also coordinating with the Stratis project developers in case some changes or fixes are needed in Stratis itself.

  • Release engineering: #13395

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

This change does not affect upgrades. Only new installations will be affected by this change.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? No

Early images for testing can be provided by the developers. Once Stratis is included on the installation images, manual installation using Cockpit or mountpoint assignment as described below, can be tested.

:link: How To Test

:link: WebUI

The WebUI itself doesn’t allow for selecting the storage technology which will be used for automated or guided partitioning. Stratis layout can be created through the external Cockpit storage editor. The installer will automatically use Stratis devices created this way. Preexisting Stratis filesystems can be also used in the mount point assignment installation method. Generic documentation for storage configuration in Anaconda can be found here.

  1. On the Installation method page start Cockpit storage editor using the Launch storage editor option from the menu.
  2. Create partitions required for booting (/boot and /boot/efi or biosboot).
  3. Create Stratis pool.
  4. Create Stratis filesystems for / and /home (and other filesystems as needed).
  5. Return to the installer.
  6. Newly created layout should be recognized and the Use configured storage option should be selected.
  7. Finish the installation.

:link: Kickstart

Below are snippets of kickstart files with storage configuration. These are only examples and the exact syntax of the commands might change. Full example kickstart files for testing will be provided later.

:link: Automatic partitioning

autopart --type=stratis

Automatic partitioning with Stratis. The exact storage layout will be determined by the installer based on the available disk space. This doesn’t differ from automatic partitioning with LVM or Btrfs.

:link: Manual partitioning

part bd.01 --size=18000 --ondisk=vda part bd.02 --size=18000 --ondisk=vdb stratispool mypool bd.01 bd.02 stratisfs / --size=10000 --name=root --pool=mypool stratisfs /home --size=1 --grow --name=home --pool=mypool

Example of manual Stratis configuration in kickstart. Two 18 GB partitions will be created on vda and vdb disks (/boot and other partitions needed for booting are not shown here). One new Stratis pool named mypool and two filesystems: 10 GB root for / and ~26 GB home for /home (remaining free space after creating the root filesystem) will be created.

:link: User Experience

Users who are not using advanced storage configuration or are not interested in trying Stratis shouldn’t notice any changes. Default behavior of the installer, storage type and layout will remain the same, as configured for the specific Fedora variant.

For users that want to use Stratis, this will be a major simplification of the process. Stratis will be included on the Fedora images and users will be able to use Stratis for their root filesystem without any additional manual steps needed. Kickstart support is aimed mostly at advanced users, but with the Cockpit support in the WebUI, Stratis can be configured and used the same way as any other non-default storage technology.

Note that there is no plan for including support for Stratis in the old GTK-based Anaconda interface.

:link: Dependencies

Directly affected packages: blivet (python3-blivet), pykickstart (python3-kickstart), anaconda.

We don’t expect any other packages to be affected by this change and we don’t require assistance from other packagers.

stratisd, stratis-cli and stratisd-dracut packages will be added as new dependencies to Anaconda. Total installation size on Fedora Workstation Live image is 28 MiB. The resulting boot ISO image grows from about 1193 MiB to 1206 MiB with these packages included.

:link: Contingency Plan

  • Contingency mechanism: Reverting the changes in pykickstart and anaconda.
  • Contingency deadline: beta freeze
  • Blocks release? No

:link: Documentation

The newly added kickstart commands will be documented in the pykickstart documentation. Documentation for Stratis can be found on the project website.

Previous articles about Stratis are also available on Fedora Magazine:

:link: Release Notes

Last edited by @amoloney 2026-06-30T17:49:00Z

Last edited by @amoloney 2026-06-30T17:49:00Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Note that adding any storage mechanism to the installer(s) expands the required testing surface because of how we word the criteria, especially the Final criterion:

“The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration.”

so any bug in this is at least potentially a release blocker.

Will anaconda team be adding comprehensive tests for this, including interactive webUI tests, or are you expecting quality team to add tests for this? Either way, we need to write wiki test cases and add them to the matrices; then whichever test system is going to test this needs to hook up result reporting.

4

I expect that the kickstart auto-partitioning options will be covered by the kickstart based tests in the installer upstream CI. These are the ones which we also run when we report test results to the wiki.

The basic functionality and support for stratis is already covered with tests on the Cockpit side

Do you see the need to test the interactive workflow with manual stratis configuration?

5

Yes, because there are always interactions between cockpit and the installer. I would want any available storage mechanism to be tested either in openQA or the anaconda pixel tests.

6

Yes, I plan to add both kickstart tests and webui tests for this.

With this change, stratis will be “officially supported” so this makes sense, but how does this work with Cockpit in general? Cockpit supports storage configurations that were never supported by anaconda/blivet. What if cockpit adds support for something like bcachefs or ZFS, would that be considered a blocker as well just because Anaconda uses Cockpit for manual partitioning?

1 Like
7

Well, as written, yes. I think this is appropriate, because what “anaconda supports” vs. what “cockpit supports” is not relevant to the user. That’s our problem, not theirs. We chose to use cockpit-storage in the installer. All they see is an installer with a weirdly obscure link to the partitioning tool.

The logic behind the criterion is that it looks very bad if we make it possible for somebody to configure some kind of storage setup and then, later, crash or cryptically refuse to install to it. That is a bad experience. The internal details of why that happened aren’t interesting to the user, nor are they a justification for it happening.

8

“The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration.”

Random custom partitioning via external editor in not the default installer configuration.

We have extended the default installation paths in the installer WebUI exactly for the purpose that users do not need to reach to the storage editor in all the default supported cases.

The fact that storage editor can be opened by a click of a button during the installation, doesn’t make it a default installer configuration. The same way how the click on opening gparted in the other window doesn’t make it a part of default installation experience.

We do have some validation checks for when you have configured storage in some custom way, the partitioning complies with some basic expectations (/boot size, / size, etc). But we are not covering all possible configuration user can create in the custom partitioning screen with tests. We never did.

9

But there is no “start gparted” button in the installer itself. The Cockpit storage editor is well integrated into the installer so I see Adam’s point here. But that’s a bit offtopic here.