Ubuntu 26.04 LTSとBtrfs：Ansibleで再現できる安全な環境作り

Ubuntu 26.04 LTS に Btrfs を組み合わせるなら、最初に決めるべきことは「どのコマンドで作るか」ではありません。 どの変更を戻せるようにしたいのか、どこから先を Ansible で再現するのかを先に決めるほうが安全です。

この記事では、Ubuntu 26.04 LTS で Btrfs を使う場合に確認すべき 26.04 固有の前提と、Ansible で自分の環境を再現する範囲を整理します。サブボリューム設計や検証コマンドの基礎は別記事に譲ります。

TL;DR

Ubuntu 26.04 LTS で Btrfs を使う前提（サブボリューム設計・スナップショットの限界）は、別記事「UbuntuでBtrfsを使う前に：インストールとスナップショット設計の基本」で整理しています。
26.04 系では sudo-rs への移行が進んでおり、sudo のプロンプト文字列を正規表現マッチする自動化は影響確認が必要です。
Ansible は、ディスク初期化よりも初回起動後のパッケージ・設定・開発環境の再現に使うのが安全です。
ローカル環境で確認した ansible / ansible-core / btrfs-progs のバージョンを示します。

最初に決める設計

Ubuntu 26.04 LTS を Btrfs で運用するなら、インストール前に次の 3 点を決めます。

/ と /home を別サブボリュームにするか
スナップショットをどこに置くか
初回起動後の設定をどこまで Ansible に任せるか

最小構成なら、@ を /、@home を /home、.snapshots をスナップショット置き場として扱う設計が分かりやすいです。ログ、Docker、仮想マシンイメージ、データベースを別サブボリュームにする設計もありますが、最初から増やしすぎると復旧手順が複雑になります。

ブートローダ、/etc/fstab、initramfs、暗号化、TPM/FDE、別 OS との共存は環境差が大きい領域です。短いコマンド列だけで安全に完了できる作業ではないため、実ディスク操作よりも検証と復旧手順の準備を先に置きます。

Ubuntu 26.04 LTS で確認しておくこと

24.04 LTS から移行する場合は、インストール方法だけでなく、26.04 LTS の要件と変更点も先に確認します。特に自動化と復旧に関係する点は、Btrfs 設計と Ansible 設計の両方に影響します。

特に自動化に関係する点として、26.04 系では sudo-rs への移行が進んでいます。通常の Ansible become: true だけであれば大きな影響は出にくい一方、sudo のプロンプト文字列を Expect や独自スクリプトで正規表現マッチしている場合は注意が必要です。

ローカルの Ubuntu 26.04 LTS 環境では、次の候補バージョンを確認しました。

apt-cache policy ansible ansible-core btrfs-progs sudo sudo-rs

確認した環境では、ansible は 13.1.0+dfsg-1ubuntu1、ansible-core は 2.20.1-1、btrfs-progs は 6.17.1-1build1 が候補でした。リポジトリのミラーや更新時期で変わるため、実作業前に自分の環境で確認してください。

Btrfs の基礎は別記事で確認する

サブボリュームの定義、@/@home が Btrfs 固有の必須名ではないこと、スナップショットが同じストレージ上の参照共有であることなど、Btrfs 自体の基礎用語は別記事「UbuntuでBtrfsを使う前に：インストールとスナップショット設計の基本」の「UbuntuのBtrfsで混乱しやすい点」にまとめています。

ここでは前提として、Btrfs を使う理由は「魔法のロールバック」ではなく、変更前の状態をファイルシステム上で扱いやすくすることだという点だけ押さえておきます。外部バックアップ、復旧用 USB、復旧手順のメモは別に必要です。

検証は一時イメージで行う

mkfs.btrfs をファイルバックドイメージで試す手順と、guestfish でのサブボリューム/スナップショット作成検証は、別記事「UbuntuでBtrfsを使う前に：インストールとスナップショット設計の基本」の「実ディスクを触る前に安全に試す」で手順化しています。実ディスクに触る前に、必ずそちらで動きを確認してください。

26.04 LTS のローカル環境では、btrfs-progs v6.17.1 でこれらのコマンドが期待どおりに動くことを確認済みです。

実ディスクで作業する前の判断

Ubuntu を Btrfs で入れる方法は、Desktop / Server、インストーラー、暗号化、既存 OS との共存によって変わります。そのため、この記事では実ディスク向けの parted と mkfs.btrfs を「最初に実行する手順」としては置きません。

実ディスクで作業するなら、最低限ここまで確認します。

lsblk -f
findmnt -no SOURCE,FSTYPE,OPTIONS /
blkid

インストール後に Btrfs になっているか、どのサブボリュームが使われているかは次で確認します。

findmnt -no SOURCE,FSTYPE,OPTIONS /
sudo btrfs subvolume list /

もし sudo btrfs subvolume list / が失敗するなら、/ が Btrfs ではないか、Btrfs でも期待したサブボリューム構成になっていない可能性があります。この場合、既存環境をその場で変換するより、VM や予備ディスクで再現手順を作ってから進めるほうが安全です。

fstab は「起動できるか」に直結する

subvol= 指定を含む /etc/fstab の具体例と、圧縮オプションがファイルシステム単位で影響し合う注意点は、別記事「UbuntuでBtrfsを使う前に：インストールとスナップショット設計の基本」の「fstabの例」にまとめています。

fstab を誤ると起動できなくなります。編集前にバックアップを取り、ライブ USB からマウントして戻せることを確認してから触ってください。

Ansible は初回起動後の再現に使う

ansible ubuntu 26.04 で探す人の多くは、OS を入れた後のパッケージ、開発ツール、設定を再現したいはずです。 Btrfs のパーティション作成やフォーマットまで Ansible に入れることも技術的には可能ですが、個人端末や単発移行ではリスクが高くなります。

まずは、初回起動後に何度でも流せる範囲から始めます。

---
- hosts: localhost
  connection: local
  become: true
  tasks:
    - name: apt キャッシュを更新する
      ansible.builtin.apt:
        update_cache: true

    - name: 基本パッケージを入れる
      ansible.builtin.apt:
        name:
          - btrfs-progs
          - ca-certificates
          - curl
          - git
        state: present

実行例です。

ansible-playbook -i localhost, -c local site.yml

外部 PPA を使って新しい Ansible を入れる場合は、Ansible 公式ドキュメントの Ubuntu 向け手順を確認してください。一方、Ubuntu 26.04 の標準リポジトリにあるバージョンで足りるなら、まず標準リポジトリから始めるほうが切り分けしやすいです。

まとめ

Ubuntu 26.04 LTS で Btrfs を使うなら、いきなり実ディスクへ mkfs.btrfs を実行するのではなく、まず一時イメージや VM でコマンドの意味を確認します。

Btrfs はサブボリュームとスナップショットに価値がありますが、バックアップや起動復旧手順の代替ではありません。 Ansible は、初回起動後の環境再現に使うと効果が出やすく、ディスク初期化の自動化は十分に検証してから扱うべき領域です。

より一般的な「Ubuntu で Btrfs を選ぶべきか」という判断、サブボリュームの基礎、検証コマンドの詳細は、別記事の UbuntuでBtrfsを使う前に：インストールとスナップショット設計の基本に整理しました。