はじめに
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における確認例です)。
ストレージ上の空き容量が十分に確保できていることが確認できたところで、アップグレード前におけるkernelのバージョンを確認します。
以下のコマンドを実行し、Fedora 35を最新の状態にアップデートします。
アップデートが終わったら、以下のコマンドを実行して再起動します。この段階でWordPress関連のディレクトリのownerがnginxでなくなってしまい、本Webサイトのページへのアクセスができなくなったので、再起動後にownerをいったんnginxに戻します(戻し方はこちら参照)。
「shutdown -r now」でも再起動はできますが、今回はrebootコマンドで行いました(rebootコマンドを選択したことについては、特に深い意味や理由はありません)。
Fedora 36へのアップグレード
Fedora 35の最新の状態へのアップグレード中にはエラーが発生しませんでしたので、Fedora 36へのアップグレードを行います。
kernelのバージョンの確認
Fedora 35を最新の状態に更新後、以下のコマンドを実行します。
dnf-plugin-system-upgradeパッケージの更新
以下のコマンドを実行し、dnf-plugin-system-upgradeパッケージを更新します。
特にエラーもなく更新(というよりは最新版であるかどうかの確認)が完了しました。
アップグレードのためのダウンロード(1回目)
ここからが本当のアップグレード作業です。
以下のコマンドを実行し、アップグレードに必要なパッケージをダウンロードします。
なんかFedora 34→35のアップグレード時と比較するとダウンロードするファイルのデータ量が3.3倍くらい(2.0G→6.6G)に増えているような気がするのですが、気にしないことにします。
エラーが発生したので、対応します。
必要なパッケージを定めるためにdnfコマンドがパッケージ間の依存関係を調べてくれるのですが、依存関係が見つからないと前節のコマンドはエラーを返して途中で終了してしまいます。
PC群に対する前節のコマンドの実行中に以下のパッケージがインストールされたPCでは当該パッケージの依存関係の調査に失敗していました。そこで以下のコマンドを実行し、依存関係の調査に失敗したパッケージについてはすべてこの段階で削除しました。
openssl-static
本Webサイトが稼働しているサーバのアップグレード時にopenssl-staticの依存関係の解決に以下の通り失敗しました。
そこで、以下のコマンドを実行してopenssl-staticパッケージを削除しました。
php-phpmailer6
php-phpmailer6の依存関係の解決に以下の通り失敗します。
上記のエラーが出た場合には /etc/wordpress/wp-config.php のバックアップを取ってから以下のコマンドで削除を実行します。
上記のコマンドを実行するとphp-phpmailer6パッケージだけでなく、WordPressのパッケージも削除されます。
WordPressのパッケージはアップグレード後に再度インストールし、/etc/wordpress/wp-config.phpをリストアします(後述)。
精神的には少々つらいところですが、作業を進めます。
アップグレードのためのダウンロード(2回目)
対応作業が終了したところで、気を取り直してもう一回以下のコマンドを実行します。
パッケージ間の依存関係の調査に成功すると、以下のようなメッセージとともにdnfコマンドが終了します。
再起動及びアップグレードの実行
アップグレードに必要なパッケージのダウンロードが成功したら、以下のコマンドを実行しPCを再起動します。
再起動後のアップグレード作業には20-30分ほどかかりますので、他の作業をしながら待ちます。
kernelのバージョンの確認(アップグレード後)
アップグレードが終了したら、以下のコマンドを実行してkernelのバージョンを確認します。
Fedora 36用のkernelがインストールされ、かつ使われているようです。
動作確認
WordPress
再インストール
今回のアップグレードではWordPressの再インストールが必要になります。
以下のコマンドを実行して再インストールを行います。
設定ファイルのリストア
バックアップした/etc/wordpress/wp-config.phpをリストアします。
設定ファイル及びログファイル用のディレクトリのownerの設定
Fedoraでnginxを使ってWebサーバを運用していて、かつWordPressのバージョンが変わると必ず必要になるっぽいこの作業ですが…
この作業を一撃で行うためのシェルスクリプト(*1)をGitHub Gistに置きました。
| #!/bin/sh | |
| # See https://pandanote.info/?p=8118 for details. | |
| chown -R nginx /etc/wordpress | |
| chown -R nginx /var/lib/php/session | |
| chown -R nginx /var/lib/php/wsdlcache/ | |
| chown -R nginx /var/lib/php/opcache/ | |
| chown -R nginx /usr/share/wordpress/wp-content/uploads/ | |
| chown nginx:nginx /var/log/nginx |
by 実際にはもう少しコマンド等を追加したものを使っていますが、ディレクトリの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コマンドで確認したところ、
となっていたので、以下のコマンドを実行して設定を変更しました。
nuc_led
nuc_ledモジュールはこちらに書いた手直しを行ったものをインストールしました。
この記事を最初に書いた時点(2022年5月)では特に問題はないようです。
Galleon及びsnap
PC群のうちの1台にTezosのウォレットのバックアップとしてGalleonをインストールしている(Linuxの日本語環境では文字化けが発生するため常用はしていません。緊急事態用です。)ので、Galleonのパッケージを管理しているsnapdを以下のコマンドを実行してアップグレード後、Galleonをrefreshしました。
Galleonのアップグレードはバックグラウンドプロセスとして実行されますので、時々以下のコマンドを実行して状況を確認します。
上記の手順を試したPCではアップグレードに時間がかかりましたが、何とかアップグレードに成功しました。
まとめ
WordPressのパッケージが依存先のパッケージの削除に伴って一時的に削除されるという想定外の事態に見舞われましたが、アップグレード後に再インストールを行い、さらにバックアップした設定ファイル(wp-config.php)をリストアすることで何とか復旧できました。
Fedora 35までのアップグレードと比較するとアップグレードに必要なパッケージのデータサイズがかなり大きくなっているような気がしますので、アップグレードの実行前にストレージの空き容量は必ず確認した方が良いでしょう。
この記事は以上です。
References / 参考文献
Fedora 34から35へのupgrade 
Fedora36から37へのアップグレードをしたところ、WordPressのエディタからカスタムボタンが消えるので、復旧作業が必要だった件。 
Fedora 37から38へのアップグレード 
Fedora 38から39へのアップグレード 