Category: Linux

Gentoo実マシン引退へ

Gentoo AMD64の実マシンは，現在，サブWorkstation (Intel Core i7搭載の古いデスクトップ機．以下 “サブWS” )のサブOSの位置づけです．しかし，サブWSのサブOSとしてup-to-dateに保っていくには荷が重いOSです．

そこで，実マシンとしての運用はあきらめて，仮想化してサブWSのメインOS (Manjaro AMD64)で飼うことにします．

サブWSのサブOSにはお手軽簡単で守備範囲の広いDebianを仮想マシンから実マシンに復帰させます．

サブWSのSSDは現在512GBで，それをメインとサブのOSで半分ずつ使っているので，仮想ディスクの変換などをするにはかなり手狭です．

一方，サブサブWSとなった，というか，未だWSとして使えるかの実証実験レベルのステージにあるManjaro ARM64をインストールしたRaspberry Pi 4 Model B (RPi4)には，なりゆき上ですが，1TBのSSDが繋がっていて，持て余しています．

そこで，今回，サブWSの512GBとサブサブWSの1TBのSSDを入れ替えることもします．

手順としては，

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

なかなか難工事になりそうですが，頭の体操になると思います．

追記

念の為，1TB SSDからHDDにコピーしたら，そのHDDからManjaro ARM64が起動できることを確認します．手順を以下のように変更します．

  1. サブWSのサブOSであるGentoo AMD64を仮想ディスクにクローニングする（昨夜に済み）
  2. Manjaro ARM64 (RPi4)のSSD(1TB)の中身を空いているHDDにコピーする
  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が起動するようにする
忍耐の必要なステージ．他のことをして夢中になると，肝心なことを忘れて手順を間違える危険が大きい（当社実績による）ので，コピーの様子をぼーっと眺めているしかない．

Let’s Encryptのbuildエラー

筆者の管理する2つのサイトでLet’s Encryptの証明書を使用しています．証明書の有効期間は90日で，満了の30日前に更新の催促のメールが来て，忘れないうちにと更新するので，実質的には2か月ごとに更新してます．

手続きとしては，証明書の獲得・更新ツールをまずgitレポジトリーからpullして最新にして，ビルドスクリプトと思われる😥 tools/venv.pyを実行します．

どちらのサイトもSlackwareを使っているため，Pythonは2.7が最新で，3.xは，入っていません．困ったことに，この2か月間に，Python2.7のサポートが外されたようで，即エラーになりました．

sbopkgを使うことで，Python 3.7がインストールできますが，今度はtools/venv.pyの実行の途中でエラーが出ます．

どうも，cryptographyをbuildしているときにエラーが出るようです．これと同じです．

pipでcryptographyをbuildしようとしても同じ結果になります．しばらくは様子を見ることにしますが，それでは証明書が失効してしまうので，バックアップから前回のPython 2.7をサポートしていた状態に戻して，証明書の更新をしました．

追記（関連情報）

あとで，手でPython 3.9をインストールして試してみましたが，同じ結果でした．

QEMUのコマンドラインに挑戦

下記サイトなどを参考に，こんな感じで，macOSや，Manjaro AMD64で，Raspberry Pi OSのイメージを起動して，updateまでできたのですが，そのあとでブートするとネットが繋がらなくなって，悩んでいるところです．

qemu-system-aarch64  -kernel boot/kernel8.img  \
    -dtb boot/bcm2710-rpi-3-b.dtb  \
    -M raspi3 -m 1024  -serial stdio  \
    -append "rw earlycon=pl011,0x3f201000 console=ttyAMA0 loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes net.ifnames=0 rootwait memtest=1" \
    -drive file=2021-01-11-raspios-buster-armhf-full.img,format=raw,if=sd  \
    -device usb-kbd  -device usb-mouse \
    -device usb-net,netdev=net0  \
    -netdev user,id=net0,hostfwd=tcp::5555-:22 \
    -no-reboot

下準備としては，MacでもLinuxマシンでも適当なところに，フォルダーを作り，そこに，Raspberry Piのサイトからインストール用のイメージをダウンロードして，unzipします．微妙にSDイメージのサイズが2のn乗にならないので，qemu-imgでリサイズしました．そして，そのSDイメージのvfat部分をLinuxマシンにマウントして，SDイメージを展開したフォルダー内に “boot” というサブフォルダーを作ってコピーしました．

そこで，上記のqemu-system-aarch64 … を実行しました．

そうそう，libvirtやVirt-Managerとは違って，全部一般ユーザーの権限で作業できます．

Manjaro ARM64では，上記に “-accel kvm” を追加するのでいいと思うのですが，起動すらしてくれません．さらに深く悩み中です．

参考にしたサイト

コマンドラインじゃないとだめかも(QEMU)

Virt-Managerは，非常に解りやすいですが，複雑なQEMUのオプションの扱いを完全に網羅し切れているわけではないようです．

QEMU自体も，ハードウェアやOSによりいろいろ制約があるところ，それをサポートするlibvirtやVirt-Managerもそれぞれ制約があって，最終的に，Virt-Managerがカバーできる範囲が狭くなるのでしょう．

筆者自身，QEMUの複雑怪奇なオプションをいちいち調べて設定していられないよ，というのが，Virt-Mangerに頼るようになったきっかけなので，今さら，コマンドラインを打ち込みたくないのです．

しかし，Virt-Mangerだよりできた仮想マシンいじりの膠着状態を打開するには，QEMUに無数の😓オプションを指定して直接実行するしか選択肢はなさそうです．

コマンドラインでいくならば，Virt-Mangerはもとより，libvirtも不要なようなので制約条件はずいぶん緩和されると思います．Mac miniにMacPortsを再びインストールして，qemuのインストールからやり直すことにします．

libvirtやVirt-Managerの存在理由そのもの．

サブWSもManjaroに

結局，LinuxのリアルマシンであるWorkstation (WS)，あるいは，AMD64 (x86_64) WSとして2番めの使用頻度のマシンのdual boot設定のうちの第一のOSをManjaro x86_64にしました．

理由は，各種ソフト（OS，システム関係，アプリ）が最新に近いこと，ハードの能力をかなり引き出していると感じていること，QEMU/KVMをかなり守備範囲広くインストールできること，システムのインストールや，その後のupdateや追加が楽であることなどです．

簡単で，最新で，速い，といったところでしょうか．

しかし，残念ながら，x86_64下でのRaspberry Piのエミュレーションはまだうまくいっていません．

ここまでは．Arch Linuxのおかげ．
Manjaroの一番の売り．
Distroの提供するパッケージとして．
個人の感想です．
当社調べ．