Debian 11.0 bullseyeが24日にリリースされていたことに気づき、メインPCのDebian buster 10.10をbullseye 11.0にアップグレード、何事もなく、あっさり、完了。
となるとラズパイもとRaspberry Pi OSダウンロードページを見ると[Release date: May 7th 2021]と前回Raspbianの方が早かっただけに、わかりにくく、/etc/source.listのURLを確認すると昨日(2021/08/27)付でbullseyeがあったので、ラズパイもbullseyeにアップグレードすることにしました。
使用中のRaspberry Piは3台あります。
順次アップグレードしていくつもりですが、とりあえず、滅多に使わないサブパソコンとしているラズパイからアップグレードしてみたら、途中でやらかし、見事失敗、これは、isoイメージをダウンロードしてddしましたが、busterだったので即、bullseyeにアップグレード。
結果、3台とも全く同一の状況で、それを知った後の2台め、3台めは、相応の時間はかかりましたし、それぞれ微妙な事後処理はあったものの、アップグレード自体は無事完了しました。
ちなみにDebianについては、PCだけでなく、LiveUSBもあり、これもアップグレード予定。
armhf用の第4章 Debian 10 (buster) からのアップグレードを参照しつつ、作業。
PC用と同様に、いきなり、apt update && apt full-upgradeしてみましたが、パッケージの衝突があり、アップグレードがエラー終了し、だいぶハマりました。
改めてドキュメントを見直してみると4.5.2. 予期されるパッケージの削除、4.5.3. 衝突 (Conflicts) あるいは事前依存 (Pre-Depends) のループや4.5.4. ファイルの衝突などの対処が必要だった模様。
[2021/08/30]
と思ったら、エラーは、まさにhttps://qiita.com/mt08/items/56a1ef23b2c768e46dcdの環境にあるlibc6-dev絡みのこれ、gcc-8-baseをインストールすればよかったっぽい...。
が、リンク先の場合、数日の間にイメージの更新があり、回避されたのか、後述のように自身は問題なかったRaspberry Pi OS Lite Busterをインストール後、bullseyeへのアップグレード時に同警告に遭遇していることと「apt install gcc-8-baseをすると先へはすすめる」という含みのある言い回しは、とりあえず感が漂い、少し気にはなりますが。
自身は、ここで間違いを犯してしまい、apt --fix-broken installやapt autoremoveしても対象パッケージが1つとか限られ、4.8. 利用されなくなったパッケージに沿ってaptitudeをインストール、search、purgeしてみたら、必要なパッケージまで含め、大量に、ホントに大量にpurgeされてしまった結果、GUIメニューからほとんどのアプリが消える事態に。
そこで、まず、4.4.4. システムの最小アップグレードしてみると数件応答の必要はありますが、パッケージが少ないために、あっさり完了。
恐る恐るマシンを再起動してみると...起動しない...!!
電源を入れ直しても当然!?...起動しない...!!
ディスクというのも変ですが、ブートもですが、システムはSSDに入っているのでSSDをPCにつないでチェック。
ブートパーティションもシステムパーティションも自動でマウントされ、中身も見えます。
そこでGpartedでシステムパーティションを修復(ディスクを選択、パーティションをアンマウント後、選択、右クリックで[チェック(H)])してみることに。
必要だったか定かではないものの、ブートフラグも立っていなかったので同様に[フラグを編集(A)]で[boot]を選択。
fsckもしてみましたが、駄目。
そこで諦めてRaspberry Pi OSダウンロードページからRaspberry Pi OS Lite(2021/05/07リリース 圧縮ファイル444MB)をダウンロード、展開後1.9GBのOSイメージをddすることに。
SDカードだけでなく、USBハードディスクやSSDでもいけそうな情報もあったのでRaspberry Pi OS Imagerを試してみようと思いましたが、そもそもダウンロードしたUbuntu用の.debの扱い方がわからず、ddで。
blkidしてみるとcmdline.txtの内容に齟齬はなかったのでHDMI絡みで以前、使っていてRaspbianが入っていたUSBメモリのconfig.txt内容を反映させ、ラズパイにつなぐとあっさり起動しました。
自身の各種Raspbianアップグレードページやラズパイ入手したらまずやることを参照しつつ、イチから環境を作っていくことにします。
尚、useradd -m userでホームディレクトリが作られなかったり、初期状態でも、visudoでsudoersファイルを編集、sudoグループ全員に権限を委譲する設定にしても、再起動してみても先に作ったアカウントuserでsudoが使えず、sudoersファイルでuserを許可する必要があったことは意外でした。
また、SSHも有効にしていない素のRaspberry Pi OS Liteからのアップグレードだったのでsshを自動起動すべく、raspi-configでSSHを有効にする必要があることに気づくのに若干時間がかかりました。
これらと併せてwifi接続する場合は、raspi-configで各種関連設定を行うとともに/etc/wpa_supplicant/wpa_supplicant.confを適宜編集、wpa_supplicant -B -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.confが必要。
ホスト名も変更、新たなユーザーuserの環境を整え、piを利用不可にした後、バージョンを確認するとbusterのバージョン10系でした。
さすがに公式イメージそのままなのでアップグレード上の不具合はないはず...。
ということでbusterでアップデート及びアップグレード後、ソースリストを適宜、busterからbullseyeに変更。
その後、bullseyeでアップデート及びフルアップグレード。
バージョンを確認すると11.0になっているのでbullseyeへのアップグレード成功です。
アップグレードは、あっという間に終わった印象。
ちなみにRaspberry Piの公式ドキュメントで「apt full-upgradeは同一バージョン内、dist-upgradeは、バージョンをまたいだアップグレード」という間違いと思われる記述を見かけましたが、前者はaptの、後者はapt-getのコマンドのはずなので注意が必要です。
再起動して環境構築...。
残る2台は、気が向いたときに試してみようかと...その際は、ここに追記予定です。
ラズパイで2度めとなるbusterからbullseyeへのアップグレードは、同じく3B+でスマートスピーカー用として使っているもの。
1台め同様の警告に遭遇・対処したことでスムースにアップグレード完了。
ただ、gcc-8-baseのインストールも、途中、応答を求められるところで2回ほど、しばし気づかなかったこともありますが、その後のfull-upgradeもかなり時間を要し、数時間かかりましたが。
尚、アップグレード後に外付けUSBスピーカーから音が出なくなり、特にスマートスピーカー用だけに対応が不可避なスピーカーを出力機器として設定する必要がありました。
この現象、パソコンに入れたDebianでは起きたことがないのでRaspberry Pi OS/Raspbian固有のもののようです。
ラズパイで3度め、2Bとしては初となるbusterからbullseyeへのアップグレードは、各種サーバー及びメーラー等々の共用などとして使っているもの。
ラズパイ 2Bとしては初めてだったため、改めて書きましたが、アップグレードに関しては、やったことは、2台めと全く一緒です。
1台め同様の警告に遭遇・対処したあと改めてapt update && apt upgrade、やはり、相応の時間はかかり、眠くなってきたので明日まで放置...。
それにしてもモデル(スペック)の違いからくるのか、USBメモリの差なのか、ラズパイの内、2Bは唯一有線LAN、アップグレード対象のパッケージ数も確か2Bは半数程度、にも関わらず、2台めにアップグレードした3B+以上に、かなり、相当、ものすごく時間を要した気がしますが、気のせいでしょうか...?(今度から時間計ろう...。)
起床して確認してみると、avahi-daemon.confファイルを更新するか否かで止まっていたので応答して継続、しばらくして無事アップグレード完了。
再起動...。
ん?ラズパイ2B、SSH接続できない...!?pingも通らない!?
あ、mDNSか...、固定してあるIPではSSHできるもmDNS.localではpingもsshも通らない...、アップグレード時、avahi-daemon.confは、現状のものを残す指定したけどな...。
systemctl status avahi-daemonしてみると[No service file found in /etc/avahi/services]なる目を引くメッセージが出るもPCのDebianも含め、そのディレクトリにファイルはない。
そこでsystemctl restart avahi-daemonしてからsystemctl status avahi-daemonしてみると先のメッセージはなく、正常になったように見える。
が、mDNS.localや固定IPでavahi-resolveしてもタイムアウトになってしまうし、PCからssh mDNS.localしても相変わらず[ssh: Could not resolve hostname mDNS.local: Name or service not known]で通らない...。
IP固定が幸いしてsshログインはできるのの、mDNS.localを当てにしているサービスはいくつかあるわけで、さて、どうしたものか?
/etc/avahi/hostsファイルを見るとIPとmDNS.localを明示的に関連付けさせられるようなので仕方なく?メインPCの当該ファイルを編集、保存後、ssh mDNS.localしてみると、拍子抜けするほど、あっさりsshできました。
同じくヘッドレスのスマートスピーカー用ラズパイ3B+では、この現象は起きませんでしたが、固定IPかdhcp任せかの違い?
ちょっとした、もやもやは残りますが、まぁ、よしとしておくことにします。