横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
自分宛のメモです．
新しいKernelをbuildして，インストールしたらリブートが鉄則ですが，筆者の使う主なアプリは，KonsoleとFirefoxくらいで，これらはリブートしなくても動きますので，時間の無駄と思ってたいていリブートしないまま作業を続けてしまいます．
しかし，KVMの仮想マシンにとってはこれが具合が悪いようで，仮想マシンがフリーズしてしまいます．そして，仮想マシンだけ再起動しても起動してくれません．
ここは，セオリー通りホストの再起動をしなければなりません．
今回はさいわい仮想マシンは壊れず，再起動したホストの元で起動して，KDEにloginできました．
そう言えば，現在個人で管理している公開サーバーはRaspberry Pi 4 Model Bで動いていますが，Raspberry Pi (以下 “RPi”)にする前はIntel Core i7のデスクトップ機で動かしていました．
切り替えるときに旧サーバーのハードディスクをイメージ化して残しておきました（qcow2型式）．当初このイメージからブートできるように設定していたと思います．
まあ，他の人のなんの役に立つわけではありませんが，自分で昔に書いた文章がときどき自分で必要になることがあります．たいていは，MacのSpotlightや，RPiのサーバーでlocateコマンドを実行することで，ワークステーション内やサーバー内に探し出せることが多いですが，今回のは見つからず，The Wayback Machineを久しぶりにアクセスしてみました．
その文章に該当する記事の目次のページはあったんですが，The Wayback Machineが，PukiWikiのサイトのクロールをちゃんとできていなくて，残念ながら記事本文はサルベージできませんでした．
それで思いついたのは，Core i7のサーバーに残っている可能性です．仮想マシンを起動してみましたが，起動はしませんでした．ここで気がついたのは，仮想マシンを起動しなくても，ディスクイメージをマウントすれば，データにアクセスできるということです．
たぶん，旧サーバーのディスクイメージを仮想マシン用にとっておいたのも，仮想マシンとして動かすよりも，データのサルベージ用だったんじゃないかと，自分の過去の思いを推測しています😓
さいわいなことに，qcow2をマウントしたら，目的の文章があっさり見つかりました．
現在，メインのWSであるMac mini，唯一のノートであるMacbook，サブのWSであるSlackwareの動くデスクトップ，それぞれに仮想環境があり，それぞれにDebianがインストールしてあります．
なぜDebianかというと，Ubuntuみたいに独自性に突っ走ることのないオーソドックスなLinux distroであり，デスクトップがSlackwareと共通で気に入っているKDEであるからです．
で，何に使ってるのといわれると，特に具体的な用途はないんです😓 まあ，Slackwareに自力でGNU Radioをインストールするのに疲れたので，パッケージングソフトで簡単にGNU Radioをインストール&アップトゥデートできるということが唯一の具体的な用途かも知れません．
しかし，GNU Radioに対する関心もかなり低下して，GNU Radioで何をやるのと言われると明確に回答できません😓 逆に明確な目標・目的がないからこそ3つもの仮想マシンを維持しているわけです．
その，3つの無駄にディスク容量を食う仮想マシンのうち，一番実用性が高いと思われるSlackware下のKVMで動かしているDebianを壊してしまいました．
どのように壊してしまったかというと，よく思い出せないのです．いつもと違う古いKernelで，Slackwareを起動してしまい，その状態でディスクエラーが出る（なぜ?）のに，仮想マシンを起動してしまったような気がします．しかし，Kernelのバージョンが古いから問題だったのか，このWS自体久しぶりに起動し，ハードウェアに何か不具合が生じていた為なのか，その辺り解りません．
たしかなことは，当該の仮想マシンであるDebianを起動しても正常に起動せず，ブート時にfsckをマニュアルでかけろとメッセージが出て止まってしまうようになったことです．そのインストラクション通りにfsckをかけてから再起動したらログイン画面は出るようになったのですが，そこでパスワードを入れても，またログイン画面に戻ってしまいます．Xか何か肝心なところが壊れているのかも知れません．
どのように直そうか迷いましたが，結局，昔，「別所」のWSで動かしていたDebianの仮想マシンをコピーして済ませました．古いけど，Debian 9 (Buster)なので，update & upgradeで最新の状態にできました．
今回は，upgradeした状態のスナップショットをとっておきました．仮想マシンはバックアップをとらないので，安定した状況のスナップショットをひとつ残しておくのは重要ですね．
さて，復活したDebianで何をしますかね😓
ログの原簿であるLog200のデータにある交信レコードをup-to-dateにしているメインのデータベースであるMariaDB (MySQLコンパチブル)のデータと照合して，MariaDBに欠落しているレコードがないか，を確認するプロジェクトですが，照合スクリプトの最終形が吐き出したエラー分について手で確認をしました．
MariaDBとの照合は，日付，時刻（±5分のマージン）とコールサインで検索しました．参考の為に，モードの違いについても，検索してヒットしたレコードと原簿のレコードについて照合して，違う場合はwarningとしました．
原簿にある7万9千レコード全部について照合するのに，190分ほどかかりました．そのうちほとんどがMariaDBが占めていて，PerlのCPU占有は30秒余りです．
その結果，モードの違いまでも含めると，540ありました．検索条件が違うので(4)の293件より多くなっています．
このうちwarning扱いのモードの違いをのぞいたエラーは，128件で，手作業で照合しました．
ほとんどが，コールサインの間違いです．もらったQSLカードで修正したものがほとんどです．また，時刻の違いも何件かありました．時刻は，PCの時計データを取り込むようにしていますが，そのPCが仮想マシンのため，仮想マシンが再起動した直後に時刻データが不正確であった可能性があります（これは仮想マシンの特定のバージョンにより含まれているバグです）．可能性は低いとはいえ，自分が間違っている可能性もあり，間違っているのは自分か相手か断定できません．しかし，もらったQSLカードに返信の形で発行するQSLカードは相手の時刻に合わせた方が無難なので，ほとんどのケースで相手に合わせて修正してます．
完全な漏れは，先に判明したUR2FEO局の2交信分の他は，8N2SEA/2局との1交信のみでした．いずれも追加済です．思っていたよりうんと少ないレベルなので，安心しました．
これで，少なくとも原簿であるLog200に記録されている交信は全てメインの交信データベースにあるという状態にできました．
ただし，多くはない思いますが，原簿に漏れている交信もあるはずです．それらについてはどうしようもないです．QSLカードが届いて，該当する交信レコードがないときはこっそり追加するしかありません😓
最初のバージョンでは，日付とコールサインとモードが一致するという条件にしました．レコードが完璧に抜け落ちていたのは，2QSOのみで，それがいずれもUR2FEO局です．全くの偶然か，そのコールサインだけひっかかるような原因があるか，当時のLog200からMySQLにexportするスクリプトは残っていないので，全く探りようがありません．
この段階で，レコードの不一致があったものは，293件です．全レコード数は，7万9千件ほどなので，0.37%です．先日発表された，東京の新コロナの抗体保有者とコンパラです😓
目だったレコードの不一致は，モードの不一致です．50MHz帯の交信のSSBとCWが入れ替わっていることが多いです．周波数からモードを自動的に決める機能が，50MHzではあだとなっています．交信相手からQSLカードをもらって，気づいて修正しているところが多いです．
MariaDB(かつてはMySQL)のデータは修正しますが，オリジナルのログデータは修正しないことにしているのでこの不整合が発生します．
考えてみれば，ログソフトからMariaDBに取り込むときの漏れを問題にしているので，モードの不一致はドントケアーとします（警告だけ出すようにします）．
その代わりに，時刻を±5分のマージンで絞ることにしました．この制限を付けても，全体の処理時間はほとんど変わりません．
そんな感じで何度か試行錯誤して練ってきたほぼ最終版を今走らせています．一度走らせると3時間待たないと結果が出ないので，試行錯誤のサイクルは長いです．