Fedora 35から36へのアップグレード時に一時的にWordPressを削除することになった件。

By | 2022年5月18日

はじめに

2022年5月10日にFedora 36が登場しました。

そこで、

  • 自宅の1台の物理サーバ、
  • VirtualBox上のゲストOSとして稼働している4個の仮想サーバ、及び
  • さくらインターネットのVPSで稼働している2台のサーバ群

(以上ここまでのサーバ及びサーバ群を総称して「PC群」と書きます。)のFedora 35をFedora 36にサクサクとアップグレードする…

つもりだったのですが、VirtualBox上のゲストOSとして稼働している4個の仮想サーバのアップグレードの作業効率を上げようと考え、アップグレードの対象となる2個の仮想サーバを同時に起動しアップグレードの作業を始めたところ、

というような画面が表示されたあたり(=アップグレード用のパッケージのインストール作業中)でホストOSがメモリ不足で停止してしまうという現象に遭遇しました(復旧(?)までの顛末はこちら)。

VirtualBox上のゲストOSとして稼働している4個の仮想サーバのFedora 36へのアップグレード作業は最終的には成功したものの、上記のトラブルの影響で重要度の低い仮想サーバについては復旧を諦めることとなってしまいました。

そこで、自宅の1台の物理サーバ及びさくらインターネットのVPSで稼働している2台のサーバ群のアップグレードについてはメモリ不足に陥ることのないよう、慎重にアップグレード作業を行うことにしたのですが…

WordPressを途中でいったん削除しないと作業が先に進まないことが発覚したので、対処策について書きます。

また、アップグレード中に発生しがちなその他の小問題とそれらに対する対応策についても書きます。

スポンサーリンク

事前作業

データ等のバックアップ

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

VirtualBox上のゲストOSにデータ倉庫的なものを用意してあるので、そこにバックアップを取得します。

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

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


スポンサーリンク

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

前回のアップグレードまでは、NUC(←Amazonへのリンクです。うちのNUCはこちら)のFedoraのroot partitionに空きがあまりなかったのですが、HP Elite Dragonfly G2の購入に伴うストレージの組み換えによって、root partitionの容量が470GBまで拡大できるようになりました。

したがって、root partitionの残り容量について慎重に確認する必要性は薄れましたが、念のためdfコマンドでストレージ上での空き容量を確認します(以下の例はNUCにおける確認例です)。

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

 

ストレージ上の空き容量が十分に確保できていることが確認できたところで、アップグレード前における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を最新の状態にアップデートします。

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

スポンサーリンク

 

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

$ sudo reboot

 

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

Fedora 36へのアップグレード

Fedora 35の最新の状態へのアップグレード中にはエラーが発生しませんでしたので、Fedora 36へのアップグレードを行います。

kernelのバージョンの確認

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

[panda@pandanote.info ~]$ uname -a
Linux pandanote.info 5.17.6-200.fc35.x86_64 #1 SMP PREEMPT Mon May 9 14:22:05 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

 

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


スポンサーリンク

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

# dnf install dnf-plugin-system-upgrade --best
[sudo] panda のパスワード:
パッケージ python3-dnf-plugin-system-upgrade-4.0.16-1.fc35.noarch は既にインストールされています。
依存関係が解決しました。
行うべきことはありません。
完了しました!

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

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

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

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

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

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

 

なんかFedora 34→35のアップグレード時と比較するとダウンロードするファイルのデータ量が3.3倍くらい(2.0G→6.6G)に増えているような気がするのですが、気にしないことにします。

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

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

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

openssl-static

本Webサイトが稼働しているサーバのアップグレード時にopenssl-staticの依存関係の解決に以下の通り失敗しました。

エラー:
問題: パッケージ openssl-static-1:1.1.1n-1.fc35.x86_64 には openssl-devel(x86-64) = 1:1.1.1n-1.fc35 が必要ですが、どのプロバイダーからもインストールできません
– openssl-devel-1:1.1.1n-1.fc35.x86_64 はdistupgradeレポジトリーに属していません
– インストール済パッケージの問題 openssl-static-1:1.1.1n-1.fc35.x86_64
(インストール不可のパッケージをスキップするには、’–skip-broken’ を追加してみてください)

 

そこで、以下のコマンドを実行してopenssl-staticパッケージを削除しました。

# dnf remove openssl-static

 

php-phpmailer6

php-phpmailer6の依存関係の解決に以下の通り失敗します。

エラー: トランザクションテストエラー:
ファイル /usr/share/php/PHPMailer/PHPMailer6/PHPMailer.php は php-phpmailer6-6.6.0-1.fc36.noarch と wordpress-5.9.3-1.fc36.noarch のインストールで競合しています
ファイル /usr/share/php/PHPMailer/PHPMailer6/SMTP.php は php-phpmailer6-6.6.0-1.fc36.noarch と wordpress-5.9.3-1.fc36.noarch のインストールで競合しています

 

上記のエラーが出た場合には /etc/wordpress/wp-config.php のバックアップを取ってから以下のコマンドで削除を実行します。

# dnf remove php-phpmailer6

 

上記のコマンドを実行するとphp-phpmailer6パッケージだけでなく、WordPressのパッケージも削除されます。😱

WordPressのパッケージはアップグレード後に再度インストールし、/etc/wordpress/wp-config.phpをリストアします(後述)。

精神的には少々つらいところですが、作業を進めます。

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

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

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

合計サイズ: 6.6 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.17.6-300.fc36.x86_64 #1 SMP PREEMPT Mon May 9 15:47:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

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

動作確認

WordPress

再インストール

今回のアップグレードではWordPressの再インストールが必要になります。

以下のコマンドを実行して再インストールを行います。

# dnf install wordpress

 

設定ファイルのリストア

バックアップした/etc/wordpress/wp-config.phpをリストアします。

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

Fedoraでnginxを使ってWebサーバを運用していて、かつWordPressのバージョンが変わると必ず必要になるっぽいこの作業ですが…

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

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

データベースの更新

WordPressにログインすると以下の画面が表示されますので、「WordPressデータベースを更新」ボタンをクリックしてデータベースを更新します。

すると…

と表示されますので、「続ける」をクリックするとダッシュボードを表示させることができます。

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

(*1)のシェルスクリプトを使ってownerの設定を変更します。

Wake-On-Lan

アップグレードを行うたびにコロコロと変わるWake-On-Lan及びWake-On-Lanに関連した構成ですが、今回のFedora 36へのアップグレードではWake-On-Lanのパケットを受診するためのインターフェース名がeno1に変わってしまいました。

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

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

 

となっていたので、以下のコマンドを実行して設定を変更しました。

# nmcli connection modify eno1 802-3-ethernet.wake-on-lan magic

 

nuc_led

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

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

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ではアップグレードに時間がかかりましたが、何とかアップグレードに成功しました。

まとめ

WordPressのパッケージが依存先のパッケージの削除に伴って一時的に削除されるという想定外の事態に見舞われましたが、アップグレード後に再インストールを行い、さらにバックアップした設定ファイル(wp-config.php)をリストアすることで何とか復旧できました。

Fedora 35までのアップグレードと比較するとアップグレードに必要なパッケージのデータサイズがかなり大きくなっているような気がしますので、アップグレードの実行前にストレージの空き容量は必ず確認した方が良いでしょう。

この記事は以上です。

References / 参考文献

  1. DNF System Upgrade
  2. Upgrade to Fedora 36 from Fedora 35 using DNF