Debian 10.0 Busterを11.0 bullseyeにアップグレード

Debian 10.0 Busterを11.0 bullseyeにアップグレード

　8/24にDebian 11.0 bullseyeがリリースされていたのでBuster 10からアップグレードすることにしました(amd64版)。

アップグレード対象端末

　今回は、あまり深く考えずに、いきなり、メインとしているこのPCのDebianをアップグレードしました。

　ちなみにメインマシンであるTOSHIBA dynabook B45は、使う機会もないけど極小サイズゆえ邪魔にもならないFreeDOSとのマルチブート状態。

　Raspberry Pi OS含め、他に対象は4つあり、順次アップグレード予定。

• サーバ及びメールクライアント共有としているRaspberry Pi 2B/Raspberry Pi OS(Raspbian Buster)
• サブのデスクトップPC用Raspberry Pi 3B+/Raspberry Pi OS(Raspbian Buster)
• スマートスピーカー用Raspberry Pi 3B+/Raspberry Pi OS(Raspbian Buster)
• LiveUSBのDebian Buster

メインマシンからアップグレードを実行

　第4章 Debian 10 (buster) からのアップグレードやDebian 11 -- Release Notesを参照しながら、そこにある方法のうち、findコマンドによるものとdpkg --auditをチェックして何も出力がないこと、相応のlinux-imageが存在することを確認、特に問題ないと判断し、最小アップグレードから試し、フルアップグレードすることが推奨されてはいますが、結果的にapt update及びapt full-upgradeしました。

　timeコマンドも使いませんでしたし、途中、3つ4つ質問に応答する必要があり、気づかず放置していたりしたのでアップグレードの所要時間は、不明。

bullseysアップグレード後の感想

　起動に若干時間がかかるようになった気もしつつ、GUIがなめらかにフェードインしてみたり、アイコンに少し変化があったりするものの、さらっと使ってみた限り、大きな変化は認められず、以前の通り良好です。

　ただ、あらゆるデスクトップ環境を入れているからか、入力メソッドが複数入り、fcitxからibusに設定が変わったようで当初、そのままでは日本語入力が効かず、fcitxに変更する必要がありました。

　が、アップグレード後も何事もなかった再起動、この後に再起動してみると起動しない状態となり、ブートメニューからrecovery modeで起動、パスワード入力でrootログイン、試しにapt update && apt upgrade && apt autoremove && apt clean && apt autocleanしてみると、なぜか、bullseyeへのアップグレードがなされていないかの如く大量のアプリがアップグレードされました。

　そのまま、exitすると普通に起動し、GUIのログイン画面まで到達、ログイン後も十分サクサク。

　あと特に実害はなさ気もブート時にfirmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)といったメッセージやCannot enable port 3. Maybe the USB cable is bad?については数行繰り返され、多少起動時間をとられる事象がありますが、アップグレード後に起動が遅くなった気がしたのは、これだったようです。

　とは言え、起動に失敗するわけではなく、少し待つと、そのまま起動し、無線LANもUSB機器も今のところ、支障なく使えています。

　その後、再起動した際に、なぜか起動せず、レスキューモードとなり、パスワード入力でrootログイン、いくつか操作してみた結果、ifconfigしてみるとネットワークにつながっていない...まさかと思い、ONU(+ルータ)をリセット、PCも電源を落としてから改めてやってみたところ、起動できました。

　まさかのまさか、ONU(+ルータ)って、間が悪いにもほどがある...。

　メインPCは、ほぼ無線を使わないので気づきませんでしたが、起動後、ネットワークパネル上に無線LANがなく、有線LANのみであることに気づきました...。

　改めて調べるとMicrocodeの既知のバグがあるとのことでintel-microcode for Debianの後ろの方に[RECOVERY PROCEDURE:]という修復方法があり、試してみることに。

　ブートメニューからGRUB2の設定(ブート行を選択後、[e])を行ない、linux行の最後尾に[dis_ucode_ldr]を追記(英語キーボードになるので[_]は[Shift]+[-])し、起動するとレスキューモードになったのでrootパスワードを入力し、ログイン。

　が、いざ、intel-microcodeパッケージを探すとシステム内にインストールされていないことが判明、とりあえず、当該パッケージを削除できなかった場合の[update-initramfs -u]を実行後、exitで起動させようと思ったら起動しないので電源を落として改めて起動。

　起動はしましたが、無線LANが復活しているわけではない上、なんか画面のチラツキが...、考えれば当然ですが、先のブートメニュー編集は一時的なもの、電源を入れ直した時点で従前のメニューで起動していることから、再度、端末からroot権限で[update-initramfs -u]後、再起動。

　すると、あら、不思議、ネットワークパネルに無線LANが復活していました、更に再起動してみましたが、やはり、表示されており、接続もできました。

　この手順で2度[update-initramfs -u]したことが功を奏した？

　相変わらず、ブート中にmicrocodeを最新に更新してねっぽいメッセージは、表示されますし、そう言えば、前から表示されていたような気もしますが、とりあえず無線が復活したのでよしとします。

　また、ブート中に表示されるiwlwifi firmware: failed to load iwl-debug-yoyo.bin (-2)については、Debian Bug report logs - #966218の最後にある通り、なかったので新規作成しましたが、/etc/modprobe.d/iwlwifi.confに[options iwlwifi enable_ini=N]行を追加したら、確かにブート画面から消え、無線接続にも影響なく、解決。

　Maybe the USB cable is bad?については、UUIDから、保存用の2TB HDDのことのようで、これが反応した時点で、ブートが継続して、そのまま起動するも、このHDDそもそも認識されるまでに若干ながらタイムラグはありつつも、以前はこうしたメッセージは表示されなかった気がしますが、大勢に影響ないので、まぁいいかと。

　画面のチラツキは、当初は、ノイズが入ったような画面左隅の一部の歪みが常時、現在は、画面左から画面の3/4近くまで真っ黒になったり、戻ったりのチラツキが稀に起き、モニタ上の任意の場所でマウスクリックしたり、開いているブラウザの？任意の？画面を最大化したり、元に戻したりすると何事もなかったかのように落ち着くという状況になっています。

　このように邪魔くささはあるものの、なんとかチラツキを抑えることはできるので放置。

　[Cannot enable port 3. Maybe the USB cable is bad?]は、bullseyeへのアップグレードとは関係なかったようです。

　/etc/fstabに書かなくとも、最初からだったか、いつの日からかだったか、/media/$USER/パーティションラベルで自動マウントされるようになった外付けHDDに対するものではありました。

　が、何かの拍子にファイルマネージャ上には、/media/$USER/パーティションラベルとありつつ、実態は、/media/$USER/パーティションラベル1でファイルマネージャ上では、前者をクリックすると後者にアクセスできる一方、端末からだと後者はもちろん、前者も各マウントポイントは存在するもシンボリックリンクになっているわけでもなく、前者の中身は空、後者はマウントされた状態に。

　/media/$USER/パーティションラベルを前提に設定してあったスクリプトなどもあったのでよく考えることなく、つい先日、これをfstabに書いて強制的にオートマウントさせることにしたことに起因していたようで結果的に後述のように対処、/etc/fstabの当該行を削除したところ、解消しました。

　ふと、これら/media/$USER/内の当該マウントポイントを一度全てアンマウントして/media/$USER/パーティションラベルのディレクトリをrmdirしてしまえば良いのではないかと、/etc/fstabの/media/$USER/パーティションラベルへの強制マウント行の削除と併せ、やってみたところ、再起動してみたら、元通り、/media/$USER/パーティションラベルでマウントされるようになり、正解でした。

　何らかの事情でマウントポイントとして/media/$USER/パーティションラベルが既にあったから、これではなく、/media/$USER/パーティションラベル1という新たなマウントポイントでマウントされていたってことですね。

　そもそも、この事象に気づいたのは、インストールせず、ダウンロード、展開した状態で、この外付けHDDに複数バージョン保存してあり、ファイルマネージャからでも端末からでも従前は起動していたArduino IDEやProcessing IDEが起動しなかったことからでした。

　しかも、スケッチを書こうと思ったわけではなく、たまたま別件でスケッチを見てみようと思い、なんの気なしにファイラーではなく、Arduino IDEで確認したことで発覚。

　この際、端末から試してみると共有ライブラリやJava関連の警告メッセージなども表示され、試しにProcessingを確認してみたら、やはり、起動しなかったのでJava方面やIDEを扱うにあたり必要なグループがあったのか？、はたまた、セキュリティ面等々から外付けHDDとかから起動できないような流れにでもなったのか？などあらぬ方向を彷徨い、遠回りすることに。

　ちなみに端末でIDEをシェルスクリプトから起動する際、ファイル名や./ファイル名だと[許可がない]、sh ファイル名やbash ファイル名だとArduinoは、[liblistSerialsj.soを読み込めない]、Processingは、[PATH/TO/java/lib/ext is not supported. Use -classpath instead.]とか、[Could not create the Java Virtual Machine.]とか表示され起動できませんでした。

　加えて、インストールしない状態で使うこれらIDEの起動は、展開した時に含まれているシェルスクリプトで行ないますが、テスト用に作ってみた超簡易スクリプトは、端末でもファイル名や./ファイル名では実行できないものの、sh ファイル名やbash ファイル名なら実行できた一方で、これらIDEは、何れも起動できなかったことでPATHを含む環境変数にも目が行ってしまうもマウントポイントに起因する部分を変更しても何も変わらず、更に少し遠回り。

　つまり、シェルスクリプトの中に書かれているソースに起因していたってことなんでしょうね。

　結果、ブート時に[Cannot enable port 3. Maybe the USB cable is bad?]が表示されることもなくなり、ブート時間も短縮できるようにはなったものの、一連のマウントポイント問題が、なぜ、こういう事態を招いたのか、具体的には、よくわからずじまいですが、ま、いっか。

関連リンク