Category: Manjaro

UTMでManjaro ARM

何とか動かしたいと思い，普通のアプローチではうまくいかないのでネット検索したら手順を詳細に紹介されている記事を見つけました．

この記事の表題にあるように，普通にManjaro ARMのGeneric-EFIイメージを使ってUTMで起動させると，初回の設定モードは動くのですが，設定を終えてリブートすると起動してくれないのです1．

最新のUTM2と最新のManjaro ARM Genericのイメージファイルで上記記事のとおりに手順を踏むと3，初回の設定ができて，リブートもできます．またLinux (Kernel)とLinux-api-headersをupdateから除外してupdateもかけられますが，筆者の場合そこでエラーが出てしまいました．

仮にこれでうまく動くようになってもKernelのupdateが通常のお手軽な手順ではできないのが残念です．

ということで，こちらでは投了です．

Apple SiliconのMac上でUTMを使ってKDE Plasma Desktopを動かしたいのであればDebian ARM64が一番いいと思います．

いちおう記念撮影．

たぶん，もう少しいじって消します．箱庭遊びなんで😓

  1. 筆者のケースではフリーズではなく，EFIのshellが起動する． ↩︎
  2. 4.7.5 ↩︎
  3. UTMの設定が一部前後します． ↩︎

Orphan

以前経験したのに忘れてしまっていました．

サーバーをSlackware ARM 15.0からRaspberry Pi OS 13.3に切り替え，古いサーバーのデータなどを整理していたら，総容量が200GB程度まで減りました．

今まで1TBのSSDをつないでいましたが，半端な容量で使い道のない250GBのSSDがありこれに引っ越すことにしました．1TB SSDも空きます．

作業はManjaro AMD64 (x86_64)で行います．fdiskでGPTのパーティションを切り，mkfsでブート用のvfatとルートのext4をフォーマットします．

これが落とし穴で，Manjaroでフォーマットしたext4はSlackware 15.0では認識されないのです．

2回，コピーしてブートしてくれないので，インターフェースが悪いのかSSD自体が悪いのかなど悩みましたが，ManjaroでフォーマットしたボリュームはSlackwareでは読めないことを思い出しました．

このBLOGにもそれに関する記事があるはずですが今回見つけられませんでした😓

Geminiに聞いてみたら，古いKernelでは最新のmkfs.ext4のデフォルトでフォーマットしたボリュームはtoo newでマウントできないんだそうです．

回避策としては，

mkfs.ext4 -O ^orphan_file,^metadata_csum_seed /dev/sdXN

とします．あるいはSlackware上でフォーマットすればよいのです．

しかし，このような後方互換性のない新機能というのもちょっと困ったもんです．名前をext5にしてくれていればまだ分かりやすいものを．

Raspberry Pi5をサーバーに仕立てる (1)

そういう訳で，Raspberry Pi5 (RPi5)をサーバーに仕立て，WordPressを立ち上げて現在の内容を全部か一部コピーする，ということにしました．

Rapspberry Pi 5を購入したのはもう2年前になります．以来評価ということで，SDカードベースや，SSDベースでいくつかのOSを動かしてきました．一番最近の状態は，

  1. Raspberry Pi OS (RPi OS) + PIXEL （デフォルトのGUI）
  2. RPi OS + KDE
  3. Slackware-current (aarch64) + KDE
  4. Manjaro ARM64 + KDE

で，全てaarch64(ARM64)版です．結局UbuntuのデフォルトのGUIのようなのは使いたくない😓 ので，KDEに落ち着きました1SDカードで動かした1だけ例外でした．．Slackwareについては正式リリースでないので高い評価はつかなくても仕方ないと思いますが，まあ，いかにもSlackwareだなという感じでした．

安定性と日本語WSとして使えそうという点では4のManjaro ARM64が一番です．

2のRPi OS + KDEはほとんどDebian (+KDE)で悪くはないです．KVM/QEMU環境も簡単に実現できるので，そこでDebian ARMやDebian x86_64を動かしていました2ただしDebian x86_64のエミュレーション動作は全く実用的な速度ではありませんでした．．実験的にいろいろやるには一番いいと思います．

総合的には，Raspberry Pi 4 Model B (RPi4)よりは体感速度は明らかに上ですが，日本語WSとして使用する上で十分なスピードや安定性とは言えないと思います．

これまで，RPi4で構築・運営してきたサーバーは，遅くてどうしようもないということはありませんでしたから，それをRPi5に置き換えることで当分の間は十分使えると思います．

Raspberry Pi財団のオリジナルケースに入ったRaspberry Pi 5 (RAM 8GB)

RPi5にはPironman 5を用意してからと考えていましたが，RPi財団のオリジナルケースのままで行きます．SSDもNVMeにしたかったですが，それは先の楽しみにして当分は現有のUSB接続のSSDで行きます．つまり，今の段階での投資はなしです．

これまで512GBのSSDにパーティションを切って3OSの評価に使ってきましたが，全部消して，RPi OSをインストールし直します．KVM/QEMUの仮想マシンを消すのは少し残念ではありますが．

Manjaroがへそを曲げる

ここのところ，メインworkstation (WS) であるM4 Mac miniのプチフリーズの原因究明に時間を取られ，サブWSであるx86_64マシンはほとんど電源を入れませんでした．

久しぶりにManjaro AMD64を起動したら146個のupdateがあり，早速施したのはいいのですが，日本語入力ができなくなりました😅 しばらく見限っていたのでへそを曲げられました．

今の時代，日本語が入力できないとなんの役にも立たないですね．

さて，どうしたものか．少し前の状態を仮想マシン化してあるので，その仮想マシンのupgradeをして，日本語入力ができるかどうか確認したいと思います．それもできないとなると困ったことになります．

バックアップディスクが不調になったのとほぼ同時にDebianがブートしなくなったのは偶然ではない

何言ってるか解らない題だと思いますが，自分宛のメモです．

現在Linux WSの第1 OSはManjaro，第2 OSはDebianです．両OSは同じ1TBのSSDのパーティションにあります（だいたい半分ずつ）．このほか仮想マシン（KVM/QEMU）のディスクイメージを保存するのに2TB SSDを，そのディスクイメージをバックアップするために3TB HDDを，ManjaroとDebian本体をバックアップするのに2TB HDDを使用してきました14基ともPCの筐体内に設置してあります．．

そのバックアップ用の2TB HDDが数日前から不調で，バックアップのためマウントしようとしても出来ません．取り出して外部のSATA用のアダプターに接続したら読み出すことが出来たので，手持ちの1TB SSD 2基に中身をコピーしました．

この不調が生じたのとほぼ同時期からDebianがブートしなくなりました．

よく考えてみると，Debianはバックアップ用のHDDの第1パーティションをEFIに使っているのです．メインOSのManjaroが自分のドライブの第1パーティションとしているのでDebianはそこを使えないためです．

もちろんManjaroのEFIから導かれたGRUBにはDebianも表示されますが，Debianが主体のEFI/GRUBがあった方が便利です2とはいえなかなか煩雑ではあります．．

このため，DebianのEFI/GRUBが置かれたバックアップ用の2TB HDDが不調になったらDebianはブートできないのです（起動時にマウントすべきEFIパーティションが見つからないため）．

2TB HDDの後任には2TB SSDを新規購入してあてがいました．今どき2TBだとSSDはHDDとほとんど値段が変わらなくて驚きました．

故障したSeagateの2TB HDDと新規購入したOricoの2TB SSD

2基の1TB SSDに待避したバックアップの中身を新規購入したSSDへコピーしましたが速いです．なんか，バックアップ用にするのはちょっともったいない気もします．