箱庭遊び13: Debianの仮想マシンの復元作業で連戦連敗

今年の読売の対阪神戦のようです

少し実用に近い作業をしていますが,昨日は使える時間をすべて使って取り組んだにも関わらず全く成果が得られませんでした.

何をしているかというと,某所で実用的に動いている仮想マシンが現在Debian 11.x Bullseyeのままなので,その某所のネットワーク管理者に叱られる前にDebian 12.x Bookwormにupgradeする必要があり,その下準備です.

その某所の仮想マシンについては,「ホストの管理者権限をもっていない」という大きな制約があります.したがって作業は慎重に慎重を重ねてやっていますが,これまで動かしてきた1年ちょっとの間に数回リブートできないトラブルに見舞われました.

そのうち1度はブートの仕組みをぶっ壊してしまい,手元にあるバックアップファイルから仮想ディスクを再構築して,仮想マシンのホストの管理者(以下「大家さん」)にSDカードに書き込んだ仮想ディスクを郵送して差し替えてもらいました.

残りのブート失敗はKVM/QEMUのバグで,何回かブートするとブートの一番最初のあたりで引っかかって先に進まないものです .このトラブルの場合には,大家さんに仮想マシンの強制リスタートをかけてもらえばたいていというかこれまでのところ全部解消してきました.

それで今回の話に戻りますが,しばらくその実用的なDebianの仮想マシンはいじっていないのて勘所をすっかり忘れています.そこで,そのマシンのバックアップから仮想ディスクを作り,仮想マシンとして起動して,Debian Bookwormまでupgradeをするという手順の確認と習熟を手持ちのマシンでするという非常に生産的な作業をしています.

最初は最新状態のManjaroで空の仮想ディスクを作ってext4にformatしてnbdでマウントしてバックアップをコピーし,Debian 12.1 (Bookworm)のインストールDVDイメージからchrootしてgrubのインストールを試みましたが,何度やっても自分で起動するようになりません.ときどき “unknown filesystem” っていうエラーメッセージが出ている事に気づきました.FEATURE_C12の呪いを忘れていました.

Debian 11.xの仮想ディスクはDebian 11.xでformatして作らないとNGです

それを思い出してから作業をしていますが,Debian 11.xのインストールDVDから仮想ディスクイメージにchrootする選択をして,grub-installなりupdate-grubをするとエラーなくコマンドは通るのですが,いざ仮想ディスクイメージからブートしようとしてもgrubのrescueモードになってしまい,コマンドラインを打ち込んでもKernel Panicで止まってしまいます.

寝ながらいろいろ考えましたが,既に考え得ることは全てやり尽くしたように思います.しかし,昨年,確かにバックアップの内容から仮想ディスクを作り直し,その仮想ディスクで現在サーバーが稼働しているわけですから,できないはずはないです.

一つ可能性があるとしたら,Debianのインストール用DVDイメージのchrootで,必要なおまじないをしていないのかもしれません.

ということで,今日時間が取れたら,DVDイメージのRescue Modeから起動しても仮想とディスクへのchrootは自分でおまじないをしてからしてみる,というのを試みてみます.

これまで散々悪行を尽くしてきたのにこの成績とは,って誰か言ってました.
筆者がいじっている仮想マシンのうち唯一の実用マシンです😓
昨年トラブったときにネット検索をしていくつか事例を見つけたのですが,今回は面倒なので調べません.
筆者の経験則としては,10回に1回程度でしょうか.
当然最新のmkfsにFEATURE_C12をdisableにするオプションがあるはずですが,今のところ発見できていません😓

箱庭遊び12: EFI+GRUBがうまく行かない

うまく行かない最大の理由は,よく理解していないということなのはよくわかっています😓

箱庭遊びの範囲がそもそもの定義である「仮想マシン遊び」から,第2WSの第2OSのパーティションでの遊びまで広がってしまいました.第2OSのパーティションもほぼ制約なく書き換えたり消したりできますので,ここもなし崩し的に箱庭の範囲に含めてます.

さて,何がしたいかというと,第2WSに積んでいる3機のマスストレージの,第1OSのブート用SSDではないマスストレージにEFIのパーティションを設けて,そこから第2OSをブートさせるということです.これは今夏の箱庭遊びを始める前にはできていました.

ここ数日は,バックアップ用の2TB HDDに設けたEFIパーティションを現在第2OSにしているUbuntuの/boot/efiにマウントして,いろいろ試していますが,うまくいきません.

今日からはVMの仮想ディスク保存用のSSDでできないかやってみます.

一応この辺を参考にしています.

workstation.
rootディスク用の1TB SSD, VM(仮想マシン)仮想ディスクを保存している2TB SSD, OSバックアップ用の2TB HDD.

箱庭遊び11: Slackware 32bit版はやめとく

Slackware64は実マシンにしてAvahiのインストールやrsyncdの有効化など行いまあ使えるレベルになったので,仮想ディスクイメージにコピーして,実マシン化前のSlackware64の仮想マシンの仮想ディスクと差し替え,また仮想マシンとして稼働するようになりました.仮想マシンから実マシン,さらに仮想マシンに戻して一段落です.

そこで,前回難航したSlackware 32bit版の実マシン化を再度試みました.

しかし,今回は自前のEFI+GRUBによる稼働はおろか,前回成功したManjaroのGRUBからの起動もできていません.

なんとか動くようにトラブルを解決したいのですがやめときます.考えてみれば,Mozcが使えるというのがSlackware 32bit版の唯一の存在理由でした.しかし,MozcはSlackware64で使えるようになり,しかも日本語入力切替の方法が多く選択できるfcitx5が使える(Slackware 32bit版ではインストールに成功していません)ので,もはや全く32bit版にアドバンテージはありません

ということで,長年愛用してきたのに少し寂しい気もしますが,Slackware 32bit版で遊ぶのはこれでやめることにします

fcitx(4)の元で.
32bit版ではFirefoxがクラッシュすることがあります(当社調べ).
仮想マシンには残しておきます.

箱庭遊び10: Slackware64の実マシンブートする

紆余曲折がありましたが,Slackware64の仮想マシンを実マシンに移行した上,自前のEFI+GRUBと,ManjaroのEFI-GRUBからブートするようになりました.

今回引っかかった最大の罠は,ext4のFEATURE_C12です.

詳しく調べたわけではないですが,e2fsprogs 1.47.0では,FEATURE_C12がdefaultでONになり,mke2fs 1.47.0でformatしたパーティションを,それ以前の世代のGRUBを含むfirmwareがマウントできないようです.

Workaroundとして,SlackwareのインストールDVDイメージを焼いたUSBメモリーから起動して第2OS用パーティションをmke2fs 1.46.xによってフォーマットして,そこに第1OSであるManjaroでSlackware64の仮想マシンの仮想ディスクイメージの内容をrsyncによってコピーしました.

2つ目は,EFIの罠で,これは今まで何度も引っかかっています.Slackware64のインストール用DVDイメージを焼いたUSBメモリーから起動してハードディスクをルートにする際に,必ず “UEFI: Flash Image” から起動しないと,efibootmgrが動きませんし,efibootmgrを用いるgrub-installもエラーになります.

USBメモリーのEFIから起動するとなかなかよくできていて,メニューに従ってハードディスクのパーティションを適切に選べば,そのままハードディスクのパーティションをルートにして,Xまで立ち上がります.

ちなみに,第2WS (workstation)の第1OSと第2OSの違いは,仮想マシンのホストにするかしないかです.Debianでも比較的楽にKVM/QEMU環境は築けますが,敢えてやり直す気もしないので,当分はManjaroを第1OSにしたままにします.第2OSは仮想マシンのホストにするという条件がないので,仮想マシンと自由に入れ替えできます.

mke2fsは,最新の1.47.0と思います(後で確認します).
正確には違うと思います😓

箱庭遊び9: Slackware64 仮想マシンから実マシンへ移行

仮想マシンのSlackware64にfcitx5-mozcのインストールが成功しました.ローマ字入力しかできないなどと馬鹿な独り言を書いてしまいましたが,Mozcの設定のダイアログはコマンドラインから起動できることを思い出し,かな入力もできるようになりましたし,他のマシンで培った😓 ユーザー辞書のインポートもできました.

あとは,あきらめたSlackware 32bitの間借りしていた実マシンのパーティションに移植するだけです.コピーにはいつものように,qemu-nbdなどを使います.

Slackware 32bitのときと同じくManjaroのGRUBから起動できれば十分なので,お手軽簡単にManjaroから

update-grub

をかけてみましたが,うまくブートしてくれません.kernelモジュールがないと文句を言っているようなので,もとの仮想マシンの仮想ディスクのイメージを確認すると,KernelはSlackwareの最新パッチの5.15.117なのに,initrd.gz内のモジュールは初期の5.15.19のままです./boot/initrd-tree内に5.15.117のモジュールのツリーをコピーして,

mkinitrd

をしてみましたが,ブートしてくれません.なお,これだけの修正をするのに

仮想マシンの作業を終えて仮想マシンを止める
modprobe nbd      ← 初回のみ
qemu-nbd --connect /dev/nbd0 /仮想/マシンの/ディスクイメージ.qcow2
fdisk -l /dev/nbd0   ← ルートパーティションを確認する(初回のみ)
mount /dev/nbd0pなんとか /mnt/hd1 -oro
mount /dev/sdなんとか /mnt/hd2
rsync -artlvd /mnt/hd1/ /mnt/hd2/
場合によっては/mnt/hd2の修正作業
umount /mnt/hd1
umount /mnt/hd2
qemu-nbd --disconnect /dev/nbd0
update-grub
reboot

の作業が必要です.これでだめならまた仮想マシンのディスクの修正作業からやります.

Manjaroのgrub頼みはいったんあきらめて,chrootの手続きにより,Slackware64自身によるブートの仕組みをこしらえてみます.

第2 WS(workstation).
第2 OSの定位置.
Manjaroで,root権限です.
qemu-nbd --disconnect /dev/nbd0をしないと,Manjaroのgrubに/dev/nbd0なんとかがブート可能なパーティションとして追加されてしまいます.まあ,全部終わったら削除すればいい話かもしれませんが.