Fedora 34から35へのupgrade

はじめに

2021年11月2日にFedora 35が登場したので、さっそくFedora 34で稼働している自宅とさくらインターネットのVPSに点在する総勢4台のサーバ(以下、「PC」と書きます。)及びサーバ群(以下、単に「PC群」と書きます。)をFedora 35にサクサクとアップグレードすることにしました。

例によってインストールに失敗してもダメージの少ない方から順番にアップグレード作業を行い、特に大きな問題が発生することもなくアップグレード作業を終了することができましたが…

最近本Webサイトも午前1時ごろまでページビューがそれなりにあります(ありがとうございます。🙇‍♂️)ので、本Webサイトの更新作業だけは朝方に行いました。

panda大学習帳のサーバのOSをFedora34から #Fedora35 にアップグレードするため、明日の6時頃あたりにアクセスできなくなる時間帯があるかもしれません。🙇‍♂️#fedoraproject#Linux#lifeinyokohama

— pandanote.info (@Pandanote_info) November 8, 2021

毎度特に大きな問題が発生することなく終了はするのですが、小さい問題はちょこちょこと発生します。

そこで、この記事ではアップグレード作業自体の他にアップグレード中に発生しがちな小問題とそれらに対する対応策についても書きます。

作業の進め方

今回のアップグレードはFedora Projectのページ[1]及び[2]に記載の手順に従って作業を進めていきます。

なお、作業自体については概ね上記の記事に沿った手順で進めることができます。

事前作業

データ等のバックアップ

最初に重要なデータ等のバックアップを取ります。

一番最初にアップグレード作業を行うPCにデータ倉庫的なものを用意してあるので、そこにバックアップを取得します。

Fedora 34の最新の状態へのアップデート

Fedora 35へのアップグレードを行う前にFedora 34を最新の状態にアップデートする必要があります。

スポンサーリンク

アップデートを実行する前に必要なパッケージがダウンロードされるので、ダウンロードしたパッケージの格納用のスペースとしてrootパーティション上にそれなりの空き容量が必要です。

今回のアップグレードでも、NUC(←Amazonへのリンクです。うちのNUCはこちら)のFedoraをアップグレードする際に6.2GB程度の空き容量が必要である旨のメッセージが表示されたので、journalを削除後、root partitionを3GBほど拡張し、13GB程度の空き容量を確保することにしました(確保の方法についてはこの記事をご参照ください。XFSは偉大です)。

空き容量の確保後にdfコマンドでストレージ上での空き容量を念のため確認します(以下の例はNUCにおける確認例です)。

ストレージ上の空き容量が十分に確保できていることが確認できたところで、アップグレード前におけるkernelのバージョンを確認します。

以下のコマンドを実行し、Fedora 34を最新の状態にアップデートします。

アップデートが終わったら、以下のコマンドを実行して再起動します。この段階でWordPress関連のディレクトリのownerがnginxでなくなってしまい、本Webサイトのページへのアクセスができなくなったので、再起動後にownerをいったんnginxに戻します(戻し方はこちらの「設定ファイル用のディレクトリのownerの設定」の項、またはこの記事の後ろの方参照)。

「shutdown -r now」でも再起動はできますが、今回はrebootコマンドで行いました(rebootコマンドを選択したことについては、特に深い意味や理由はありません)。

アップデート作業中におけるエラー

PC群のうちの1台で”RPM: 警告: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend.”と表示されてアップデート作業中にエラーが発生し、処理が中断してしまいました。

そんな場合には以下のコマンドを実行後、dnf –refresh upgradeを再び実行します[3]。

Fedora 35へのアップグレード

kernelのバージョンの確認

Fedora 34を最新の状態に更新後、以下のコマンドを実行します。

 
Fedora 33→34のアップグレードでは、Fedora 33を最新の状態にした時のみ作業の前後でkernelのバージョンが変わっていました。そこで、アップグレードの作業の前後ではベースとなっているkernelのバージョンは変わらないと判断したので、この時点で確認です。

dnf-plugin-system-upgradeパッケージの更新

以下のコマンドを実行し、dnf-plugin-system-upgradeパッケージを更新します。

 
特にエラーもなく更新(というよりは最新版であるかどうかの確認)が完了しました。

アップグレードのためのダウンロード(1回目)

ここからが本当のアップグレード作業です。

以下のコマンドを実行し、アップグレードに必要なパッケージをダウンロードします。

エラーが発生したので、対応します。

必要なパッケージを定めるためにdnfコマンドがパッケージ間の依存関係を調べてくれるのですが、依存関係が見つからないと前節のコマンドはエラーを返して途中で終了してしまいます。

PC群に対する前節のコマンドの実行中に以下のパッケージがインストールされたPCでは当該パッケージの依存関係の調査に失敗していました。そこで以下のコマンドを実行し、依存関係の調査に失敗したパッケージについてはすべてこの段階で削除しました。

httpcomponents-client-cache

ocaml-rope-devel, ocaml-rope, ocaml-oasis-devel, ocaml-oasis

php-pecl-apcu-bc

アップグレードのためのダウンロード(2回目)

対応作業が終了したところで、気を取り直してもう一回以下のコマンドを実行します。

パッケージ間の依存関係の調査に成功すると、以下のようなメッセージとともにdnfコマンドが終了します。

再起動及びアップグレードの実行

アップグレードに必要なパッケージのダウンロードが成功したら、以下のコマンドを実行しPCを再起動します。

再起動後のアップグレード作業には20-30分ほどかかりますので、他の作業をしながら待ちます。☕

kernelのバージョンの確認(アップグレード後)

アップグレードが終了したら、以下のコマンドを実行してkernelのバージョンを確認します。

 
Fedora 35用のkernelがインストールされ、かつ使われているようです。

動作確認

NetworkManager

1台のPCで「有線接続 1」という名前のインターフェースの生成を試みて失敗した旨のログが/var/log/messagesに延々と出力されていたので、以下のコマンドを実行して生成を試みないよう設定しました。

なお、上記以外の設定についてはFedora 35へのアップグレード前後では変更されていなかったので、そのまま使うことにしました。

Wake-On-Lan

Fedora 34へのアップグレード時には削除されてしまったWake-On-Lanの設定ですが、今回のFedora 35へのアップグレードでは削除されませんでした。

Wake-On-Lanで起動される側の設定をnmcliコマンドで確認したところ、

となっていたので、設定自体は問題ないと思います(実際、動きましたし)。

なお、接続のタイプ名がethernetから802-3-ethernetに変わっているようです。

WordPress

設定ファイル及びログファイル用のディレクトリのownerの設定

Fedoraでnginxを使ってWebサーバを運用する限りは必ず必要になるっぽいこの作業ですが…

この作業を一撃で行うためのシェルスクリプトをGitHub Gistに置きました。✨

実際にはもう少しコマンド等を追加したものを使っていますが、ディレクトリのownerの設定を変えるだけなら↑のシェルスクリプトを実行すれば十分です。

WordPressプラグインの更新

長年の悲願だった前節のシェルスクリプトができたところで、さっそくWordPressの既存の記事を更新してみたところ、nginx のログファイルに「定義されていないget_magic_quotes_gpc()が呼ばれている」という旨のエラーページが表示されてしまいました。＿|￣|○

Fedora 35へのアップグレードに伴いPHPのバージョンが8.0.12になりますが、バージョン8.0.0以降ではget_magic_quotes_gpc関数が削除されたために「関数が見つからないよ。」と言ってきているもののようです。

このエラーの原因となっているプラグイン(Social Networks Auto-Posterプラグイン)もかなり前にインストールしたもので最新版ではなかったため、この際最新版に交換してみました。

交換後はrestoreconコマンドを用いてSELinuxのコンテキストを忘れずに設定します。

その結果、上記のエラーはログに出力されなくなり、エラーページも表示されなくなりました。

nuc_led

nuc_ledモジュールはこちらに書いた手直しを行ったものをインストールしました。

この記事を最初に書いた時点(2021年11月)では特に問題はないようです。

firewalld

自宅のPC-さくらのVPS間でOpenVPNを使って仮想的なネットワークを構成しているのですが、自宅PC側のgatewayとなっているNUC側のネットワークインタフェースがfirewalldにおけるzoneがtrustedに設定されていました。

この設定により、自宅のPC-さくらのVPS間で仮想的なネットワークを経由したping等が通らなくなっていたので、以下のコマンドを実行してfirewalldの設定を変更しました。

 
具体的には以下の設定を変更しています。

1. OpenVPN用のネットワークインタフェースのzoneをFedoraServerに変更。
2. FedoraServerの設定のうち、forwardがnoに設定されていたので、yesに変更。

これは原因がわかるまでにかなりの時間を要してしまいました。

上記のコマンドを実行したところで、いったん自宅のPC側のgatewayを再起動して設定が正しく行われていることを確認します。

Python3

Python3のバージョンが3.10.0になったので、以下のコマンドを実行してパッケージをインストールします。

なお、第三倉庫(仮)でPython3を使ってグラフを描画しているので、以下のパッケージも忘れずにインストールします。

Galleon及びsnap

PC群のうちの1台にTezosのウォレットのバックアップとしてGalleonをインストールしている(Linuxの日本語環境では文字化けが発生するため常用はしていません。緊急事態用です。)ので、Galleonのパッケージを管理しているsnapdを以下のコマンドを実行してアップグレード後、Galleonをrefreshしました。

Galleonのアップグレードはバックグラウンドプロセスとして実行されますので、時々以下のコマンドを実行して状況を確認します。

上記の手順を試したPCではアップグレードに時間がかかりましたが、何とかアップグレードに成功しました。

まとめ

今回のFedora 35へのアップグレードではWordPressのプラグインが古かったことに起因する問題が珍しく発生しましたが、その他の部分については概ね順調にアップグレード作業が進みました。😀

テーブルのカラムをDROPできるようになったSQLite3(3.36.0)が使えるようになったのが個人的には刺さったところですが、その件については別の記事で書くかもしれません。

今回アップグレードしたFedora 35についてはこの状態で使ってみるつもりです。

この記事は以上です。

References / 参考文献

1. DNF System Upgrade
2. Upgrade to Fedora 35 from Fedora 34 using DNF
3. Bug 1960991 – RPM unusable following upgrade to Fedora 34: cannot open Packages index using bdb_ro – Operation not permitted (1)

Related Posts / 関連ページ

Fedora 35から36へのアップグレード時に一時的にWordPressを削除することになった件。 Fedora 32からFedora 33へのupgrade バックエンドのGROWIサーバの電源が入っていない時に、「503 たぶんサーバの電源が切れています。」とフロントエンドのnginxに返してもらうための設定のようなもの(2/2,書き込み側のお話)。 Fedora 33から34へのupgrade