Gentooのメンテあきらめ

もとは同じだと思うのですが,2つのGentooの仮想マシンがあります.一つは多分メインのWSとしての可能性を調べるために実マシンにインストールして,その後メインとしてもサブとしてもWSとしては使えないという判断をしたものの,いつか実マシンに復帰させる可能性を残して,仮想マシンに移行させたイメージです.

もう一つは,もともとあった古いGentooの仮想マシンをup to dateにするのは不可能と判断して,前述のWSとしての実用性をテストしている実マシンから,VMWare Fusionの仮想マシンに移行して,さらにLinuxのKVMにコンバートして,元々あった古い仮想マシンの後釜に据えたものです.

Gentooのメンテは実マシン・仮想マシンにかかわらず,基本的に週にそれぞれ数回パッケージのデータベースを配布元にシンクロして,その後updateコマンドをかけるのですが,基本はソースからbuildするのでものすごく時間がかかります.時間がかかるだけなら,放っておけばいいのですが,ときどき,なんか警告が出て,よくわからない注意書きを読まされ,設定の変更を要求されます.これがただ残しておくだけが目的の仮想マシンに行うのはめんどくさいです.たぶん,してはいけないほうの判断を時々したと思います.

そんなわけで,いろいろ重荷なのに,仮想マシンで動かしても,「動く」という以外全く意義がないので,update作業はやめることにしました.

ディスクイメージはとっておくことにしますが,まあ,将来的に使うこともないでしょう

あるいは,仮想マシンでインストールを開始して途中で実マシンに移行したかもしれないけれど,もはや思い出せません.
可能かもしれないけれどものすごい調査と手間と試行錯誤が必要.
Gentooは,update作業をさぼると,up to dateにするのが非常に困難になります.

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の入れ替え作業は完了です.

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