Gentoo VMを飼い続けるのはきびしいかも

実マシンの第2OSとしてGentooを維持するという当初のプランでは,システムをup to dateにするためには,第2OSであるGentooで起動させて,長い時間emerge (Gentooの自動buildシステム)を動かしておく必要があるので,第1OSを使いたいときに使える状況ではなくなりました.

Gentooを第1OSにしたとしても,updateで平気で一晩かかるとかあるので,システムのON/OFF/Rebootの自由度がなくなり扱いづらいです.

それと,当初期待したほど〝守備範囲〟が広くなくて,第1OSとしては厳しいんです😓

そこで,Gentoo以外の扱いやすく守備範囲の広いdistroを第1OSとして(ManjaroかDebian),Gentooをその仮想マシンとすることで,update中は第1OSの電源断やリブートはできませんが,第1OSにマシンパワーをある程度リザーブできますし,普通の作業(ってなんだ😓)は可能です.

しかし,それでも平気で何時間もかかるようなupdateはありますので(しかも,実マシンの時よりも何割か余計に時間がかかる),飼っている第1OSの自由度は制限されます.

といって,Gentooを放置すると,並みやたいていの方法では二度とup-to-dateにできなくなります😓

ということで,持て余しているというか,振り回されているのが現状です.

仮想マシンであるGentoo AMD64が,qtwebengineを激しくemergeしている様子

元実マシンのGentoo VMへそを曲げる

実マシン(第2Workstation=第2WS)の第1OSだったGentooを仮想マシン化して,新たに第1OSに就任したManjaro AMD64の元で動かして維持していこうとしましたが,先程updateのために起動しようとしたら,仮想ディスクがパーティションマップがなくなるほどの致命的な破損を受けていて,起動はおろか,インストールディスクイメージによる修復さえもできませんでした.

大幅な降格でへそを曲げたようです.気持ちはわかります😥

仕方がないので,保存してある実Gentooからクローニングしたときのイメージを上書きすることにします.また仮想化のための多少の手続きが必要になります.今度は仮想マシンとして起動した時点で,そのイメージをバックアップしておきます.

現状のまとめ(WS, サーバー)

第1WS

Mac mini Core i7 (6core 12thread) macOS Mojaveです.わが家の最強マシンです.

VMWare Fusionで飼っている仮想マシンは,

  • Windows 8.1 アマチュア無線用(Log200とN1MM+)
  • Windows 10 ライセンス維持用
  • Manjaro AMD64
  • Debian 10 AMD64
  • Ubuntu AMD64 20.04 LTS
  • 他複数

第2WS

第4世代Core i7のデスクトップ機です.

第1OS Manjaro AMD64

KVM/QEMUで飼っている仮想マシン

  • Gentoo AMD64
  • Gentoo 32bitの古い奴
  • Debian 32bit
  • 他多数

第2OS Debian 10 AMD64

KVM/QEMU, libvirt, Virt-Manager環境を整えて,第1OSと同じ仮想マシンを動かす予定です.

第3WS

Manjaro ARM64 Raspberry Pi 4 Model Bです.まだ評価中😓 KVM/QEMUで飼っている仮想マシンは,

  • Debian AMD64
  • FreeDOS

第1サーバー

仕様は非公開.

その他

その他,Macbook, 家族共用のMac mini core i7,AMD A6のデスクトップ機(使用目的なし😓)を管理しています.家族はそれぞれ複数台のWSを所持・使用しているようです.

Gentoo実マシン引退へ 〜作業完了〜

HDDに退避したRaspberry Pi 4 Model B用のManjaro ARM64は,512GBのSSDにコピーしただけで,あっさり動きました.なまじ,fstabのパーティションをUUIDなどで記述してないからです.

一方,実マシンのGentooからコピーした仮想ディスクによる仮想マシンを仕立てるのには,結構手間取りました.というか,勘違いをしてしまい,/bootのパーティションをvfatにしてしまったため,grubがKernelイメージをちゃんと設定できなかったのです./bootパーティションは,ext4ないしext3で,vfatとすべきは,EFIですね.Raspberry Piと混乱してきました😥

今のところ仮想マシンでEFIによるブートはうまくいってませんから,EFIのパーティションを切るのは無意味です.

また./bootについても,あえて別パーティションにする必要はないので最終的には,rootドライブの/bootディレクトリーにkernelなどをコピーして,grub-install; gfub-mkconfigをかけました.

一応今回のOSとSSDの入れ替え作業は完了です.

(以上すべて当社調べによります.)

Gentoo実マシン引退へ 〜途中経過〜

途中までは,なんのケアレスミスも,想定外の事態も起きず,順調すぎました.

具体的には,

  1. サブWSのサブOSであるGentoo AMD64を仮想ディスクにクローニングする(昨夜に済み)
  2. Manjaro ARM64 (RPi4)のSSD(1TB)の中身を空いているHDDにコピーする1
  3. コピーしたHDDから,Manjaro ARM64の起動を確認する(RPi4)
  4. サブWSの512GB SSDの中身を1TB SSDにコピー(メイン・サブOS用にそれぞれ約500GBパーティションを切る)
  5. HDDに待避したManjaro ARM64の内容を512GB SSDにコピーして,起動を確認
  6. 1TB SSDをなんやかんやしてManjaro AMD64(メインOS)で起動するようにする
  7. サブOSとして,仮想ディスクイメージのDebianをクローニングして,起動できるようにする
  8. 仮想化したGentoo AMD64が起動するようにする

の手順のうちの,6まではなんのトラブルもありませんでした.

しかし7で,なかなかDebianの実マシンが起動してくれませんでした.ManjaroにDebianのパーティションをマウントしてchrootして,EFIのインストールやGRUBのupdateをしましたが,再起動してEFIとGRUBでDebianを選んでもレスキュー用のshellに入ってしまいます.そこで,DebianのインストールイメージをUSBメモリーに焼いて,レスキューモードで作業しました.EFIとGRUBのインストールをいろいろ試行錯誤したり,update-initramfs の乱発です😥 そのうちなんとかエラーメッセージは出るものの,Debian自身が自力でブートするようになりました.

そういうややこしい状況下でケアレスミスもしでかして解決までの道のりが遠のきました.fstabにパーティションをUUIDで記述していますが,タブルコーテーションで始めたのに,閉じるのを忘れてました😥

どうも,Debianには,お手軽簡単のイメージがあるのですが,initramfsを使うためか,ブートの条件をいじると色々難しいようです.

Manjaraoはそのへんもシンプルにしてあるようで,警告メッセージすら出ずに,すんなりブートするようになってくれました.

あとは,仮想化したGentoo AMD64が起動するのを確認することです(8).それと,Raspberry Pi 4のManjaro ARM64がHDDから起動するのを確認したあと,まだSSDにコピーしていませんでした(5).前者は大変だけど後者は特に問題ないと思います.