KVM upgrade断念

だんねん残念ながら,あきらめて,backupから,元に戻しました.

最大のネックは,GNOMEが,buildの環境をlibtoolからmeson (ninja)に変更したことです(当社調べ).たとえばglibだと2.59.xと2.60.xの間でその変更があります.マイナーバージョンが1つ上がってこんなに変えて良いのかとわめきたくなります.GTK+3にも同様に境界があり,最新のソフトは,meson対応のGTK+やglibを要求し,逆に旧式のソフトは,libtool時代の.la拡張子のlibtool archiveを要求します.

で,記憶違いかも知れませんが,qemuは,依然としてlibtool archiveを要求するのに対し,virt-managerはmeson対応のGTK+を要求します.

まあ,ちゃんとメモを残したわけではないですが,そんな感じだったと思います.もうしばらく待って,世の中のdistroが,meson & ninja対応のGNOMEパッケージを使用するようなり,そういうのにupgradeしてから挑戦し直します.

それにつけても,ninjaって名前はなんとかなりませんかね.ネット検索しても「忍者」の情報ばかりかかります.スペイン語圏の人たちはninjaを「ニンハ」って読むんでしょうか

ネット検索すると,どうもそのようです.

KVM回りのupdateに着手

結局,久しぶりに取り組んでみることにしました.しかし,なかなかたいへんです.

以前buildしたときと比較すると,

  1. 必要なライブラリーやツールが増えた
    • まあ,バージョンが進めばありがちなこと
  2. glib関係のライブラリーのバージョンが相当進んだ
    • それなのに,sbopkgでは一部のパッケージのupdateが止まっている
    • よりによって,GNOMEがlibtool archive (.la)の使用をやめたので大混乱
  3. Python2がobsoleteとなった

などの問題に遭遇しています..laがなくなったことは,訳解らずにbuildしている人間にとっては大混乱を引き起こしました.SDL2のように,すでに,.laがなくても大丈夫なライブラリーもありますが,libvirtなどは,xxx.laがない,って文句を言って止まります.今回のupdate作業では,glibは最新のものでなく,2.58.xを使用することにしました.

virt-mangerのbuildまでいきましたが,起動すると,”gi”というモジュールがないといって止まります.明日以降取り組むことにします.

追記(2020/10/14)

giの件は,大きな問題ではなく,

pip3 install pygobject

で解決しました.が,それだけの問題ではなかったです.

KVMが不安定

Slackware 14.2 (AMD64)ベースのサブWSですが,どうも最近KVMで動かしているdebianが不安定です.以前,再起動できないまで壊れてしまいましたが,そこまでひどいトラブルはないものの,よく固まります.仮想マシンなので,強制リセットすれば再起動しますが,ちょっと安心して使えない頻度で固まります.

原因は,KVM環境のライブラリーなどをupdateしないまま,Kernalだけ最新のものにupdateしているせいだと思います.あるいは,Linuxにありがちですが,新しいKernelにバグが含まれているのかも知れません.

たいていのソフトは,Kernelを更新しても影響はないのですが,KVM(Kernel-based Virtual Machines)は,その名の通りKernelに直結して動くので,影響が少なからずあるのでしょう.知らんけど😓

しかし,現実問題としてSlackwareで,自分でインストールしたKVM環境全てをup to dateにするのは,もはや気力がありません😓

そこで考えたのは,サブWSのメインOSをdebianにしてしまおうということです.debianにKVMをインストールすれば,ライブラリーなど関係のパッケージも最新に保たれるはずです.

仮想マシンのディスクイメージは独立したパーティションに置いているので,移行もそんなにめんどうではないと思います.

長年愛用してきたSlackwareをLinuxのメインWS(全体としてはサブWSだけど😓)のサブOSにしてしまうのは,ちょっと悲しい気もします.そして,debianの実マシンでdebianの仮想マシンを動かす意味があるのか😓 いや,そもそも,たまにしか電源を入れないサブWSで仮想マシンを動かす意義は?

まあ,考えてみれば,動かすことができる環境を維持していることのみが意義です.

そう考えると,時間をかけてもSlackwareのKVM環境を手作業でup to dateにするべきなのかもしれません.

「手作業」といっても,sbopkgに頼る部分がかなりあります.

Kernelを更新したらすぐにリブートせよ

自分宛のメモです.

新しい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をマウントしたら,目的の文章があっさり見つかりました.