ふだんはリモートにあるPCがもう半年以上前からsshできない。同じところに別のPCがあって、そちらはリモートアクセスできているためしばらく放置していたが、本日ようやく実機にアクセスできた。
事前に電源ボタンを押しても何も反応しない、ということを近くにいる人に確認してもらっており、おそらくは電源が壊れていると判断して新しい電源を手配してもらっていたので、交換。
するとあっけなく復活。
Ubuntuが起動していることを確認して、後はリモートでの作業を行っているのだけれど、リモートだと本当はriskyなOSのアップグレードを現在行っている。
これまでの経験から、えてして途中でエラーが発生→セッション切れる→手出しできずアウトになる、ということが起こるのだ。
しかし、最近のUbuntuはdo-release-upgradeが比較的エラー耐性をもっているように感じていることもあり、強行。
最悪ダメでも上記で書いたように代替の手段はあるし。
で、案の定、アップグレードの最後の方でopenmpiとかlibboost関係のパッケージがアップグレードできない、というエラーが出て、正確なメッセージは書き残していないのだけれど、再度アップグレードを試みるか、ここで終わるか選べ、と出てきた。
さて、これがどういう状態か正確には分からない。
上記のモジュールがアップグレードできないだけであればおそらくさほど問題ないのだろうけれど、これを含めたアップグレード全体が中途半端になっているのだとすれば恐らく中断して再起動してもOSが正常に起動しないのではないか、と。
なので、なんどか再度アップグレードを試みたが、やはり同じエラーが出る。
そこで、えいやっと中断し、再起動をかけてみた。
PCの起動にそこそこ時間がかかるので他の作業をしつつ頃合いを見てsshすると、なんとか無事に入れた。
byobuを起動するとUbuntuのバージョンも上がっていることが確認できた。ということはOS全体としてはアップグレードが成功した模様。
ここで、aptを使ってupdateとかupgradeを行うと、やはりさきほどと同じopenmpiとかlibboostが依存関係がおかしくなっておりできません、と。
しかし、よく考えてみるとこのあたりのライブラリをaptで入れたはずがない。なぜならlibboostを使うソフトが非常にバージョン依存性が高く、aptではコントロールできないから。
おそらくはsourceからbuild、installしたはずで、であれば再度同じ事をしてみよう。
さて、結果...
libboostはUbuntuが文句を言っていた1.74をインストールしたところ、その部分は文句を言わなくなった。
しかし、openmpiにかかわるエラーがまだ出るので、最新のstable versionをインストールしたものの、それでもやはりエラーが。
openmpi-bin (4.1.2-2ubuntu1) を設定しています ...
update-alternatives: エラー: /var/lib/dpkg/alternatives/mpi は壊れています: スレーブリンクがメインリンク /usr/bin/mpicc と同一です
ここでネットで検索すると、とりあえずalternativeを削除して再インストールせよ、と。
sudo rm -f /etc/aternatives/mpi* /var/lib/dpkg/alternatives/mpi*
sudo apt -y install openmpi-bin
これはエラーなく終わり、しかも以後apt updateやupgradeも文句が出ない。
どうやらこれで無事にアップグレードが完了したようだ。