Fedora 33から34へのupgrade

By | 2021年5月5日 , Last update: 2021年11月9日
0 Comment

はじめに

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コマンドでストレージ上での空き容量を確認します(以下の例は確認例です)。

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

 

ストレージ上の空き容量が十分に確保できていることが確認できたら以下のコマンドを実行し、Fedora 33を最新の状態にアップデートします。

$ sudo dnf upgrade --refresh

 

アップデートが終わったら、以下のコマンドを実行して再起動します。

$ sudo shutdown -r now

スポンサーリンク

 

Fedora 34へのアップグレード

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

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

$ sudo dnf install dnf-plugin-system-upgrade
$ 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パッケージを削除しました。

$ sudo dnf remove cockpit-docker

スポンサーリンク

 
アップグレード後に必要になった場合にはインストールをやり直す方向性です。

php-imap-7.4.16-1.fc33.x86_64

また、4台のサーバすべてでphp-imap-7.4.16-1.fc33.x86_64が原因と思われるエラーが発生しました。

とりあえず、以下のコマンドを実行し、php-imapパッケージを削除しました。

$ sudo dnf remove php-imap

 

RPMのデータベースの再作成

アップグレードを実行しようとしたところ、上記のエラーメッセージとは別に、4台中3台のサーバで、

警告: Found bdb Packages database while attempting sqlite backend: using bdb backend.

 
というメッセージが表示されました[2]。

そこで以下のコマンドを実行し、RPMのデータベースを作り直しました。

$ sudo rpmdb −−rebuilddb

スポンサーリンク

 

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

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

$ sudo dnf system-upgrade download --refresh --releasever=34

 
すると…

トランザクションの概要
================================================================================
インストール 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及びアップグレードを実行します。

$ sudo dnf system-upgrade reboot

 
アップグレードに要する時間はサーバによって異なりますが30-40分程度で、Fedora 33へのアップグレード時と比較すると少々長めでした。

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

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

[panda@pandanote.info ~]$ uname -a
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に出力されてしまい、ストレージの容量を地味に圧迫するので、以下の手順で使用しないように設定します。

  1. 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 −−

     

  2. 以下のコマンドを実行し、ens5を用いた接続を削除します。
    $ sudo nmcli connection delete '有線接続 1'
    接続 ‘有線接続 1’ (7aa49072-00a8-34d1-b168-37e70fa2eff3) が正常に削除されました。

     

  3. 以下のコマンドを実行し、ens5を用いた接続が復活しないように設定します。
    $ sudo nmcli device set ens5 autoconnect no

     

デフォルトゲートウェイの設定

無線LAN及び有線LANがともに有効化されている場合にはデフォルトゲートウェイが設定されないことがあったので、以下のように設定を行います。

  1. デフォルトゲートウェイとしない方の/etc/sysconfig/network-scripts/ifcfg-<interface name>ファイルのDEFROUTEの設定を以下のように変更します。
    DEFROUTE=no

     

  2. デフォルトゲートウェイとする方の/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に変更しました。

[panda@localhost etc]$ sudo chown nginx /etc/wordpress/

 

上記の件に加えて、この記事の「ディレクトリ等のownerの変更」に記載のディレクトリについてもownerをnginxに変更しました。

データベースの更新

WordPressで記事の編集を行おうとしたところ、データベースの更新を促す画面が表示されます(この記事参照。)ので、画面中のボタンを押してデータベースを更新します。

Wake-On-LAN

Wake-On-LAN設定が削除されてしまっていたようなので、root権限で以下のコマンドをWake-On-LANにより起動される側で実行しました。

# nmcli connection modify enp3s0 ethernet.wake-on-lan magic

 

nuc_ledモジュール

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

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

nginxのログファイルの出力先ディレクトリ[2021/07/24追加]

nginxのログファイルの出力先ディレクトリのownerがrootになってしまっていたので、root権限で以下のコマンドを実行し、nginxサーバを再起動しました。

# chown nginx:nginx /var/log/nginx
# systemctl restart nginx

 
新しいスマホのアクセス関連の設定を追加しようとしてログが出力されていなかったので、気がつきました…。

まとめ

4台続けてアップグレードしましたが、どのサーバでもFedora 32へのアップグレードのときと比較するとアップグレードに要する時間が20-30%程度長くなっているようです。

この記事は以上です。

References / 参考文献

  1. DNF System Upgrade
  2. Bug 1836108 – Unhelpful “using bdb backend” warning

Related Posts / 関連ページ

Fedora 32からFedora 33へのupgrade Fedora 34から35へのupgrade Annotation By Country プラグイン(2): wordpress.orgにプラグインを登録してみた。 本Webサイトの平成最後のFedora OSのアップデートとHTTP/2の設定とWordPressのClassic Editorのインストール。