WPP
スマホをキーボード・マウスの代わりにするアプリ Remote Touchpad

数週間もするときっと忘れてしまうのでメモ。

LM22 で SIP ソフトフォンを探していると 『Remote TouchPad』 というアプリを見つけた。どうやらスマフォからの入力をマウスやキーボードに見立てて PC に渡してくれるものらしい。

対応 OSは、 Win、Linux に対応している。

インストールして起動すると、QR コードが表示され、スマホでスキャンするとブラウザ経由で PC に接続する仕組みらしい。
つまり、PC 側にしかインストールが必要ないということだ。

PC にキーボードってそもそもいらないんじゃない?って以前考えたことがあったが、それを実現するソフトだ。

動作は若干もっさりしているが、緊急で一時しのぎで使うには問題なさそうだ。

Remoto Touchpad を動かす PC で nomachine を使って更に先のどこかにつないでいる場合、nomachine で転送しているリモートの画面では日本語の入力が上手く動かない気がする。
その場合、nomachine の転送元で Remote Toouchpad を動かせばいいのかもしれないが未検証なのでわからない。

参考

Github: Unrud/remote-touchpad: Control mouse and keyboard from a smartphone

雑談: メルカリの認証ってクソすぎん?

メルカリのアプリ版をパスキー認証にしてししばらく経ちますが、昨日くらいから PC でアクセスする Web 版がログイン不可になりました。

パスワード変更すると状態がリセットするらしいが、自分の状況ではメルカリのビットコインを買っているので問い合わせ対応になるらしい。あーめんど。

でしょうがないのでいやだけど Google アカウントと連携することで PC からもログイン出来るようになった。のはいいが副作用として SMS での2段階認証が必須になった。

そもそも、SMS での 2FA を避ける為にパスキー認証にしたのに Web 版を利用すると結局 2FA にフォールバックするっていう仕様はゴミですか?

大量の候補をだらだら見るときは PC のがやっぱり見やすいんよ。なんとかならんか。

edk2 Hello その2です

前回記事で、edk2 のハローワールドを作りました。今回は、それを qemu で実行していきます。

自分が理解する限り、UEFI の仕様は FAT パーティションに /EFI/BOOT/ というフォルダを作成してそこに起動ファイルを置く必要があるようです。

準備

edk2 のOvmfPkg をビルドしておく必要があります。 build -p OvmfPkg/OVmfPkg.dsc とかでビルドできます。

ディスクイメージの準備

ディスクイメージを作っていきます。ビルドした .efi ファイルは、
edk2/Build/HelloPkg/DEBUG_CLANGDWARF/X64/HelloApp.efi
にあるものとします。

$ qemu-img create -f raw disk.img 128M
$ mkfs.fat -n 'xxos' -s 2 -f 2 -R 32 -F 32 disk.img
; -s 2: 2 セクタ /クラスタ
; -f 2: FAT を2個用意する
; -R 32: 32 セクタを FAT で使用する
; -F 32: FAT32 を使用する

; マウントポイントを作成
$ mkdir ./mnt

$ sudo mount -o loop,uid$(id -u),gid=$(id -u) disk.img ./mnt
$ mkdir ./mnt/EFI/BOOT
$ cp ./ edk2/Build/HelloPkg/DEBUG_CLANGDWARF/X64/HelloApp.efi ./mnt/EFI/BOOT
$ sudo umount ./mnt

実行は本と同じですね。

$	qemu-system-x86_64 \
		-drive if=pflash,format=raw,readonly=on,file=edk2/Build/OvmfX64/DEBUG_GCC/FV/OVMF_CODE.fd \
		-drive if=pflash,format=raw,file=edk2/Build/OvmfX64/DEBUG_GCC/FV/OVMF_VARS.fd \
		-drive format=raw,file=disk.img
		# -net none -nographic

OVMF_CODE.fd と OVMF_VARS.fd は長いので環境変数に逃したほうがいいかも。

上は
fs0:
cd EFI/BOOT
HelloApp.efi

で実行した様子

QEMU にマウスとキーボードを掴まれたときは Ctrl + Alt + G で抜けることが出来る。

確かめていないが HelloApp.efi を適切な名前にすれば自動起動するはずだと思う。

次は、カーネルを作成したいので、まずは edk2 でのファイルの読み込みをやってみよう。 Mikan 本のブートローダーはメモリマップを作成して、ちゃんと空きメモリにカーネルロードしている。

Mikan本 派生でないっぽい Uefi や edk2 のカーネルローダーをネットでみるとやっぱり何かしら空きメモリを探す処理をしているので必要だよな。じゃないと uefi の機能が全部死ぬかもしれぬので画面出力もできなくなるよね、多分。

edk2 Hello

しばらく中断していた Mikan 本関連です。5日目くらいまで本に沿ってやっていたのですがどうも馴染めないのでやり方を変えることにした。

本をみちしるべにしつつも環境構築から勝手に行い、好きに書いていくほうがわかりやすいのでは?と思いやってみることにした。

まずは edk2 Hello world から

事前準備

edk2 をインストールして予め BaseTools をビルドしておくこと。

BaseTools に build スクリプトが含まれるのでこれをしとかないとビルドができない。

ツリー構造

今回つくる HelloPkg は最終的にこういう感じで配置しています。edk2 フォルダは git clone した時にできたフォルダになります。

  • プロジェクトルート
    • edk2 フォルダ
      • Build
      • HelloPkg << 今回作るパッケージ
        • Include
        • Library
        • Main.c
        • Hello.inf
        • HelloPkg.dec
        • HelloPkg.dsc

コード

Claude に聞くと上記の各アイテムを作れと言わるので作っていきます。

$ cd edk2
$ mkdir Include Library
$ touch Main.c Hello.inf HelloPkg.dec Hello.Pkg.dsc

各ファイルはこんな感じになります。

最初は、C ソースです。

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>

EFI_STATUS
EFIAPI
UefiMain(
    IN EFI_HANDLE       ImageHandle,
    IN EFI_SYSTEM_TABLE *SystemTable
)
{
    Print(L"Hello edk2\n");
    return EFI_SUCCESS;
}

UefiMain はなんにもしていないので極めてシンプルです。

次は、 HelloPkg.dec です。
このファイルの役割はよくわかっていませんが今の所、あまり書くことはありません。

[Defines]
DEC_SPECIFICATION = 0x00010005
PACKAGE_NAME      = HelloPkg
PACKAGE_GUID      = 25d16f8a-7fb0-467d-a13d-97c83f2a84a4
PACKAGE_VERSION   = 0.1


[Includes]
Include

[Guids]

[Protocols]

[PcdsFixedAtBuild]

DEC_SPECIFICATION は edk2 の公式ドキュメントで定義されている DEC のバージョンです。
PACKAGE_GUID は uuidgen などで生成した値を指定します。

edk2 ではちょくちょく GUID を指定する場面がありますが、その都度 uuidgen などで生成してコピペしてやります。

HelloPkg.dsc です。

[Defines]
PLATFORM_NAME               = HelloPkg
PLATFORM_GUID               = 46fcca5f-7fe2-4cd7-83e4-f0b535d60410
PLATFORM_VERSION            = 0.1
DSC_SPECIFICATION           = 0x00010005
OUTPUT_DIRECTORY            = Build/HelloPkg
SUPPORTED_ARCHITECTURES     = X64
BUILD_TARGETS               = DEBUG|RELEASE|NOOPT
SKUID_IDENTIFIER            = DEFAULT

[LibraryClasses]
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
UefiLib|MdePkg/Library/UefiLib/UefiLib.inf

# dependencies
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull.inf
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf

[Components]
HelloPkg/Hello.inf

先程と異なり結構書きます。

どうやらこのファイルに記述したモジュール名を頼りにビルドの依存関係を解決していくようです。

その仕組みと source edksetup.sh を使って、Main.c で突然出てきた Uefi.h とかを参照し、リンクするってことをしているようです。

当初 [LibraryClasses] には UefiApplicationEntryPoint と UefiLibMdePkg の2行しか記述していなかったのですが、それだと edk2 の build コマンドでビルドエラーが出てきます。
例えば、 BaseLibMdePkg が見つからないよとか言ってきます。直してはビルドを繰り返していくうちにこういうふうになりました。結局 Mikan 本の[LibraryClasses] とほぼ同じ感じになったはず。

Hello.inf です

[Defines]
INF_VERSION     = 0x00010005
BASE_NAME       = HelloApp
FILE_GUID       = 2bbb1fb0-95b5-4b59-a98c-15093d771b11
MODULE_TYPE     = UEFI_APPLICATION
VERSION_STRING  = 0.1
ENTRY_POINT     = UefiMain

[Sources]
Main.c

[Packages]
MdePkg/MdePkg.dec
HelloPkg/HelloPkg.dec

[LibraryClasses]
UefiLib
UefiApplicationEntryPoint

ビルドすると BASE_NAME が引き継がれて HelloApp.efi が作成されるようです。

ビルド結果は edk2/Build/HelloPkg/DEBUG_CLANGDWARF/X64 に保存されます。

保存先のフォルダは build コマンドに引数を渡さなければ以下のようになります。

DEBUG_CLANGDWARF は、edk2/Conf のtarget.txt の TARGET= と TOOL_CHAIN_TAG= を組み合わせたものになります。GCC を使っていれば DEBUG_GCC とかになります。

X64 の部分も同じように target.txt の TARGET_ARCHI= の値が来ます。

build -t CLANGDWARF とかすると target.txt の内容を無視して指定の内容で実行されます。

長くなったので QEMU での実行は次の記事にします。

NoMachine をアップデートすると Windows に接続できない場合の対策

以前から、NoMachine をアップデートするたびに Windows PC に接続できなくなる気がしていたがなんとなくアンインストール / 再インストールなどしてお茶を濁していたがいい加減面倒になってきたので少し調べて見た。

どうやら Active Directory に参加している PC だと、ドメインのポリシーによっては必要な権限が外れるっぽい。NoMachine は Windows のユーザー認証の真面目に対応しているのでかえって面倒なことが起きてしまうようだ。

VNC みたいに独自認証を突き進む場合、Windows 側の設定には左右されないのでこういう問題はおきない。

現象

他の PC から NoMachine で接続するとユーザー認証画面が出てくるがここは認証が通る。

新しいウィンドウが表示されるが、真っ白なままで接続先の画面が転送されてこない。
(このとき、接続された Windows 側では接続してきたよと通知が出るので認証は通っている。)

数秒立つと接続が切断され、リトライを続ける。

環境

Windows 11 + Active Domain に参加しているPC

対策

ローカルグループポリシーエディタで User Rights Assignment で Act as part of operating system に nx ユーザーを追加し直す。

実は他にもあるらしい、全部まとめると

  • Act as part of operating system
  • Logon as service
  • Adjust memory quatas for a process
  • Replace a process level token

の 4つのユーザー権限が必要らしい。

手順としては、

スタートから Local Security Policy を起動する

左ツリーから Local Policies > User Rights Assignment にすすむ

右ペインの Act as part of operating system をダブルクリック

恐らく nx ユーザーが追加されているはずですが、こいつを一旦削除する。
(PC に nx ユーザが追加されていないようだと NoMachine のインストールそのものが上手くいっていない。)

Add User or Group ボタンを押して nx ユーザーを追加し直す。

これで通った。

他の設定もなにか影響している可能性も考えられるが事象を記録しておく。

追記、一晩明けた今朝、接続を試みるとまた接続できなくなってしまった。うーん原因がわからない。

参考

NoMachine Forum – First time connecting session negotiation failed error

NoMachine Forum – Active directory authentication

トラックボールの音鳴り対策 – その1:ハンドクリーム

普段自宅では、Kensington Slime Blase Pro を使っているのですが、最近ボールを転がすとキーって感じの音がして気になっていました。

このトラックボールは、ボールの側面を上下に動かすとスクロールしてくれるのですがそれをすると特に顕著に音がします。

インターネットを検索するとやはりそういう問題があるようで、対策してはシリコンスプレーや食用の油をボールに塗って動作を潤滑にするっていうのがあるようです。

で、手元にシリコンスプレーがないので買いに行くのはちょっと面倒と思っていましたが、ふと思い立ちハンドクリームをボールに塗って代替にできないか試してみました。

ハンドクリームならもともと手に塗るものだし、良さそうだと。
ちょうど自宅にある食用油は、バターかオリーブオイル以外はきらせていて、その2つだたぬるぬるがいつまでも取れないとかありそうなので、まずはハンドクリームで試してみることにした。

結果、音は鳴らなくなり、割といい感じになりました。手元にあったハンドクリームはさらっとしたタイプのテクスチャだったのでそれが良かったのかもしれない。しかし、数分前に塗ったばっかりなので効果の持続性はまだわからない。

副作用としてボールの動きが恐ろしく軽くなった。考えてみると購入時はハンドクリームを塗る前ほどボールの動きが重くなかった気がするので、最初はなにか塗布されているのだと思う。

すぐに効果が切れるようなら他の方法も試してみます。

追記:2日くらいしか持ちませんでした。

LM22.1 にアップグレード

Linux Mint 22 から 22.1 にアップグレードした。

今回は、21 から 22 のときのような TimeShift のバックアップを要求されずにすんなりとアップグレードできた。

画面は全くキャプチャ取っていないが、何も難しいことはないので問題ないだろう。

os-realease と upstream-relase/lsb-release はこうなった。

$  cat /etc/os-release 
───────┬──────────────────────────────────────────────────────────────────────────────────────────────
       │ File: /etc/os-release
───────┼──────────────────────────────────────────────────────────────────────────────────────────────
   1   │ NAME="Linux Mint"
   2   │ VERSION="22.1 (Xia)"
   3   │ ID=linuxmint
   4   │ ID_LIKE="ubuntu debian"
   5   │ PRETTY_NAME="Linux Mint 22.1"
   6   │ VERSION_ID="22.1"
   7   │ HOME_URL="https://www.linuxmint.com/"
   8   │ SUPPORT_URL="https://forums.linuxmint.com/"
   9   │ BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
  10   │ PRIVACY_POLICY_URL="https://www.linuxmint.com/"
  11   │ VERSION_CODENAME=xia
  12   │ UBUNTU_CODENAME=noble
───────┴──────────────────────────────────────────────────────────────────────────────────────────────

$ cat /etc/upstream-release/lsb-release 
───────┬──────────────────────────────────────────────────────────────────────────────────────────────
       │ File: /etc/upstream-release/lsb-release
───────┼──────────────────────────────────────────────────────────────────────────────────────────────
   1   │ DISTRIB_ID=Ubuntu
   2   │ DISTRIB_RELEASE=24.04
   3   │ DISTRIB_CODENAME=noble
   4   │ DISTRIB_DESCRIPTION="Ubuntu Noble Numbat"
───────┴──────────────────────────────────────────────────────────────────────────────────────────────
Pixel 6a を LinegeOS 22 にアップグレード

年末くらいから Pixel 6a に入れている LinegeOS 21 (Android14) にアップグレードが来なくなりました。正確には毎週のアップデート通知はくるが、メジャーアップデートなのでそのままではアップデートできません。

ちょっと時間が取れたので 22 にアップグレードしていきます。本来ならデータバックアップを取るべきですが、公式の手順にも wipe しないよって書いてあるのでそのまま行きます。基本、重要データは退避してあるはずなのでまあ OK でしょうという感じで進めます。(真似してコケて泣いてももしりません。)

流れはこんな感じ。

  1. OS の zip、 Google apps をダウンロード
  2. リブートして sideload に入る
  3. PC から sideload で OS を焼く
  4. Pixel を再起動してリカバリーに入る
  5. リカバリーの中で Advanced Option から sideload を起動する
  6. PC から sideload で Google apps を焼く
  7. Pixel 6a を再起動して LineageOS 22 を起動する

OS ダウンロード

LineageOS Downloads から lineage-22.1-20250118-nightly-bluejay-signed.zip をダウンロードしておく。

Google apps ダウンロード

Google apps | LineageOS Wiki から LineageOS 22.1 (Android15) ARM64 用のGApps をダウンロードしておく

リブートして sideload に入る、OS を焼く

予め USB ケーブルで PC と Pixel 6a をつなげ USB デバッグを有効にしておく。(もちろん ADB もインストールしておくこと)

そしたら以下を PC で実行する。(.zip と同じフォルダにいるとする)

$ adb -d reboot sideload
; 実行すると Pixal 6a が再起動する

; sideload に入ったら
$ adb -d sideload  lineage-22.1-20250118-nightly-bluejay-signed.zip 

; 終わるまえ1分くらい待つ

Pixel を再起動してリカバリーに入る

終わったら、次はリカバリーに入り直す。

Pixel の画面で Advanced を選び、 Reboot to Recovery 的なやつで Pixel を再起動します。

リカバリーの中で sideload を起動する

Pixel の LineageOS リカバリーが起動したら、Apply Update をタップする。そうすると sideload 待ちの状態になる。

PC から sideload で Google Apps を焼く

また、PC に戻り今度は Google Apps を焼く

$ adb -d sideload MindTheGapps-15.0.0-arm64-20240928_150548.zip
; 終わるまで少し待つ

Pixel 6a を再起動して LineageOS 22 を起動する

Pixel 6a の LineageOS リカバリーで Reboot system 的なやつで再起動する。
上手く行っていれば、LinegeOS 22 が起動してきます。

失敗した場合は、焼き直しやワイプ、ダウンロードファイルの大きさなんかをチェックしてやり直すといいと思います。

あっけなくアップグレードできてよかった。

LinegeOS の公式の手順は、実行するコマンドが文章中に埋め込まれているので拾いだすのが面倒なのでメモした。まあ、たいした手順じゃないから、文に埋めたい気持ちもわかる気がする。

参考

Upgrade LineageOS on bluejay | LineageOS Wiki

arm64 ROS2 環境を podman で動かす

いろいろと紆余曲折ありましたが、最終的に podman で動かすことで落ち着きそうなので記事にします。

d最近の私のお供は Claude なのですが早速聞いてみますとつらつらと Dockerfile を提示してきます。多少アレンジしてますが骨子はそのままです。

FROM --platform=linux/arm64 ubuntu:22.04


ENV DEBIAN_FRONTEND=noninteractive

RUN rm /var/lib/dpkg/info/libc-bin.* && apt-get clean

# 日本のミラーに向ける
RUN sed -i 's@archive.ubuntu.com@ftp.jaist.ac.jp/pub/Linux@g' /etc/apt/sources.list

RUN apt-get update && \
    apt-get install -y wget \
    curl \
    git \
    vim \
    lsb-release \
    build-essential python3-pip python3-setuptools python3-dev \
    gnupg2 xterm x11-apps

# ROSのセットアップ(ここでは例としてROS 2 Humbleを使用)
RUN curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg
RUN echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | tee /etc/apt/sources.list.d/ros2.list > /dev/null
RUN apt-get update && apt-get install -y \
    ros-humble-ros-base \
    ros-humble-rqt* \
    ros-humble-rviz2 \
    python3-colcon-common-extensions

# 作業ディレクトリの作成
RUN mkdir -p /workspace
WORKDIR /workspace

# 環境変数の設定
RUN echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc

変更かけたのは、 sed で日本のミラーに向けたところと、rm /var/lib/dpkg/info/libc-bin.* でファイルを削除した箇所です。

特にこの libc-bin.* の削除をしないと、apt-get でのパッケージインストールにことごとく失敗するします。なんとなく削除するのは良くないような気もするのですが、 Stack Overflow でもいくつか Good がついているので大丈夫じゃないかと。

setup.bash もすでに読み込み済みなので起動すると即 ros2 コマンドが実行できる状態になっています。

ビルドと起動は下のようにします。

Claud は気が利いているのどうなのかこの状態で GUI アプリも動作出来るようにしてくれているようでコンテナを実行するにはこうするみたいです。

$  ls ./Dockerfile
./Dockerfile

$ podman build -t ros2-arm64 .

$ podman run --platform linux/arm64 \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=$DISPLAY \
  -v $HOME/.Xauthority:/root/.Xauthority \
  -v $HOME/ros2_ws:/workspace \
  --net=host \
  -it localhost/ros2-arm64

起動のたびにこのコマンド打つのはしんどいのでシェルスクリプトかなんかにしたほうがよさげ。

でコンテナの中で動作確認するには、下のようにしろと Claude が言うので試してみる。

; ホストに 目玉アプリが表示される。
in-contailner: # xeyes

; ホストに ros2 の rqt が表示される
in-contailner: # rqt 

ちゃんと計測したわけではないが qemu-system でエミュレーションより少し早い気がする。

にしても Claude に言われるがままだな。

参考

Dockerのイメージビルド中でapt-getを高速化するたった1つの方法 | ゲンゾウ用ポストイット
souces.list のミラーを日本の jaist に向ける設定

ruby on rails – Docker build fails because unable to install libc-bin – Stack Overflow
libc-bin のエラー回避

x86_64 の LM22 で arm64 の ubuntu 22.04 を動かす

前回記事では、同じ x86_64 の LM22 で arm64 向けのクロスビルド環境を設定しましたが、ちょっと考えてみると、ROS2 からヘッダやらライブラリを取ってきて /usr/aarch64-linux-gnu 以下に適切に配置するのはちょっと面倒そうだと思えてきたので qemu で arm64 の ubuntu を動かすことにした。

流れとしては Ubuntu の ARM64 vitual machines on QRME のページでいいのだが、Qita 見ないと行けない部分があったので記事にする。

$ sudo apt install qemu-kvm qemu-system-arm64 libvirt-daemon-system libvirt-clients bridge-utils virtinst libosinfo-bin

Ubuntu 22.04.05 をインストールインストールしたかったので releases から .iso ファイルをダウンロードしたのだが上手く起動しなかった。

Ubuntu Cloud Images – the official Ubuntu images for public clouds, Openstack, KVM and LXD から 22.04 を指し示す jammy > current と進み、jammy-server-cloudimg-arm64.img をダウンロードする。

wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-arm64.img

としてもいい。

ここから先は、Ubuntu 公式ではなく Qiita の参考ページの手順をやっていく。イメージサイズを変更する必要があるらしい。

$ qemu-img resize  jammy-server-cloudimg-arm64.img 16G

cloud イメージ用に設定ファイル作成する。

$ touch meta-data
$ touch user-data
$ vi user-data
;; 以下の内容を入れるらしい
#cloud-config
user: xxxxx
passowrd: xxxx
chpassword: { expire: Fail }
ssh_pwauth: True
:wq

上の設定だと、ユーザーが作成されて初回起動時にパスワード変更を強制される。さらに ssh のパスワード認証も許可される。
パスワード変更の強制が面倒なのであとで回避できる設定を調べようと思う。

ユーザーデータを保存?するイメージを作成する必要もあるみたい。
CD-ROMイメージだし、恐らく user-data と meta-data を読み出すためだけに作るものっぽい。

 ci$ genisoimage --output ./udata.iso --volid cidata -joliet -rock user-data meta-data

で、やっと仮想マシンを作成すると、ままんま

$ virt-install \
--connect qemu::///system \
--name u22-arm64 \
--vcpus 4 --ram 4096 \
--hvm --virt-type qemu \
--arch aarch64 \
--os-type linux --os-variant ubuntu22.04 \
--import --norebooy \
--disk path=./jammy-server-cloudimg-arm64.img  \
--disk path="./udata.iso,device=cdrom"

ここで iso ファイルにアクセスできない「permission denied」エラーが出ので最後の参考ページの内容を実行する。

/etc/libvirt/qemu.conf にユーザー名とグループ名を設定する

$ vi /etc/libvirt/qemu.conf
以下の2行をいい感じのところに追記

user = "ログインユーザー名"
group = "libvirt"
:wq

/etc/libvirt/libvirtd.conf も設定しないと行けないようだ。

$ vi /etc/libvirt/libvirtd.conf
unix_sock_group = "libvirt"
unix_socl_ro_perms = "0777"
unix_sock_rw_perms = "0770"

auth_unix_ro = "none"
auth_unix_rw = "nonw"
:wq

自分のケースはこのファイルは何も変更する必要がなかったかもしれない。

もう一度 virt-install をし直すと、無事に仮想マシンが作成され実行出来るようになった。

ブリッジネットワークを作成する必要があるというページもいくつか見かけたが、今回試した際は手動で作成することなく自動的にブリッジネットワーク(NAT)が作成されて完了した。

これで ROS2 のビルドできそうだ。とはいえこの PC だと遅い。

参考

Boot ARM64 virtual machines on QEMU – Ubuntu Server documentation
ARM64 となっているのに qemu-system-arm をインストールとなっているのは、qemu-system-arm64 の間違いだと思う。

Ubuntu20.04@x86_64のLinuxKVM上にaarch64のUbuntu20.04仮想マシンを立てる #Ubuntu – Qiita

virsh-install時にpermission deniedとなる場合 #KVM – Qiita