はじめに
2021年4月30日にFedora 34が登場したので、自宅とさくらのVPSに点在する総勢4台のFedora 33のサーバ等を順番にFedora 34にアップグレードすることにしました。
例によってインストールに失敗してもダメージの少ない方から順番にアップグレード作業を行い、特に大きな問題が発生することもなくアップグレード作業を終了することができました。
毎度特に大きな問題が発生することなく終了はするのですが、小さい問題はちょこちょこと発生するので、この記事ではそれらの小問題と対応策について書きます。
作業の進め方
今回のアップグレードはFedora Projectのページ[1]に記載の手順に従って作業を進めていきます。
なお、作業の内容自体については概ね上記の記事に沿った手順で進めることができます。
事前作業: Fedora 33のアップデート
Fedora 34へのアップグレードを行う前にFedora 33を最新の状態にアップデートする必要があります。
アップデートの際には必要なパッケージがダウンロードされるので、ダウンロードしたパッケージの格納用のスペースとしてrootパーティション上にそれなりの空き容量が必要です。
Fedora 33へのアップグレードまではパッケージの格納用のスペースを約3GB程度と見積もっていましたが、NUCのFedoraをアップグレードする際に6.2GB程度の空き容量が必要である旨のメッセージが表示されたので、念のため10GB程度の空き容量を確保することにしました(確保の方法についてはこの記事をご参照ください。XFSは偉大です)。
そこで、dfコマンドでストレージ上での空き容量を確認します(以下の例は確認例です)。
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/fedora-root 39G 22G 18G 55% /
ストレージ上の空き容量が十分に確保できていることが確認できたら以下のコマンドを実行し、Fedora 33を最新の状態にアップデートします。
アップデートが終わったら、以下のコマンドを実行して再起動します。
スポンサーリンク
Fedora 34へのアップグレード
アップグレードのためのダウンロード(1回目)
Fedora 33を最新の状態に更新後、以下のコマンドを実行します。
$ sudo dnf system-upgrade download --refresh --releasever=34
エラーが発生したので、対応します。
前節のコマンドを実行してみたところ、以下のようなエラーが発生し、アップグレードに失敗しました。
問題 1: パッケージ cockpit-docker-219-1.fc31.x86_64 には cockpit-bridge >= 122 が必要ですが、どのプロバイダーからもインストールできません
– パッケージ cockpit-bridge-241-1.fc34.x86_64 は cockpit-docker < 233 と競合しています。これは cockpit-docker-219-1.fc31.x86_64 により提供されます
– パッケージ cockpit-bridge-243-1.fc34.x86_64 は cockpit-docker < 233 と競合しています。これは cockpit-docker-219-1.fc31.x86_64 により提供されます
– cockpit-bridge-229-1.fc33.x86_64 はdistupgradeレポジトリーに属していません
– インストール済パッケージの問題 cockpit-docker-219-1.fc31.x86_64
問題 2: パッケージ php-imap-7.4.16-1.fc33.x86_64 には php-common(x86-64) = 7.4.16-1.fc33 が必要ですが、どのプロバイダーからもインストールできません
– php-common-7.4.16-1.fc33.x86_64 はdistupgradeレポジトリーに属していません
– インストール済パッケージの問題 php-imap-7.4.16-1.fc33.x86_64
(競合するパッケージを置き換えるには、コマンドラインに ‘−−allowerasing’ を追加してみてください または、’−−skip-broken’ を追加して、インストール不可のパッケージをスキップしてください)
cockpit-docker-219-1.fc31.x86_64
4台中2台のサーバでcockpit-docker-219-1.fc31.x86_64が原因と思われるエラーが発生しました。
Docker自体を使っていなかったりするので、以下のコマンドを実行してcockpit-dockerパッケージを削除しました。
アップグレード後に必要になった場合にはインストールをやり直す方向性です。
php-imap-7.4.16-1.fc33.x86_64
また、4台のサーバすべてでphp-imap-7.4.16-1.fc33.x86_64が原因と思われるエラーが発生しました。
とりあえず、以下のコマンドを実行し、php-imapパッケージを削除しました。
RPMのデータベースの再作成
アップグレードを実行しようとしたところ、上記のエラーメッセージとは別に、4台中3台のサーバで、
というメッセージが表示されました[2]。
そこで以下のコマンドを実行し、RPMのデータベースを作り直しました。
アップグレードのためのダウンロード(2回目)
対応作業が終了したところで、気を取り直してもう一回以下のコマンドを実行します。
すると…
================================================================================
インストール 119 パッケージ
アップグレード 2383 パッケージ
削除 5 パッケージ
ダウングレード 16 パッケージ
ダウンロードサイズの合計: 1.8 G
DNF はパッケージのダウンロード、gpgキーのインストール、トランザクションのチェックのみ行います。
これでよろしいですか? [y/N]:
(中略)
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
完了しました!
ダウンロード完了! アップグレード開始には ‘dnf system-upgrade reboot’ を使ってください。
キャッシュされた metadata と transaction の削除には ‘dnf system-upgrade clean’ を使ってください
ダウンロード済みのパッケージは、次の正常なトランザクションまでキャッシュに保存されました。
‘dnf clean packages’ を実行することでキャッシュパッケージを削除できます。
のように表示されました。
パッケージのダウンロードが成功裏に終了しているようです。
reboot & アップグレード
以下のコマンドを実行し、reboot及びアップグレードを実行します。
アップグレードに要する時間はサーバによって異なりますが30-40分程度で、Fedora 33へのアップグレード時と比較すると少々長めでした。
kernelのバージョンの確認(アップグレード後)
アップグレードが終了したら、以下のコマンドを実行してkernelのバージョンを確認します。
Linux pnr.pandanote.info 5.11.17-300.fc34.x86_64 #1 SMP Wed Apr 28 14:21:28 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
kernelのバージョンは5.11.17でした。
Fedora 34用にビルドされたもののようです。
動作確認
NetworkManager
使用しないネットワークインターフェースの無効化
さくらのVPSのサーバではネットワークのインタフェースとしてens5が設定されますが、このインターフェースが設定されているとこれを有効化しようとして失敗した旨のログが延々と/var/log/messagesに出力されてしまい、ストレージの容量を地味に圧迫するので、以下の手順で使用しないように設定します。
- nmcliコマンドでネットワークの設定の状況を確認します。
$ sudo nmcli c s
NAME UUID TYPE DEVICE
ens3 5902813f-bc40-47a8-957e-2b7cfa698f08 ethernet ens3
tun0 16959581-64cb-4da5-9303-11558a750962 tun tun0
ens4 a7f50301-52aa-4957-b948-ac4187c8f8ae ethernet ens4
有線接続 1 7aa49072-00a8-34d1-b168-37e70fa2eff3 ethernet −− - 以下のコマンドを実行し、ens5を用いた接続を削除します。
$ sudo nmcli connection delete '有線接続 1'
接続 ‘有線接続 1’ (7aa49072-00a8-34d1-b168-37e70fa2eff3) が正常に削除されました。 - 以下のコマンドを実行し、ens5を用いた接続が復活しないように設定します。
$ sudo nmcli device set ens5 autoconnect no
デフォルトゲートウェイの設定
無線LAN及び有線LANがともに有効化されている場合にはデフォルトゲートウェイが設定されないことがあったので、以下のように設定を行います。
- デフォルトゲートウェイとしない方の/etc/sysconfig/network-scripts/ifcfg-<interface name>ファイルのDEFROUTEの設定を以下のように変更します。
DEFROUTE=no
- デフォルトゲートウェイとする方の/etc/sysconfig/network-scripts/route-<interface name>ファイルに以下の設定を追加します。
ADDRESS0=0.0.0.0
NETMASK0=0.0.0.0
GATEWAY0=<IPアドレス>
WordPress
設定ファイル用のディレクトリのownerの設定
Fedora 33の最新版へのアップデート時及びFedora 34へのアップグレード時に、/etc/wordpressディレクトリのownerがrootになってしまって、nginxから読めなくなりました。
nginxから読めなくなると、以下の画面が表示されます(ボタンを押しても何も起こりません)。
そこで、以下のコマンドを実行し、ownerをnginxに変更しました。
上記の件に加えて、この記事の「ディレクトリ等のownerの変更」に記載のディレクトリについてもownerをnginxに変更しました。
データベースの更新
WordPressで記事の編集を行おうとしたところ、データベースの更新を促す画面が表示されます(この記事参照。)ので、画面中のボタンを押してデータベースを更新します。
Wake-On-LAN
Wake-On-LAN設定が削除されてしまっていたようなので、root権限で以下のコマンドをWake-On-LANにより起動される側で実行しました。
nuc_ledモジュール
nuc_ledモジュールはこちらに書いた手直しを行ったものをインストールしました。
この記事を最初に書いた時点(2021年5月)では特に問題はないようです。
nginxのログファイルの出力先ディレクトリ[2021/07/24追加]
nginxのログファイルの出力先ディレクトリのownerがrootになってしまっていたので、root権限で以下のコマンドを実行し、nginxサーバを再起動しました。
# systemctl restart nginx
新しいスマホのアクセス関連の設定を追加しようとしてログが出力されていなかったので、気がつきました…。
まとめ
4台続けてアップグレードしましたが、どのサーバでもFedora 32へのアップグレードのときと比較するとアップグレードに要する時間が20-30%程度長くなっているようです。
この記事は以上です。
References / 参考文献
Fedora 34から35へのupgrade 
Fedora 37から38へのアップグレード 
Fedora 38から39へのアップグレード 
Fedora 39から40へのアップグレード 