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).前者は大変だけど後者は特に問題ないと思います.

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が起動するようにする
忍耐の必要なステージ.他のことをして夢中になると,肝心なことを忘れて手順を間違える危険が大きい(当社実績による)ので,コピーの様子をぼーっと眺めているしかない.

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の存在理由そのもの.