バックアップから， 仮想ディスクを仕立てて，仮想マンシを起動するまでの手順をほぼ習熟しました．KVM/QEMUでもVMWare Fusionでもほとんど手順を間違えずに，あるいは間違えたとしてもすぐ修正して，仮想マシンが動きました．
一応これは実用的な訓練でしたが，あとは実用的な利用目的は考えつかないので，そろそろ箱庭遊びは切り上げます．
さて，次は何をしようかな😥
Category: Manjaro
箱庭遊び14: ようやく1勝
今日は都合によりいつも仮想マシン遊びをする第2 WS(workstation)でなくて，第3 WSの位置づけであるMacbookのVMWare Fusion 13 Player（以下 “VMWare”）で戦いの続きをすることにしました．
まずはVMWareで新規のマシンOther Linux Kernel 5.x (64bit)を作りました．インストール用DVD イメージはSlackware64 15.0のものを使いました．仮想ディスクは分割しない40GBです．
DVDイメージからブートして，仮想ディスクをfdiskで1つのパーティションのみのDOSパーティション(MBR)にしました．そして普通に，
mkfs.ext4 -j /dev/sda1
としてformatしました．
ここでいったん仮想マシンを終了させて，同じVMWareで動いているまともなLinuxの仮想マシンに，先程作った仮想ディスクを接続（元からは削除）してrsyncを使ってバックアップの内容をコピーしました．バックアップには/sys /proc /tmp /devがありませんからこれらを手で作ったり，/devに関してはコピーしました．
コピーが完了したら，もう一度その仮想ディスクを先程の仮想マシンに戻して，引き続きSlackware64 15.0のDVDイメージから起動して，いよいよchrootです．
今回は昨日の反省を踏まえて，ちゃんと手作業で準備をしてからchrootしました．これで，
grub-install /dev/sda grub-mkconfig -o /boot/grub/grub.cfg
として，今度は祈りながら仮想ディスクイメージからブートさせることで，ようやくディスクイメージからのブートに成功しました．
ネットワークの設定方法をすっかり忘れてしまっていましたが，実用マシンはスタティックなIPアドレスを使っていますが，そのままでは仮想環境から外に繋がらないので，/etc/network/interfacesをちょこっと編集しました．
これで外につながるようになったので，
apt update apt upgrade apt autoclean apt autoremove ここでリブートできればする 再度ログインして/etc/apt/sources.listのbullseyeをbookwormに書き換える apt update apt upgrade apt dist-upgrade apt autoclean apt autoremove
以上で無事にBookwormになりました．このVMareの仮想ディスクvmdkをqemu-imgでqcow2にコンバートすれば何もいじらずにKVM/QEMU環境で起動すると思いますが，練習を積むことも重要な目的なのでKVM/QEMU環境では仮想ディスクの作成からもう一度やってみます．
たぶんGPTにする場合，BIOS boot用のパーティションが別に必要になると思います．
今回はManjaro AMD64．
箱庭遊び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にするオプションがあるはずですが，今のところ発見できていません😓
箱庭遊び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と思います（後で確認します）．
正確には違うと思います😓