WPP
VSCode で g++ を使うための設定

他のページもちらほら見つかるが自分的最小メモを残しておく。

VSCode には予め CMake Tools のエクステンションをインストールしておく。

そして VSCode 上でステップ実行(デバッグ)するために 2 つの設定ファイルを作成 (編集)する必要があります。

tasks.json でビルド方法を定義し、launch.json でデバック起動方法を定義します。

CMake extensionの設定

CMake がインストールされていると VSCode の左下のほうに CMake .. のような表示が出てくるのでそこをクリックして、コンパイラを選択します。

tasks.json の設定

task.json ではビルドコマンドを定義します。なのでここでは、cmake を使ったビルド環境に合わせて調整します。

プロジェクトのフォルダに .vscode フォルダがあるはずなのでその中の tasks.json を編集します。

CTRL + SHIFT + P を押して tasks: Configure task などを選んで設定を追加します。

{
    "tasks": [
        {
            "label": "CMake: build",
            "type": "shell",
            "command": "/usr/bin/cmake",
            "args": [
                "--build",
                "${workspaceFolder}/build",
                "--config",
                "Debug"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                "$gcc"
            ],
            "detail": "Task generated by CMake Tools."
        }
    ],
    "version": "2.0.0"
}

“label” は表示される名前なので好きな感じにして OK です。
“command” と “args” でコマンドラインを組み立てます。ソースと同じディレクトリで実行するなら
`cmake –build ./build –config Debug` というコマンドになります。
ビルドディレクトリを変えたければ “${workspaceFolder}/build” を変更します。

tasks.json を設定しても、VSCode の Run メニューとかでは実行できないようです。どうしたら実行できるのかは後で調べる。

launch.json の設定

launch.json では VSCode の デバッグタブ? (左端の Run & Debug) で上部に表示できるデバッグ時の起動方法を設定する。

デバッグタブのギヤアイコンをクリックすると設定を追加できる。

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "CMake Debug",
            "type": "cppdbg",
            "request": "launch",
            "program": "${command:cmake.launchTargetPath}",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [
                {
                    "name": "PATH",
                    "value": "S{env:PATH}",
                    // "name": "LD_LIBRARY_PATH",
                    // "value": "/usr/local/cuda-11.8/lib64:/usr/local/cuda-11.8/lib64/stubs:/usr/local/cuda-11.8/targets/x86_64-linux/lib"
                }
            ],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb.",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "CMake: build"
        }
    ]
}

launch.json はきほんそのままで動くみたいだが、
“environment” に PATH や LD_LIBRARY を追加すると
`PATH=xxx LD_LIBRARY [ビルドしたプログラム]`
のように起動することになるらしい。

これで次回からも設定に戸惑わなくなりそう。

bat の小ネタ

bat というシンタックスをハイライトしてくれる cat クローンがあってそれを常用しています。

ネタ的には bat というより less の -X オプションをしらなかったというしょうもない話になりますが忘れないためにメモします。

bat は less のようなページャとしての側面も持っており長いファイルの場合は、一旦画面が止まって入力待ちになるのですが、デフォルトだとこんな時に q で終了しても画面がクリアされてしまい。ファイルの内容が見えなくなってしまいます。これが地味に不便でした。

一方 less では、これを回避するための -X オプションがあり最終画面を残したまま終了することができます。

cat のページャ機能は結局のところ less を使って実現しているようなので -X を強制的に渡すと望んでいることができるようです。

export BAT_PAGER='less -XFR'

これで終了時の画面をクリアしなくなります。

設定を永続化するには、 .bashrc などに上記を追加して source ~/.bashrc で反映します。

また一つ地味な不便さを解消できました。

参考

bat: bat/doc/README-ja.md at master · sharkdp/bat

自ホストの外側の IP アドレスを curl で取得する。

IP アドレスでアクセス制限すfる場合に自ネットワークの外側からみた IP アドレスを調べたい場合がある。外部の API サーバーや Web サーバーが接続元の IP アドレスで制限するような場合だ。

ローカルのルーターに入れば確認することは当然にできるがまあ面倒です。curl でアクセスすると自ネットの IP アドレスを返してくれるサイトがあります。以前から ipinfo.io は知ってましたがこのサイトだと IPv4 しか返してくれません。(恐らく IPv4 でしか接続を受け付けてくれないのでしょう。)

Claude に “curl で自ホストのIPアドレスを確認できるサイトをリストアップして” と聞いてみると以下の回答を返してくれました。

IP アドレスを確認できるウェブサイトに対して、curl コマンドでアクセスできるものをリストアップします。以下のサイトでは外部から見たあなたの IP アドレスを確認できます:

1. `curl ifconfig.me`
2. `curl ipinfo.io/ip`
3. `curl api.ipify.org`
4. `curl checkip.amazonaws.com`
5. `curl icanhazip.com`
6. `curl ipecho.net/plain`
7. `curl ip.tyk.nu`
8. `curl wtfismyip.com/text`
9. `curl ipaddress.sh`
10. `curl myip.dnsomatic.com`

これらのサイトはプレーンテキストで IP アドレスだけを返すため、curl コマンドと相性が良いです。追加情報が必要な場合は、例えば `curl ipinfo.io` のようにすると、IP アドレスだけでなく地理的な位置情報なども取得できます。

ひとつづつ確認してみると、IPv6 と IPv4 を返すサイトが半々くらいでした、10 はアクセスできませんでした。で、自分にはこれらのサイト名はちょっと覚えにくかったので IPv6 と IPv4 を両方とも表示するスクリプトにしました。

# get outside IP address. this script gets IPv6 and IPv4 address both.

#!/bin/bash

# for IPv6
echo -n "IPv6: "

# 出力に改行がないパターン
curl ipecho.net/plain
# curl ipecho.net/plain
# curl ip.tyk.nu
echo ""

# 出力に改行のあるパターン
# curl wtfismyip.com/text
# curl ifconfig.me
# curl icanhazip.com
# curl wtfismyip.com/text

# for IPv4
echo -n "IPv4: "
curl ipinfo.io/ip
#curl api.ipify.org
echo ""

# 出力に改行のあるパターン
# curl checkip.amazonaws.com
# curl ipaddress.sh
RUSTDESK がいい感じ

これまで linux での VNC の設定がいまだによくわからないので、nomachine をリモートデスクトップ接続に使用していました。

数あるリモートデスクトップアプリの中でも nomachine は linux, Mac, Raspberry pi, Windows に対応し都合が良かったからです。

一方で Windows ドメイン (Active Directory) に参加している Windows にリモート PC からアクセスすると度々認証まわりのエラーで接続できないことが多くちょっと面倒だとおもっていました。
具体的には設定等を変更していないのに、あるときは接続に失敗したり、別のときは成功したりといった現象にわずらわされていました。これは推測ですが、Windows ドメイン認証は、社内ネットワークに接続していない状態でPC にログインできるように認証情報がキャッシュされる仕組みがあったはずです。このキャッシュでの認証できる状態だとどうやらログインできている気がする。(反対向きにいうとネットワーク経由でログインしたときは、どうもnomachine で必要な権限が許可されていないようだ。)

話がながくなったが、上に閉口して移転先を探してみた。

候補としては、X2Go、RUSTDESK、Dayon が見つかったが今回は RUSTDESK を使用することにした。

Windows でのインストール

scoop にパッケージがあったので `> scoop install rustdesk` でインストールした。

Linux でのインストール

LM22 では デフォルトのアプリストアに flatpak で掲載されていたので flatpak でインストールした。

2025-3-25 追記:

LM22 で RUSTDESK をインストールしただけの状態では、デスクトップセッション(X11)を開いてからしか使えないようなので、自動ログインするように設定した上で、 [Startup Applications] で RUSTDESK を起動するようにした。

Raspberry pi でのインストール

参考ページの Pi-Apps というのを経由して入れてみた。RUSTDESK 自身は github にあるんですが、Version-Upの度に手動インストールは結構だるいので、Pi-Apps を使ってみることにした。

使用方法

説明を明確にするための用語の定義

リモート PC: リモートからアクセスさせたいPC (画面なしPC や手元以外のPC)

ローカル PC: 自画面に外部PC の画面を表示してコントロールする PC

  1. リモート PC で RUSTDESK を起動する。
    • この PC をヘッドレス運用したい場合は、固定パスワードを指定する。
    • リモートPC の ID とパスワード をメモる (メモらなくてもいいがこの PC の ID でリモートから接続する)
  2. ローカル PC でも同じように RUSTDESK を起動する。
  3. リモート PC の ID で接続開始する。
  4. リモート PC のワンタイムパスワードか固定パスワードで認証要求をかける
  5. リモート PC の画面が表示される。

あくまで体感でしかないが、nomachine や VNC よりもキビキビと動いているきがする。画面表示もクッキリなきがしていいかもしれない。

当面はこれを使っていこう。

参考

Install RustDesk on Raspberry Pi | Pi-Apps

rustdesk/rustdesk: An open-source remote desktop application designed for self-hosting, as an alternative to TeamViewer.

ラズベリーパイに eza をインストール

eza は ls の代替コマンドでいい感じに表示してくれるやつ。LM22 や Ubuntu では気に入って使用しているが RaspberryOS ではデフォルトではインストールできないようだ。

公式の説明では以下の通りだが、RaspberryOS (bullseye) では 若干ディレクトリ構成がことなるので調整する。

$ sudo mkdir -p /etc/apt/keyrings
$ wget -qO- https://raw.githubusercontent.com/eza-community/eza/main/deb.asc | sudo gpg --dearmor -o /etc/apt/keyrings/gierens.gpg
$ echo "deb [signed-by=/etc/apt/keyrings/gierens.gpg] http://deb.gierens.de stable main" | sudo tee /etc/apt/sources.list.d/gierens.list
$ sudo chmod 644 /etc/apt/keyrings/gierens.gpg /etc/apt/sources.list.d/gierens.list
$ sudo apt update
$ sudo apt install -y eza

gpg キー用のフォルダが /etc/apt/trusted.gpg.d となり keyrings とは異なっていたので変更。

gpg キーファイル、ソースストのファイル名も eza.gpg と eza.list にそれぞれに変更した。もとの gierens という名前だと後で見たとき恐らく何ために入れたかわからなくなりそうなので変えた。
これは好みの問題で、そのままで変える必要はない。

$ wget -qO- https://raw.githubusercontent.com/eza-community/eza/main/deb.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/eza.gpg
$ echo "deb [signed-by=/etc/apt/trusted.gpg.d/eza.gpg] http://deb.gierens.de stable main" | sudo tee /etc/apt/sources.list.d/eza.list
$ sudo chmod 644 /etc/apt/trusted.gpg.d/eza.gpg /etc/apt/sources.list.d/eza.list
$ sudo apt update
$ sudo apt install -y eza

eza という名前を忘れるのでエイリアスを ~/.barshrc や~/ .bash_aliases に書き込む。書き込んだら . (source コマンド) で反映させる。

$ alias ls='eza'
$ . ~/.bashrc

参考

eza/INSTALL.md at main · eza-community/eza

LM22: Mozc の辞書ツールにキーボードショートカットを割り当てて、ユーザ辞書を追加した

最近、日本語変換で積極的に単語登録するようにしている。特別な方法ではなくよくある「よろ」で「よろしくお願いします」に変換するような短縮を登録している。

で、辞書に単語登録するのが面倒な理由の一つが辞書ツールや登録ツールを呼び出すのに IME のアイコンから右クリックしてメニューを選択するというアクションがいちいち面倒なためだと思う。
この面倒さは、Linux のデスクトップでも Windows でもほとんど変わらない。しかの最終的に変換できてしまうものだからなんとなく後回しにしがち。

でだ、辞書ツールのコマンドラインがわからないので Archi Linux の Wiki を調べるとユーザー辞書を追加したほうがいいよ的なことが書いてあるのであわせて実施してみた

辞書ツールにショートカット割り当て

LM22 (Linux Mint) のCinnamon で行っているので Ubuntu とか他のデスクトップ環境では若干異なると思うがほぼ同じようなことはできるはずだ。

辞書ツールのコマンド

Mozc – ArchWiki によると設定ツール、辞書ツール、単語登録というのは mozc_tool という一つのファイルで引数を切り替えることで使い分けているようです。

実際のコマンドはこんな感じらしい。

設定ツール:
/usr/lib/mozc/mozc_tool –mode=config_dialog

辞書ツール
/usr/lib/mozc/mozc_tool –mode=dictionary_tool

単語登録
/usr/lib/mozc/mozc_tool –mode=word_register_dialog

今回は、ラウンチャアイコンは作成せずに、辞書ツールに直接キーボード・ショートカットを割り当てることにした。

  1. 設定アプリからキーボードを開く
  2. ショートカットタブを選択する
  3. カスタムショートカットを選択
  4. [Add custom shortcut] ボタンをクリック
  5. Name: を適当に決める
  6. Command: に /usr/lib/mozc/mozc_tool –mode=dictionary_tool を指定する
  7. 登録して、ダイアログを閉じる。
  8. 下段のキーボードバインディングで unassigned の行をダブルクリックする。
  9. 割り当てたいキーボードショートカットを押す。

自分は、Shift + Ctrl + D をショートカットに割り当てましたが、このへんは好みで変えてほしい。
また、個人的な好みでダブリ登録したくないので辞書ツールを起動しているが、単語登録でもいいと思う。

ユーザー辞書登録

ネット上では Mozc UT ってのを使うっていう記事がたくさん見つかりますがこれ、Mozc そのものをビルドしなきゃいけないんですね。ちょっと面倒なので、他の方法でいくことにした。

Mozc UT Dictionaries

utuhiro78/merge-ut-dictionaries: Merge multiple Mozc UT dictionaries into one and modify the costs.

だいぶ古い記事になるのですが、

Google日本語入力 強化辞書の構成を変えてみた。 – 黒MacBookが好き の辞書をインポートして使っている。

Mozcに辞書を追加した: arcadia’s blog のやり方が参考になるかもしれない。

考えるのも面倒だったので、自分の場合はそのまま辞書ツールでインポートした。

英和と和英辞書はインポートしなくてもよかったかもしれない。

Remmina が mdns で名前解決できるようにした

最近は、いちいち VNC クライアントをインストールがめんどうなので LM22 にはじめから入っている Remmina を 使っている。

がしかし、Remmina だと mdns による名前解決が使えなくて困っていた。

Remmina 自身は flatpak でインストールしていたが、D-Bus のパーミッション (socket=system-bus、socket=session-bus) を許可しても現象に変化がなかった。

Claude に聞いてみると /etc/nsswitch.conf を書き換えろってことでやってみた。

変更前:
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname mymachines

変更後:
hosts: files mdns4_minimal mdns4 [NOTFOUND=return] dns myhostname mymachines

[NOTFOUND] の前に mdns4 を追加すると Remmina でも名前解決できるようになった。

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"
───────┴──────────────────────────────────────────────────────────────────────────────────────────────
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