Fedora 34から35へのupgrade

By | 2021年11月9日 , Last update: 2022年11月27日

はじめに

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

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

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

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

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

スポンサーリンク

作業の進め方

今回のアップグレードは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における確認例です)。

[panda@pandanote.info ~]$ df -h /
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/fedora-root 38G 25G 18G 67% /

 

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

[panda@pandanote.info ~]$ uname -a
Linux pandanote.info 5.11.16-300.fc34.x86_64 #1 SMP Wed Apr 21 13:18:33 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

 

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

$ sudo dnf upgrade --refresh
(中略)
トランザクションの概要
================================================================================
インストール 18 パッケージ
アップグレード 1084 パッケージ
削除 3 パッケージ
 
ダウンロードサイズの合計: 1.3 G
これでよろしいですか? [y/N]: y
(以下略)

スポンサーリンク

 

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

$ sudo reboot

 

「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]。

# restorecon -Rv /var/lib/rpm
# rpmdb --rebuilddb

 

Fedora 35へのアップグレード

kernelのバージョンの確認


スポンサーリンク

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

[panda@pandanote.info ~]$ uname -a
Linux pandanote.info 5.14.16-201.fc34.x86_64 #1 SMP Wed Nov 3 13:57:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

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

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

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

# dnf install dnf-plugin-system-upgrade --best
[sudo] panda のパスワード:
Fedora 34 – x86_64 23 kB/s | 7.0 kB 00:00
Fedora 34 – x86_64 – Updates 12 kB/s | 5.7 kB 00:00
MongoDB Repository 6.0 kB/s | 2.5 kB 00:00
パッケージ python3-dnf-plugin-system-upgrade-4.0.15-1.fc34.noarch は既にインストールされています。
依存関係が解決しました。
行うべきことはありません。
完了しました!

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

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

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

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

# dnf system-upgrade download --refresh --releasever=35
(中略)
トランザクションの概要
================================================================================
インストール 98 パッケージ
アップグレード 2492 パッケージ
削除 4 パッケージ

ダウンロードサイズの合計: 2.0 G
DNF はパッケージのダウンロード、gpgキーのインストール、トランザクションのチェックのみ行います。
(以下略)

 

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

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

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

httpcomponents-client-cache

# dnf remove httpcomponents-client-cache

 

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

# dnf remove ocaml-rope-devel ocaml-rope ocaml-oasis-devel ocaml-oasis

 

php-pecl-apcu-bc

# dnf remove php-pecl-apcu-bc

 

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

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

# dnf system-upgrade download --refresh --releasever=35
(中略)
トランザクションの概要
================================================================================
インストール 98 パッケージ
アップグレード 2492 パッケージ
削除 4 パッケージ

ダウンロードサイズの合計: 2.0 G
DNF はパッケージのダウンロード、gpgキーのインストール、トランザクションのチェックのみ行います。
(以下略)

 

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

完了しました!
ダウンロード完了! アップグレード開始には 'dnf system-upgrade reboot' を使ってください。
キャッシュされた metadata と transaction の削除には 'dnf system-upgrade clean' を使ってください
ダウンロード済みのパッケージは、次の正常なトランザクションまでキャッシュに保存されました。
'dnf clean packages' を実行することでキャッシュパッケージを削除できます。

 

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

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

# dnf system-upgrade reboot

 

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

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

スポンサーリンク

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

[panda@pandanote.info ~]$ uname -a
Linux pandanote.info 5.14.16-301.fc35.x86_64 #1 SMP Wed Nov 3 13:55:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

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

動作確認

NetworkManager

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

# nmcli connection delete ‘有線接続 1’
# sudo nmcli device set ens4 autoconnect no

 

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

Wake-On-Lan

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

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

$ nmcli connection s enp3s0 | grep ethernet
(前略)
802-3-ethernet.wake-on-lan: magic
(後略)

 

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

なお、接続のタイプ名が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のコンテキストを忘れずに設定します。

# cd /usr/share/wordpress/wp-content/plugins
# restorecon -R social-networks-auto-poster-facebook-twitter-g

 

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

nuc_led

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

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

firewalld

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

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

# firewall-cmd --permanent --zone=FedoraServer --add-interface=tun0
# firewall-cmd --permanent --zone=FedoraServer --add-interface=tun0
# firewall-cmd --add-forward --zone=FedoraServer
# firewall-cmd --permanent --add-forward --zone=FedoraServer

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

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

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

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

Python3

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

\$ pip install httplib2
\$ pip install pytz
\$ pip install google-api-python-client

 

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

\$ sudo pip install httplib2
\$ sudo pip install matplotlib
\$ sudo pip install pandas
\$ sudo pip install seaborn

 

Galleon及びsnap

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

# dnf update snapd
# snap refresh galleon

 

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

$ snap changes
ID Status Spawn Ready Summary
7 Done today at 11:45 JST today at 12:50 JST Auto-refresh 5 snaps

 

上記の手順を試した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)