Debian/Trixieから期待できること

概要

Debian 13 "trixie" は2025年8月9日に安定版としてリリース予定
サーバー運用者視点 での主要な変更点や注意点を整理
パッケージバージョンの比較 や、重要な新機能・非互換点を解説
apt・systemd など基盤ツールの進化点を詳細に紹介
アップグレード時の注意事項 や追加情報へのリンクも記載

Debian 13 "trixie" サーバー管理者向けアップグレードノート

Debian 13 "trixie" は2025年8月9日に新たな安定版として公開予定
主要顧客にて trixieリリース準備 を2024年8月から主導、必要なパッケージの確保や安定稼働を確認済み
重大な問題回避 や、円滑なアップグレードの実現を重視
現時点では全体的に 順調な進捗 を確認
ここでは サーバー用途・システム管理者視点 で重要な点を抜粋

参考資料

公式Debianリリースノート を必ず参照
特に「 What’s new in Debian 13」と「trixieで注意すべき課題」は熟読推奨

主なパッケージバージョン比較（2025-07-20時点、amd64想定）

| パッケージ名 | bookworm/v12 | trixie/v13 | |:---|:---|:---| | ansible | 2.14.3 | 2.19.0 | | apache | 2.4.62 | 2.4.64 | | apt | 2.6.1 | 3.0.3 | | bash | 5.2.15 | 5.2.37 | | ceph | 16.2.11 | 18.2.7 | | docker | 20.10.24 | 26.1.5 | | dovecot | 2.3.19 | 2.4.1 | | dpkg | 1.21.22 | 1.22.21 | | emacs | 28.2 | 30.1 | | gcc | 12.2.0 | 14.2.0 | | git | 2.39.5 | 2.47.2 | | golang | 1.19 | 1.24 | | libc | 2.36 | 2.41 | | linux kernel | 6.1 | 6.12 | | llvm | 14.0 | 19.0 | | lxc | 5.0.2 | 6.0.4 | | mariadb | 10.11 | 11.8 | | nginx | 1.22.1 | 1.26.3 | | nodejs | 18.13 | 20.19 | | openjdk | 17.0 | 21.0 | | openssh | 9.2p1 | 10.0p1 | | openssl | 3.0 | 3.5 | | perl | 5.36.0 | 5.40.1 | | php | 8.2+93 | 8.4+96 | | podman | 4.3.1 | 5.4.2 | | postfix | 3.7.11 | 3.10.3 | | postgres | 15 | 17 | | puppet | 7.23.0 | 8.10.0 | | python3 | 3.11.2 | 3.13.5 | | qemu/kvm | 7.2 | 10.0 | | rsync | 3.2.7 | 3.4.1 | | ruby | 3.1 | 3.3 | | rust | 1.63.0 | 1.85.0 | | samba | 4.17.12 | 4.22.3 | | systemd | 252.36 | 257.7-1 | | unattended-upgrades | 2.9.1 | 2.12 | | util-linux | 2.38.1 | 2.41 | | vagrant | 2.3.4 | 2.3.7 | | vim | 9.0.1378 | 9.1.1230 | | zsh | 5.9 | 5.9 |

雑多な変更点・注意事項

asteriskパッケージ はtrixieにも未収録（#1031046参照）
debian-repro-status パッケージ新規追加、インストール済みパッケージの再現性を確認可能
Grml live system 由来のパッケージ(grml-keyring、grml-hwinfo、grml-paste)が新規収録
pacemaker利用者注意 ：fence-agentsパッケージは移行用となり、個別パッケージ化。全エージェント必要ならfence-agents-allを明示的に導入
- Recommends無効の場合は特に注意
usrmerge が最終化（dpkg警告にも留意、リリースノート参照）
XMPP/Jabber関連 はxmpp-teamのブログを参照
curlパッケージ に新たにwcurlコマンド追加（curlラッパー）

apt 3.0 の主な新機能と変更点

カラー表示対応 （インストール/アップグレードは緑、ダウングレードは黄、削除は赤。--no-colorや環境変数で無効化可能）
出力のセクション化 と、削除操作の強調表示
sequoiaによる署名検証 の導入
新しいソルバー の実装
apt modernize-sources コマンドで/etc/apt/sources.list.d/*.listを新DEB822(.sources)形式に変換
apt distclean コマンドで$statedir/lists配下の不要ファイル一括削除（配布用イメージの最終化などに活用）
APT::NeverAutoRemove::KernelCount 設定で保持するカーネル数を制御可能（例: 3で最新+稼働中含め3つ維持）
--snapshot や --update など新コマンドラインオプション追加
apt-key完全廃止 （代替となる鍵一覧インターフェースなし）

systemd 257.7-1 の主な新機能・変更点

net.naming_scheme がv257で変更、PCIスロット番号の取得元が変更（影響がある場合は#1092176, #1107187やDebian Wiki参照）
devicetreeエイリアス が複数ポートコントローラの個別インターフェースにも対応
新ツール追加
- run0 ：sudo類似の一時的な権限昇格
- systemd-ac-power ：外部電源接続状況の報告
- systemd-confext ：System Extension Imagesの有効化
- systemd-vpick ：‘.v/’バージョン付きディレクトリ解決
- varlinkctl ：Varlinkサービスの操作
各systemdツールの新オプション・コマンド
- busctl、hostnamectl、journalctl、kernel-install、localectl、loginctl、networkctl、systemctl、systemd-analyze、systemd-ask-password、systemd-cat、systemd-creds、systemd-detect-virt、systemd-firstboot、systemd-id128、systemd-inhibit、systemd-machine-id-setup、systemd-mount、systemd-notify、systemd-path、systemd-run、systemd-sysext、systemd-sysusers、systemd-tmpfilesなどで多数追加
- 例えばjournalctlの --invocation=ID や --exclude-identifier=STRING、systemctlの soft-reboot や sleep コマンド、systemd-analyzeの architectures や has-tpm2 コマンドなど
詳細は公式リリースノートおよび各manページを参照

アップグレード時の注意点

公式リリースノート の既知の問題点セクションを必ず確認
独自パッケージ や運用中のサービスが新バージョンで動作するか事前検証
usrmerge や apt-key廃止 など構成管理・自動化にも影響あり
systemdの新機能やデバイス命名規則変更 がネットワーク設定等に影響する場合あり

さらなる情報・推奨リンク

Debian公式リリースノート
What's new in Debian 13 （新機能・変更点まとめ）
Debian Wiki （個別パッケージやサブシステムの詳細情報）
各種パッケージのアップストリームリリースノート も併用推奨

このノートは今後も随時更新予定。 サーバー運用者視点でのtrixie移行・運用の参考資料 として活用推奨。

Hackerたちの意見

注意しておいてね：Trixieのアップデートはロールバックできないよ。理論上は可能かもしれないけど、実際には毎回失敗するし、システムが不安定で壊れた状態になっちゃうんだ。（コード的には「すぐに起動できなくなる」って感じ）。つまり、ドライバーやアプリケーションソフトが壊れたときに、アップグレードが失敗だったって気づいても、もう手遅れってこと。特に、MySQL/MariaDBみたいに、アップグレードが元に戻せないものもあるからね。データベースのバイナリ形式がアップグレード中に変わるから、他の何かが壊れたことに気づいて戻りたいと思っても、結構大変だよ。どうしてそう思うか、聞いてみて。

└

それは今までサポートされてなかったよ： https://wiki.debian.org/SystemDowngrade

└

アップグレードについてのページ[0]にはこんな警告があるよ：データをバックアップしてね。リリースアップグレードはリスクがあるから、アップグレードが失敗してシステムが機能しなくなることもある。ユーザーはリリースアップグレードを試みる前に、すべてのデータをバックアップするべきだよ。DebianStabilityにはこれらのステップについての詳細が載ってる。[0] https://wiki.debian.org/DebianUpgrade

└

どうしてそう思うか、聞いてみて。どんな問題があったからアップデートをロールバックしたくなったの？

└

LVMスナップショットを使うべきだよ。それに対して文句を言うのはおかしい。

└

公平に言うと…それはどうなるの？Debianだけじゃなくて、一般的には、完全なファイルシステムのスナップショットやバックアップ以外に避ける方法が見当たらないよね。たとえば、NixOSのようなシステムでも、すべてのソフトウェアや設定を元の状態に戻すのが再起動して古い世代を選ぶだけで簡単だとしても、データベースはディスク上のフォーマットを移行しちゃってるからね。

「一時ファイルディレクトリ /tmp は tmpfs に保存されるようになった」 - https://www.debian.org/releases/trixie/release-notes/issues.... これがデフォルトなのはあんまり好きじゃないな。もっと制限されて高価なメモリより、安いディスクスペースの方がいいよ。

└

え、ってことは、動作が不安定なプログラムが /tmp を埋め尽くすことでメモリ不足エラーを引き起こす可能性があるってこと？それはすごく悪いデフォルトだね。

└

ルートで systemctl mask tmp.mount を実行して再起動すれば、/tmp を通常のディレクトリに戻せるよ。 > 新しいファイルシステムのデフォルトは /etc/fstab で上書きできるから、すでに別の /tmp パーティションを定義しているシステムには影響しないみたい。リリースノートを見る限り、元に戻すのは簡単そうだね。理由としては、ほとんどの一時ファイルが小さくて短命だから、パフォーマンスの最適化なんだ。メモリに保存して、使わなくなったらディスクにページアウトして、他の用途のためにメモリを解放するのが理想的なんだよね。

└

SSDを使ってるユーザーにとって、書き込みの劣化を防ぐのは嬉しいデフォルトだね。

└

やっと tmpfs を使うようになったね。よかった、ほんとに <3

今日知ったことだけど、ネットワークインターフェースの名前付けの仕方が14通りもあるんだって[1]。「予測可能」なんて、まったくおかしいよ。[1] https://manpages.debian.org/testing/systemd/systemd.net-nami...

└

14通りの異なるスキームに加えて、バージョンごとにちょっとずつ動作が違うものもあるんだよね。確かにピン留めはできるけど、それは内部のやり取りを解決するだけで、カーネルのコマンドラインを通じてしかできないし、古いバージョンがどれくらいの間利用可能でいるかも保証されてない。過去にはもっと侵襲的なものが非推奨になったりしてるし（例えば、cgroupv1）、ここでも古いバージョンが削除される可能性があるから、名前付けがまた壊れちゃうかも。もちろん、インターフェースをカスタム名にピン留めすることはできるけど、なんでそんな面倒なことを誰かがしなきゃいけないの？僕はsystemdが好きだけど、これは彼らが大きく失敗した一つで、まだ解決してないみたい。MACアドレスでインターフェースを短く使いやすい名前にピン留めする方が、PCIスロットでやるよりもずっと安定してたはずだよ。PCIスロットはファームウェアのアップデートや新しいハードウェア、新しいカーネルが新機能を公開することで、頻繁に変わるからね。これはほとんどの仮想関数にはうまくいくけど、仮想関数は親インターフェースのサブデバイスだから、親の名前にサフィックスを追加するだけで名前付けできるし。

└

「stable」のインターフェース命名規則は詐欺だよ。証拠もあるし。今日、VMをブックワームからトリクシーにテストアップグレードしたんだけど、なんと、すべてうまくいったのに、再起動後にネットワークインターフェースが未設定になってた？名前が変わったんだよね…

└

今までのところ、AIの一番の使い道はFedora Serverのコアインフラを「正しい方法」で管理する方法を教えてもらうことだね。ネットワークやファイアウォール、DNS、NTPの設定を恒久的に、または一時的に変更するためのファイルやコマンドとか。

└

systemdの予測可能なネットワークインターフェース名が嫌いだから、このカーネルコマンドラインオプションで無効にしてるよ：net.ifnames=0 おかえり、eth0。 :)

リリースが楽しみ！ほとんどのシステムで Debian Stable を使ってるよ（1つは MoinMoin のせいで 10/Buster に留まってるけど）。先週、linuxcontainers.org からダウンロードした LXC コンテナに Trixie をインストールしたんだ。基本インストールで気づいたことは3つ：1) セキュリティ設定が変わったせいで Ping が動かなかった（iputils-ping）[2] 2) OpenSSH サーバーが systemd ソケットで起動されて、/etc/ssh/sshd_config* を無視してた。これはダウンロードしたコンテナ特有の問題かも。3) systemd-resolved が DNS の代わりに LLMNR を使ってて、ファイアウォールで保護されたホストに Ping を打ったら失敗した。なぜなら、名前解決が LLMNR で TCP ポート 5355 にアクセスしてたから。LLMNR は無効にしたよ。一般的に、ここ数年は Debian のバージョンアップは成功してるけど、バックアップは必ず取るし、リリースノートも必ず読むようにしてる。

└

OpenSSH の変更はバグじゃないなら狂ってる。意図的じゃないことを願うよ。

└

OpenSSH サーバーが systemd ソケットで起動されて、/etc/ssh/sshd_config* を無視してた。これはダウンロードしたコンテナ特有の問題かも。 .socket ユニットは .service ユニットを指してないの？ソケットを使うことと sshd が読む設定がどう繋がるのか、全然わからないんだけど。

└

systemd-resolvedはnetwork-managerと組み合わせるとマジで厄介だよ。この二つのパッケージは、DNS解決をめちゃくちゃにして、名前解決の唯一の正しいソースになろうと急いでる感じ。dns over httpsをやろうとしてsystemd-resolvedを有効にしてみたけど、結局DNSがゼロになっちゃった。/etc/resolv.confとヘルパースクリプトの方が、ずっと安定してて簡単だと思うわ。

└

OpenSSHをソケットアクティベートサービスに変更する理由は何なの？問題があることを考えると、利点が欠点を上回るってことなのかな。

└

OpenSSHサーバーはsystemdソケットアクティベートとしてインストールされているので、/etc/ssh/sshd_configは無視される。sshdは起動時にまだ/etc/ssh/sshd_configを読み込む。私の知る限り、これは実行ファイルにハードコーディングされてる。Debianが変更したのはデーモンが起動する前のこと：サービスはソケットアクティベートされている。だから、もしsshdのデフォルトポートを設定で変更したら、アクティベーションも変更しないといけない：- ソケットアクティベートなしでsshd@サービスを有効にするか、- デフォルトでポート22が設定されているsshd.socketファイルを修正する（systemctl edit sshd.socket）。Debianにはこのサービスによって読み込まれる環境ファイル（/etc/default/ssh）があるから、ポートをそこに変数として設定してソケットアクティベーションで読み込むこともできる。でもそうするとOpenSSHのファイルと競合しちゃうんだよね。だから、Debianでは/etc/default/を二次設定として使うのが嫌なんだ。

え、Python 3.13 が stable に入ってるの？！(Debian 大好き) デフォルトで最新の Python が使えるようになるのにちょっと慣れるまで時間がかかりそう。

└

venvとPython実行可能バージョンのメンテナを使うのは、まだ良いプラクティスだと思う（uvは両方に使えるし）。

Trixieをノートパソコンで使い始めて1年くらい経つけど、めっちゃ良い経験だった。新しいThinkPadを買ったんだけど、Debian Stableに必要なドライバーがまだ入ってないことを考えてなかったんだ。今はTrixieのおかげで、KDE Plasmaの比較的新しいバージョンが使えて、本当に助かってる。Waylandに関しても、いい方向にすごく変わったし。Trixieの体験は、Ubuntuの時よりもずっと良い（さようなら！）し、これが不安定なリリースだなんて信じられない。1回だけ壊したことがあるけど、それは自分のミス（必要なパッケージが全て準備できてないのに強制的にアップデートした）だったから、教訓になったよ。

DebianとDovecotを安定版で使ってる人への警告。今回の新しい安定版リリースでは、Dovecotのアップデートが設定を壊しちゃうよ: https://willem.com/blog/2025-06-04_breaking-changes/

└

それだけじゃないんだよね：Dovecot 2.4ではdsync、replicator、directorの機能も削除されるんだ。[1] これはイライラするし、大きな損失だよ。これらの機能があれば、非常にシンプルで信頼性の高い2ノード（アクティブ-アクティブ）の冗長セットアップが可能だったのに、2.4ではそれができなくなる。個人のメールサーバーのHAを実現するために何年も使ってきたけど、今は代替手段を探さなきゃいけないな。とりあえずはDebian BookwormとDovecot 2.3を使い続けるつもり。[1] https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2....

昨年の9月にFrameworkのノートパソコンを買ってからTrixieを使ってるけど、すごく良い感じ。20年ぶりのLinux体験で、すべてが信じられないくらい安定してる。今は、テスト中の環境が突然安定したらどうなるのか、次のテストにどうやって移行するかを考えないといけないかな。

└

基本的に2つの設定があるよ。もしsources.listが明示的にTrixieになってたら、そのままそこに留まる。テスト版になってたら、次のテストリリースがちゃんと来るよ。

2023年の終わり頃からtesting/trixieを使ってるよ。（基本的にいつもテスト版を使ってるけど、安定版が安定するまで約6ヶ月は安定版を使って、パッケージの入れ替えが激しい新テストを避けてる。）Debianから期待してる通り、退屈だけど機能的だね。アップデート後にシステムが起動しなくなる問題には一度も遭遇したことがないよ（テスト版の時は大体2〜4週間ごとにアップデートしてる）。ほとんどのことは、壊れたパッケージを直したり、魔法のaptコマンドを唱えたりする必要もなく動いてる。Debianにはいつも感心させられてる。完璧ではないけど、ボランティアや寄付、スポンサーでできることはすごいよね。

└

これ、俺かも。俺も同じことしてるし、2026年の初めにForkyにアップデートする予定だよ。

└

2004年頃から不安定な状態で使ってる。アップデートを1年飛ばした時にだけ壊れたかな。

└

だからこそ、Linuxをインストールする時はDebianを使ってるんだ。安定して動いてくれるものが欲しいけど、最新のソフトウェアが必要ってわけじゃない。システムに時間をかけられるし、しっかりしてるって分かってるからね。もしパッケージリポジトリにない新しいソフトが必要になったら、自分でコンパイルする能力があるし、少なくとも自分のシステムを変更してやりたいことを動かすって選択肢もある。要するに、不安定になる可能性は自分の意識的な選択で、時々それを選ぶこともあるんだ。

これ、楽しみだな。Debian 12にはめっちゃ感動したよ。2003年頃からLinuxユーザーをやったりやめたりしてるけど、このリリースでついに完全に切り替えた。今のところ、WindowsやmacOSよりも不安定さが少ない気がする。こんなこと言う日が来るとは思わなかった。

ハクソク