Fedora 45 Brings Stratis Storage Into the Anaconda Installer

on

By the end of this article, you will understand how Fedora 45's Anaconda installer incorporates Stratis storage, what the two-layer pool-and-filesystem model means in practice, which features are available at install time, and which must be configured afterward.

Stratis as an integration layer

Stratis is not a new storage technology in the sense of introducing novel on-disk formats or proprietary abstractions. It builds on device mapper, LUKS, and XFS — components that have been part of the Linux storage stack for years — and wraps them in a unified management interface. The value proposition is not that it can do something none of those tools could do individually, but that it collapses the multi-step configuration an administrator previously had to perform by hand into a single logical operation. The complexity of coordinating encryption, provisioning, and filesystem creation across separate tools is hidden behind a simpler model.

That model is deliberately minimal. There are two structural layers: pools and filesystems. A pool is an abstract container that sits on top of one or more block devices — whole disks, partitions, RAID arrays. It is the unit at which encryption and over-provisioning are configured. Filesystems are created on top of a pool and serve as the actual mount points: root, home, or any other logical volume an administrator needs. This two-layer model is intentionally simpler than LVM's triple indirection (physical volume, volume group, logical volume), which is part of why Stratis has been gaining traction in desktop and small-server deployments where the full LVM workflow is overkill.

Beyond the basic structure, Stratis supports snapshots, caching, and — for encrypted pools — multiple unlocking methods including TPM and Clevis/Tang. These are not new capabilities either; they are features that already existed in the underlying technologies but required separate tooling and manual coordination to combine into a working configuration.

What the Fedora 45 installer actually offers

The practical change in Fedora 45 is that Stratis is now reachable during installation through the Anaconda installer. However, the path to it is not the most direct one. The new web-based user interface for Anaconda does not currently allow the user to select which storage technology underlies the automated or guided partitioning options. The resulting layout depends on the Fedora variant being installed, and Stratis is not one of the choices presented in that automated flow.

To get Stratis during installation, the user must select the "If none of the options above apply…" option on the Installation Destination step, which opens the Cockpit storage module integrated into the installer. Cockpit supports a wide variety of storage configurations, and Stratis is among them. From there, the administrator follows a manual partitioning workflow: first creating the partitions required for booting (/boot and either /boot/efi or biosboot, depending on the system's firmware configuration), then creating a Stratis pool from the Cockpit interface. After the pool exists, filesystems for / and /home are added to it.

This is a meaningful distinction. Stratis is not being pushed as the default or even a first-class guided option alongside LVM or Btrfs in the automated path. It is available, but it requires the administrator to opt into manual partitioning and navigate the Cockpit module. For a desktop user who wants the simplest possible install, this is a non-starter. For an administrator who has decided they want Stratis and is willing to take a few extra steps, it eliminates the need to wait for the base install to complete before setting up storage. The installer now handles the structural setup in one pass rather than requiring a separate post-install configuration session.

Over-provisioning and the trade-off it introduces

The feature that makes Stratis most relevant to administrators is over-provisioning. When enabled at the pool level, it allows filesystems created on that pool to be allocated more space than the pool physically contains. The mechanism is analogous to thin provisioning in LVM and to the overcommit model in Btrfs: the system does not enforce a hard boundary at allocation time, and instead relies on the administrator to monitor actual usage against real capacity.

The practical benefit is straightforward. In a traditional partitioned or LVM setup, if /home fills up while / still has free space, the system may become unresponsive because root cannot write to its own directories. With over-provisioning, that scenario is less likely to occur in a sudden, catastrophic form — space can effectively flow between filesystems as needed. It also provides greater flexibility when using snapshots, since a snapshot does not immediately consume the full size of the filesystem it references. An administrator who takes frequent snapshots of a large volume is no longer forced to reserve the full size of each snapshot up front.

The risk is the mirror image of the benefit. An administrator who allocates 2 TB across two filesystems on a 1 TB pool is not actually managing 2 TB of storage. If both filesystems grow toward their allocated sizes simultaneously, the pool will exhaust its real capacity, and the consequences are the same as running out of disk space on a traditional system: writes fail, services may crash, and recovery requires freeing space or expanding the pool. Stratis does not prevent this; it defers the failure to a point where the administrator must have been monitoring aggregate usage. For a single-user desktop this is a manageable risk. For a multi-tenant server where multiple workloads share a pool, it demands a monitoring strategy that accounts for the total allocation exceeding physical capacity. Both over-provisioning and encryption can be toggled on or off after installation, so the decision made at install time is not permanent.

What is deferred to post-install

Not all Stratis features are available through the Anaconda installer. Caching is not currently supported during installation, and neither is encryption without a passphrase. Both can be enabled after the base installation is complete, which means an administrator who wants passphraseless encryption via TPM or Clevis/Tang, or who wants a read cache on a pool, will need to configure those after booting into the installed system. This is a reasonable compromise: the installer handles the structural setup — pool creation, filesystem creation, basic encryption with a passphrase — and the more advanced or niche configurations are left to the post-install environment where the full stratis command-line tool is available.Source: fedoramagazine.org

Comments

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

Install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Overview Running a local large language model (LLM) is easier than ever thanks to Ollama and Open WebUI. Ollama handles model downloads and inference, while Open WebUI gives you a clean, chat-style interface in your browser. In this tutorial, you'll install both on Ubuntu 24.04 (works on 22.04 too), enable NVIDIA GPU acceleration, and deploy them with Docker Compose. The result is a fast, private AI stack you control. What You'll Need - Ubuntu 24.04 or 22.04 (fresh or existing server/desktop). - An NVIDIA GPU with recent drivers (Turing/RTX or newer recommended). - Root or sudo access. - Open ports 3000 (Open WebUI) and 11434 (Ollama) on your firewall if you access remotely. Step 1: Install NVIDIA Drivers and Verify CUDA First, update your system and install the recommended NVIDIA driver. On Ubuntu Desktop you can use Additional Drivers, but the CLI route is reliable: sudo apt update && sudo apt -y upgrade sudo ubuntu-drivers autoinstall sudo reboot After reboo...

Install a Local AI Chatbot on Ubuntu 24.04 with Ollama and Open WebUI (Step-by-Step)

Running a fast, private AI chatbot on your own computer or server is easier than ever. In this guide, you will install Ollama (a lightweight local LLM runtime) and Open WebUI (a modern web interface) on Ubuntu 24.04 . You will be able to chat with models like Llama 3 or Mistral without sending data to the cloud, and with optional GPU acceleration if you have an NVIDIA card. What you will need : an Ubuntu 22.04/24.04 machine (VM, bare metal, or WSL), at least 8 GB RAM (16 GB recommended for larger models), 15–30 GB free disk space for models, Internet access, and optional NVIDIA GPU drivers for acceleration. Why Ollama + Open WebUI? Ollama manages local large language models (LLMs) with simple commands and sensible defaults. Open WebUI gives you a clean, chat-style interface with features like prompt history, file uploads (for some models), and model switching. Together, they are a simple, reliable stack for a self-hosted AI experience. 1) Update Ubuntu and install basics First, ...

Install Ollama + Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Overview This guide shows you how to install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU acceleration. You will get a fast local AI stack that can run modern large language models (LLMs) like Llama 3 on your own hardware, secured and accessible in a web browser. We will cover GPU driver setup, Docker with the NVIDIA Container Toolkit, Ollama installation, Open WebUI deployment, basic security, and troubleshooting. Prerequisites - A machine running Ubuntu 24.04 (fresh or updated). - An NVIDIA GPU with at least 8 GB VRAM recommended for 8B models (more is better). - Internet access and sudo privileges. Step 1: Install the NVIDIA GPU Driver Install the recommended proprietary driver so CUDA becomes available to both Ollama and containers. sudo apt update && sudo apt install -y ubuntu-drivers-common sudo ubuntu-drivers autoinstall sudo reboot After reboot, verify the GPU is recognized: nvidia-smi You should see a driver version and your GPU model. If not, check...

Trending Now

Homogeneous Nucleation on Mars: A Textbook Process Finally Observed in Nature

on
By the end of this piece, you will understand what the Arsia Mons Elongated Cloud is, why it resisted explanation for several years after its first observation, and what the newly published model reveals about a physical process that has never been directly confirmed on any planet's atmosphere. The cloud that broke the model Every morning during Martian spring and summer, a thin, extremely long cloud forms near the Arsia Mons volcano and gradually elongates until it stretches to more than 1,000 miles before dissipating. The cycle then repeats for several months. The formation was first recorded by a probe in 2018, and from that point onward it became a persistent puzzle for atmospheric scientists working with Mars data. The cloud's geometry, its timing, and its seasonal recurrence all pointed to a real and reproducible physical process, yet no existing model could reproduce it. For a technical audience familiar with simulation work, the situation is analogous to a product...