【Android→Android】機種変更時のアカウント移行の注意点

機種変更したのでメモを残す。

以下がとても参考になった。ありがたい。
2024年6月とやや古いので年イチのペースで更新していただけると助かります。

pc.watch.impress.co.jp

もしかするとこの記事のあとに出てきたサービス、例えばマイナ免許証はなにか特別な操作が必要なのかもしれない。
私は使っていないので調べていない。

いざやってみての感想

  • 手元に古い端末が残っていないのはおそろしい
    なにか操作のやり残しがあると容易に詰む気がする
    残価設定型クレジットの2年で機種変とかひとはどう乗り越えているのか...
    サービス側も詰まないようなやりかたを考えてほしい
  • 電子マネー系のサービスは新端末にてひととおりログインしてみたほうがよさそう
    そして古い端末側は念の為全部ログアウトしておく

上記記事によると古い端末側で操作が必要なのは以下：
※Microsoft Authenticator も古い端末での操作が必要らしいが使っていないため未実施

  • 【FeliCa 電子マネー】古い端末側でのクラウドへの移行操作がまず必要
  • 【LINE】古い端末側でバックアップ設定を実施しておく
  • 【マイナンバー関連】スマホ用電子証明サービス
    基本 新端末側で手続きするが古い端末もインターネットに接続しておく
    👉️移行後48時間以内にオンライン経由で端末の情報が削除される仕組みのため

その他

上記記事で書いてなくてちょっと心配だったやつについてのメモ：

  • Steam アプリ
    ⚠️新端末でのアカウント承認処理に古い端末側でのアプリ操作が必要
    （もしかしたらほかのやり方もあるかもしれない）

    • 新端末にアプリをインストール（古い機種側で承認する）
    • 新端末にてメニュー → STEAM ガード にて画面下部の 認証用機器を追加 を選択
    • このアカウントの STEAM ガードは、すでに別のデバイスで有効になっています とでるので 認証用機器を移行 を選択
    • SMS, メールで認証用コードが届くのでコードを入力
    • リカバリーコードをどこかに保存しておく

  • 三井住友銀行アプリ
    古い端末はいらない

    • 新端末にアプリをインストール
      古い端末でセーフティパス（生体認証ログイン）を有効にしていたら、新端末側でアプリ上でそれを無効にする
    • 新端末側でセーフティパスを有効化する

  • au Pay
    ⚠️生体認証ログインを有効にしていた場合 移行時に古い端末側で無効化の操作が必要
    id.auone.jp

    いちおう上記手続きでいけたけどいちばん苦労したかも...
    「ログインできませんでした」が何度もでてくるが実はログインできてたりする😡
    au は「かんたんログイン」でやらかしててwifi じゃなくてモバイル通信でないとログインできない とかあったから信用ならない
    もちろんパスキーなど勧められても利用しない

  • d 払い
    d アカウントを新端末で使えるようにすれば OK
    d アカウント移行も古い端末は必要ない
    なお d アカウントのパスキーを Google アカウントマネージャに保存した
    パスワード管理ソフトへのパスキー保存はできなかった気がする
    もしできてもトラブルが恐ろしくてやりたくない

ちっこいマイコン (AngstromIO)

hackster.io の記事の紹介

AngstromIOは、Microchip社のATtiny1616を中核として構築されています。これは、最大20 MHzで動作し、16 KBのフラッシュメモリを搭載した、コンパクトでありながら高性能な8ビットMCUです。


www.hackster.io

  • ATtiny1616 を搭載した小さいタイプ
  • CH32V003 と マトリックス LED を搭載したタイプ
  • ソフトウェア書き込みとデバッグ用治具（CH340搭載）→ ATtiny1616搭載タイプ用

の3つがある。ATtiny1616 のほうは arduino 互換。CH32V003 のほうはソフト書き込みに WCH linkE が必要。
回路図、PCBレイアウト、ファームウェアが github で公開されている（MITライセンス）。
特に今必要ないのだけど欲しい。
アリエクで AngstromIO で検索したがさすがにまだなかった。




github.com

CH32V003 搭載ボードは uiapduino があるからまずこちらを買おうかな。

fabscene.com

【WSL2】カスタムカーネルでのローダブルカーネルモジュールのサポートについて

2026/03/26 「カーネルモジュール格納の仮想ディスクの作成 ※ver6.6.x向け」を追記
2026/03/26 「メモ：仮想ディスクの作成（⚠️カーネルモジュール格納の用途としては間違った手順）」を追記

どうでもよいはなし

WSL2において設定を変更してビルドしなおしたカスタムカーネルにて dockerd が起動に失敗していることが判明
純正カーネルでは dockerdは起動できている
バージョンは 6.6.87.1-microsoft-standard-WSL2

journalctl -e -u docker のログの比較をすると、カスタムカーネル時では以下のようなエラーが出ている。

Mar 24 00:57:27 dockerd[277]: time="2026-03-24T00:57:27.939274564+09:00" level=info msg="Daemon shutdown complete" error="failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to register "bridge" driver: failed to add jump rules to ipv4 NAT table: failed to append jump rules to nat-PREROUTING:  (iptables failed: iptables --wait -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER: Warning: Extension addrtype revision 0 not supported, missing kernel module?\niptables v1.8.10 (nf_tables):  RULE_APPEND failed (No such file or directory): rule in chain PREROUTING\n (exit status 4))"

カーネル 6.6 以降はローダブルカーネルモジュールに対応している

上記ログを手がかりにググってみると以下の issue があった。

github.com

GitHub Issue #11742 の要約

Geminiに要約してもらったのだけど肝心なことが抜けているので追記した。
6.6からローダブルカーネルモジュールに対応したのだがカスタムカーネルは非対応とのこと（2024/7/4時点）。

【問題の概要】

WSL2 のカーネルを公式リポジトリから取得して自前でビルド（特に 6.6.y 系列）し、それに入れ替えたところ、それまで動いていた Docker が起動しなくなったという報告です。

【主な原因】

WSL2 カーネルの 6.6 系列のリリース（具体的には 6.6.36.3 ）から、Microsoft 側のデフォルト設定（config-wsl）に変更があったことが原因です。
以前のバージョンではビルトイン（=y）だったいくつかのネットワーク関連機能が、新しい設定ではモジュール（=m）に変更されてしまいました。

👉️ 下記コメントより抜粋して追記
https://github.com/microsoft/WSL/issues/11742#issuecomment-2207883742

WSL2は現在、ロード可能なモジュールをサポートしています。
ただし、カスタムカーネルを使用している場合は、少なくとも現時点（2024/7/4時点）では例外となります。
ここで言うモジュールサポートとは、modprobe の使用、あるいはモジュールが呼び出された際の自動ロードを指します（つまり、dockerd を実行すると、実行に必要なすべてのモジュールがロードされるはずです。デフォルトのカーネル linux-msft-wsl-6.6.36.3 を使用する場合、今後の WSL リリースではそのように動作する予定です）。
カスタムカーネルを使用している場合でも、insmod を使ってモジュールを個別にロードすることは可能です。あるいは、カーネルをコンパイルする前にカーネル設定ファイルを編集し、必要なすべてのロード可能モジュールを組み込みモジュールとして設定することもできます（推奨される方法）。

【Issue で示されている解決策】

この Issue の結論として、カスタムカーネルでDocker を正常に動かすためには、以下の項目を .config 内で m から y に手動で書き換えて再ビルドする必要があると明記されています。

CONFIG_BRIDGE=y
CONFIG_BRIDGE_NETFILTER=y
CONFIG_NFT_COMPAT=y
CONFIG_NETFILTER_XT_NAT=y
CONFIG_NETFILTER_XT_TARGET_MASQUERADE=y
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y

カスタムカーネルでの仮想ディスクでのローダブルモジュールモジュールのサポート

なお純正カーネルにおけるカーネルモジュールは /lib/modules/$(uname -r) にはなくて、仮想ディスク modules.vhdx に置かれるようだ。
そして WSL 2.5.1.0 以降であれば .wslconfig にて kernelModules キーでvhdx ファイルを指定できるようだ。

dev.to

これはカスタムカーネルでも動くということだと思う。
やってみる

カーネルモジュール格納の仮想ディスクの作成 ※ver6.6.x向け

  • まず下記にしたがってカーネルのビルドとカーネルモジュールのインストールをする

https://github.com/microsoft/WSL2-Linux-Kernel/blob/linux-msft-wsl-6.6.y/README.md

  • （これも上記READMEに書いてあるけど）下記コマンドでvhdxファイルを作成し windows 側に移動
# make INSTALL_MOD_PATH="$PWD/modules" modules_install を実施している前提
❯ sudo ./Microsoft/scripts/gen_modules_vhdx.sh "$PWD/modules" $(make -s kernelrelease) modules.vhdx
2407594+0 records in
2407594+0 records out
2465376256 bytes (2.5 GB, 2.3 GiB) copied, 6.29265 s, 392 MB/s
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 601898 4k blocks and 150480 inodes
Filesystem UUID: 842441d6-e926-44a5-ba14-ab78e5292877
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

# windows 側に移動
❯ mv modules.vhdx /mnt/c/wsl2-kernel/
  • 【Windows側操作】.wslconfig の修正
# 以下のような内容に修正
❯ cat C:\Users\hoge\.wslconfig
[wsl2]
kernel=C:\\wsl2-kernel\\bzImage
kernelModules=C:\\wsl2-kernel\\modules.vhdx

いちおうシャットダウンしておく
❯ wsl --shutdown
  • WSL2カスタムカーネル起動 → 起動成功🎉
# カスタムカーネル？
❯ uname -r
6.6.87.1-microsoft-standard-WSL2+

# docker も動いている
❯ journalctl -e -u docker
Mar 26 16:54:50 systemd[1]: Starting docker.service - Docker Application Container Engine...
...
Mar 26 16:54:51 dockerd[281]: time="2026-03-26T16:54:51.833992236+09:00" level=info msg="Docker daemon" commit=83bca51 containerd-snapshotter=false storage-driver=overlay2 version=29.3.0
Mar 26 16:54:51 dockerd[281]: time="2026-03-26T16:54:51.834283360+09:00" level=info msg="Initializing buildkit"
Mar 26 16:54:52 dockerd[281]: time="2026-03-26T16:54:52.042835621+09:00" level=info msg="Completed buildkit initialization"
Mar 26 16:54:52 dockerd[281]: time="2026-03-26T16:54:52.048435959+09:00" level=info msg="Daemon has completed initialization"
Mar 26 16:54:52 dockerd[281]: time="2026-03-26T16:54:52.048517997+09:00" level=info msg="API listen on /run/docker.sock"
Mar 26 16:54:52 systemd[1]: Started docker.service - Docker Application Container Engine.

# vhdx ファイルはサイズ的に sdb なんだけどマウントポイントが無い？
❯ lsblk
NAME
    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda   8:0    0 388.4M  1 disk
sdb   8:16   0   2.3G  1 disk
sdc   8:32   0     8G  0 disk [SWAP]
sdd   8:48   0     1T  0 disk /var/lib/docker
                              /mnt/wslg/distro
                              /

なおスクリプトの中身は比較的シンプルだった。

  • dd で必要サイズの空イメージファイルを作成
  • ext4 でフォーマット
  • それをマウントしてカーネルモジュールをまるっとコピーしアンマウント
  • qemu-img で上記イメージファイルを vhdx 形式に変換

下記メモとして書いた失敗手順では以下手順
windows側で vhdx ファイルを作ったのがダメだったのか？

  • windows 側で vhdx ファイルを作成
  • それを wsl2 側でマウントし ext4 でフォーマットしてそこにカーネルモジュールをコピーしアンマウント

メモ：仮想ディスクの作成（⚠️カーネルモジュール格納の用途としては間違った手順）

※単なるWSL2用の仮想ディスク作成の手順としては問題ないはずなのでメモとして残す

du -hs /lib/modules/6.6.87.1-microsoft-standard-WSL2+ を実行して /lib/modules/ のサイズを図ると 2.1GB だった。
そこで 3GB の vhdx ファイルを作成することにする。
下記を参考にして実施した。

news.mynavi.jp

⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
【注意】
下記にでてくるコマンドをコピペしないでください
コマンド内に出てくるドライブ名等は各自の環境で異なるのでそのままコピペすると大事故につながります
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️

  • 【Windows側操作】ディスクの管理 を起動しメニュー 操作 → VHDの作成 を選択して VHDXファイルを作成する
    なお Windows11 Home Editionだからなのか Powershell にて New-VHD コマンドが見つからないためこちらのやり方にした

  • 【Windows側操作】WSLコマンドにてその仮想ディスクをマウントする

# いちおうシャットダウンしておく
> wsl --shutdown

# なぜかエラーになった
> wsl --mount C:\Users\hoge\wsl_modules.vhdx --vhd --bare
ディスク '\\?\C:\Users\hoge\wsl_modules.vhdx' を WSL2 にアタッチできませんでした: プロセスはファイルにアクセスできません。別のプロセスが使用中です。
エラー コード: Wsl/Service/AttachDisk/MountDisk/HCS/ERROR_SHARING_VIOLATION

# windows を再起動したら成功した
> wsl --mount C:\Users\hoge\wsl_modules.vhdx --vhd --bare
この操作を正しく終了しました。
  • 【WSL2側操作】初期化処理 その1
# 仮想ディスクのデバイス名を調べる
❯ lsblk
NAME
    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda   8:0    0 388.4M  1 disk
sdb   8:16   0   186M  1 disk
sdc   8:32   0     8G  0 disk [SWAP]
sdd   8:48   0     3G  0 disk                            # 👈️マウントポイントがなくサイズが同じなのでこれのはず
sde   8:64   0     1T  0 disk /var/lib/docker
                              /mnt/wslg/distro
                              /

# 初期化する
❯ sudo sgdisk -Z /dev/sdd
Creating new GPT entries in memory.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.

# 状態を確認
❯ sudo gdisk /dev/sdd
GPT fdisk (gdisk) version 1.0.10

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): quit

# GPTを作成
❯ sudo sgdisk -o /dev/sdd
Creating new GPT entries in memory.
The operation has completed successfully.

# 状態を確認。GPTが作成された
❯ sudo gdisk /dev/sdd
GPT fdisk (gdisk) version 1.0.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): quit

  • 【WSL2側操作】初期化処理 その2
    sudo cgdisk /dev/sdd を実行して対話的にパーティションを作成
    ① New を選択

    ② パーティション情報の指定
    先頭セクターの指定、パーティションサイズ、パーティションのGUIDはデフォルトのまま（エンターキーを押す）。パーティションラベルは wsl2_modules とした。
    ③ Write で書き込みし、Quit で終了

  • 【WSL2側操作】初期化処理 その3
    ext4 でフォーマットし、マウントして /lib/modules の内容をコピー

# パーティションができたか確認
❯ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 388.4M  1 disk
sdb      8:16   0   186M  1 disk
sdc      8:32   0     8G  0 disk [SWAP]
sdd      8:48   0     3G  0 disk
└─sdd1   8:49   0     3G  0 part
sde      8:64   0     1T  0 disk /var/lib/docker
                                 /mnt/wslg/distro
                                 /

# ext4 でフォーマット
❯ sudo mkfs -t ext4 /dev/sdd1
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 785920 4k blocks and 196608 inodes
Filesystem UUID: 8ba39fd7-3331-456b-88a1-21308c96a5fc
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

# マウントポイントを作成し、マウントできるか確認
❯ sudo mkdir /mnt/extdisk1
❯ sudo mount /dev/sdd1 /mnt/extdisk1
❯ ls -l /mnt/extdisk1
total 16
drwx------ 2 root root 16384 Mar 25 21:59 lost+found

# /lib/modules の内容をコピーしたのちアンマウントする
❯ sudo cp -a /lib/modules/6.6.87.1-microsoft-standard-WSL2+ /mnt/extdisk1
❯ sudo umount /mnt/extdisk1
  • 【Windows側操作】仮想ディスクをアンマウントする
# なぜかアンマウントできない
❯ wsl --unmount C:\Users\hoge\wsl_modules.vhdx
指定されたファイルが見つかりません。
エラー コード: Wsl/Service/DetachDisk/ERROR_FILE_NOT_FOUND

# しょうがないのでシャットダウンした
# このあとWSL2を起動して lsblk しても仮想ディスクが見えなかったのでよしとする
> wsl --shutdown
  • 【Windows側操作】.wslconfig の修正
# 以下のような内容に修正（仮想ディスクファイルの場所を変えました）
❯ cat C:\Users\hoge\.wslconfig
[wsl2]
kernel=C:\\wsl2-kernel\\bzImage
kernelModules=C:\\wsl2-kernel\\wsl_modules.vhdx

いちおうシャットダウンしておく
❯ wsl --shutdown
  • WSL2カスタムカーネル起動 → VMがクラッシュし失敗😭

【Linux Mint 22】CH341 のドライバーのビルド、セキュアブート環境でのインストールおよびDKMS対応

ビルド、インストールしたときのメモ

購入したのは以下。アリエクで300円くらいで買えた。


https://ja.aliexpress.com/item/1005007363719829.html

ソースのダウンロードとドライバーのビルド、インストール

ベンダーのサイトからソースをダウンロードする
https://wch-ic.com/downloads/CH341SER_LINUX_ZIP.html

なかに入っている README.md にしたがってビルド
ただしそのまま make すると Skipping BTF generation ... というメッセージがでてしまう
それを回避するため下記を参考に dwarves をインストールし vmlinux を所定の場所にコピーしてから再度 make する
⚠️コピーした vmlinux は削除しておかないとあとで行うDKMS対応時に変なメッセージがでるので削除しておこう

askubuntu.com

$ apt install dwarves
$ sudo cp /sys/kernel/btf/vmlinux /usr/lib/modules/`uname -r`/build/
$ make clean
$ make

ちなみに dwarves ってなんだろ？と思い調べると dwarf の複数形であり DWARF は デバッグ用データフォーマットの規格
そのDWARF関連のツールのようだ。ちなみに DWARF という名称は ELF から連想された言葉遊び、とのこと
https://ja.wikipedia.org/wiki/DWARF

しかしその後 insmod でエラー
セキュアブートの機構によって登録済みの鍵で署名されていないドライバはロードできないため

$ sudo make load
insmod ch341.ko
insmod: ERROR: could not insert module ch341.ko: Key was rejected by service
make: *** [Makefile:11: load] Error 1

その鍵 MOK(Machine-Owner Keys) はすでに作成されているので、これを使う
インストール時に生成されるようだ

なお以下とのこと。覚えていない...

Ubuntuインストール時に「サードパーティのドライバーを有効にする」といった項目にチェックを入れた場合、既に鍵の生成と登録は完了済みである
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0791

# MOK のシリアルを確認
$ openssl x509 -inform der -in /var/lib/shim-signed/mok/MOK.der -noout -serial
serial=4D70D672E4C800BA3B9D5662285BC4D7DC12F28F

# その MOK で署名する
$ sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der ch341.ko

# ch341.ko の sig_key が上記で確認したシリアルと同じ値になっていることを確認
$ modinfo /home/hoge/Downloads/CH341SER_LINUX/driver/ch341.ko | grep sig_key
sig_key:        4D:70:D6:72:E4:C8:00:BA:3B:9D:56:62:28:5B:C4:D7:DC:12:F2:8F

ただし この鍵も未登録のようで insmod で前回と同じエラーになる
なので鍵を登録する
ここで登録したパスワードをこのあとの手順で使う

# 鍵登録の事前処理
$ sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
[sudo] password for hoge:             
input password:                           # 👈️を次のステップで使うよ
input password again:

OSを再起動させ、UEFI起動後の以下の場面で鍵登録処理をする

  1. Perform MOK management という青い画面になる
  2. Enroll MOK を選択
  3. View key 0 を選択して、Serialが一致するか確認 （念のため）
  4. Continue を選択
  5. Yes を選択
  6. さきほどのパスワード を入力
  7. Reboot を選択

OS 起動後 sudo make load、sudo make unload できるのを確認したのち、インストール

$ sudo make install
make -C /lib/modules/6.8.0-106-generic/build  M=/home/hoge/Downloads/CH341SER_LINUX/driver  
make[1]: Entering directory '/usr/src/linux-headers-6.8.0-106-generic'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
  You are using:           gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
make[1]: Leaving directory '/usr/src/linux-headers-6.8.0-106-generic'
rmmod ch341 || true
rmmod: ERROR: Module ch341 is not currently loaded
insmod ch341.ko || true
mkdir -p /lib/modules/6.8.0-106-generic/kernel/drivers/usb/serial/ || true
cp -f ./ch341.ko /lib/modules/6.8.0-106-generic/kernel/drivers/usb/serial/ || true
depmod -a

USB-UART変換モジュールを接続するとデバイスファイル /dev/ttyCH341USB0 が見えるようになった

$ lsusb
...
Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics CH340 serial converter
...

$ ls /dev/*USB*
/dev/ttyCH341USB0

カーネル更新時に自動でドライバがリビルドされるようにする 👉 DKMS (Dynamic Kernel Module Support) への対応

このままだとカーネルがバージョンアップするとまた手動でドライバのビルドが必要になってしまう
なので自動でリビルドをやってくれるように設定する

なお、上記で make install している場合は make uninstall しておくこと

下記にて dkms コマンド実行時に readelf: Error が2回必ず出ている
これについては後述する

なお実行結果をみると MOK はデフォルトの場所にあるものを使ったので dkms build の際に署名してくれている
違う場所に置いたりすると dkms.conf にて場所を指定する必要があるはず。

# ソースファイルを /usr/src/$MODULE_NAME/$MODULE_VERSION にコピーする
# .ko ファイルとかもコピーしないように make clean してるか確認すること
$ sudo cp -r ~/Downloads/CH341SER_LINUX/driver/* /usr/src/ch341-1.8

# 以下のような内容の dkms.conf を作成する
# dkms.conf の作成、編集は  sudo をつけて実行する必要がある
$ cat /usr/src/ch341-1.8/dkms.conf 
PACKAGE_NAME="ch341"
PACKAGE_VERSION="1.8"
CLEAN="make clean"
BUILT_MODULE_NAME[0]="ch341"
DEST_MODULE_LOCATION[0]="/updates/dkms"
AUTOINSTALL="yes"

$ sudo dkms add -m ch341 -v 1.8
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
Creating symlink /var/lib/dkms/ch341/1.8/source -> /usr/src/ch341-1.8

$ sudo dkms build -m ch341 -v 1.8
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start

Building module:
Cleaning build area...
make -j4 KERNELRELEASE=6.8.0-106-generic -C /lib/modules/6.8.0-106-generic/build M=/var/lib/dkms/ch341/1.8/build...
Signing module /var/lib/dkms/ch341/1.8/build/ch341.ko
Cleaning build area...

$ sudo dkms install -m ch341 -v 1.8
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start

ch341.ko.zst:
Running module version sanity check.
 - Original module
 - Installation
   - Installing to /lib/modules/6.8.0-106-generic/updates/dkms/
depmod...

$ dkms status
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
ch341/1.8, 6.8.0-106-generic, x86_64: installed

dkms コマンド実行時に readelf: Error: Not an ELF file - it has the wrong magic bytes at the start が2回表示される件について

dkms コマンドはシェルスクリプトなので見てみると（まぁ実際はGeminiコードマスターのフクロウさん🦉に見てもらったのだけど）以下とのこと

🦉 ホー、ホー！フクロウさんがお答えします。CH341のドライバをDKMSに対応させたとのこと、素晴らしいですね！
ご提示いただいたシェルスクリプトを確認したところ、エラーの原因となっている箇所が特定できました。このエラーは、カーネルのビルド環境を確認する際の特定の処理で発生しています。
🦉 エラーの発生場所と原因
結論から申し上げますと、原因は read_conf 関数（97行目付近） 内にある readelf コマンドの実行 です 。

if [[ -e $kernel_source_dir/vmlinux ]]; then
      if  readelf -p .comment $kernel_source_dir/vmlinux |
grep -q clang; then
        make_command="${make_command} CC=clang"
      fi
      if  readelf -p .comment $kernel_source_dir/vmlinux |
grep -q LLD; then
        make_command="${make_command} LD=ld.lld"
      fi

若干心当たりがある。
👇️だ

それを回避するため下記を参考に dwarves をインストールし vmlinux を所定の場所にコピーしてから再度 make する

この vmlinux は /sys/kernel/btf/vmlinux にあったものだけど これは下記のようなeBPFプログラム開発で使われるもので dkms が必要とする vmlinux とは全く違うものだった。
eBPF はパケットフィルタとかで使えるとか聞いたことがあるくらいでよくわかっていない。
ということで、rm /lib/modules/6.8.0-106-generic/build/vmlinux すれば readelf: Error... は表示されなくなるはず。

ご指定いただいた Linux カーネルドキュメント（LSM BPF Programs）に基づき、/sys/kernel/btf/vmlinux の役割と重要性について要約します。
このファイルは、一言で言うと「実行中のカーネルが持っているデータ構造（型）の設計図」です。

  1. eBPF プログラム開発の簡素化
    通常、カーネルの内部情報を扱うプログラム（eBPFなど）を書く場合、膨大なカーネルヘッダファイルをインクルードして、複雑な構造体の定義を一致させる必要があります。
    しかし、/sys/kernel/btf/vmlinux があれば、bpftool というツールを使って、そのカーネル専用の「すべての型定義が詰まったひとつのヘッダファイル（vmlinux.h）」を生成できます。 生成コマンドの例:
    bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h
    メリット: これをインクルードするだけで、カーネルヘッダを個別に用意しなくても、カーネル内部の構造体に直接アクセスできるようになります。

  2. CO-RE（一度のコンパイルでどこでも実行）の実現 Linux カーネルはバージョンによって構造体の内部（メンバの位置など）が変わることがあります。
    /sys/kernel/btf/vmlinux に含まれる BTF（BPF Type Format） 情報を使うことで、eBPF プログラムを実行時にその環境のカーネルに合わせて自動的に調整（リロケーション）できます。
    仕組み: プログラム側で「この構造体のこのフィールドが欲しい」と指定しておけば、実行時にカーネル側の BTF 情報を参照して、正しい位置（オフセット）を特定してくれます。

  3. セキュリティ（LSM）での活用
    ドキュメントの主旨である BPF LSM において、システム全体のセキュリティポリシー（ファイルのアクセス制限など）を動的に適用する際、この BTF 情報が不可欠です。
    カーネル内のフックポイント（処理の合間）で引数として渡される複雑なデータ構造を、安全かつ正確に解析するために、BTF による型情報が利用されます。

https://docs.kernel.org/6.15/bpf/prog_lsm.html

参考

👇MOKを使った検証についての説明
https://documentation.ubuntu.com/security/security-features/platform-protections/secure-boot/#machine-owner-keys-mok-management

👇ビルドしたドライバーをセキュアブート環境でもロードできるようにするやりかた

gihyo.jp

👇自前でビルド、インストールしたドライバーについて、カーネル更新時に自動でリビルドされるように DKMS(Dynamic Kernel Module Support) を適用するやりかた

gihyo.jp

👇Skipping BTF generation ... にでてくるBTFについての記事

atmarkit.itmedia.co.jp

かわりに謝罪してくれるエビフライ🍤「ワビエビ」

どうでもよいはなし

楽天モバイルを契約していると「楽天マガジンライト」なるサービスを追加料金無しで利用できるようになったようだ

magazine.rakuten.co.jp

そこでブルータスの特集が面白そうなのでダウンロードして読んだみた

brutus.jp

大人も知りたい、おもちゃのヒミツ。 No.1049 2026年3月2日 890円

いま、おもちゃから目が離せない。日本のトイメーカーは世界へ舞台を広げ、アニメや漫画に負けず劣らずファンを増やしている。 “キダルト”と呼ばれる大人向け玩具が市場を牽引し、その規模は年間1兆円を超えるほどに活況だ。デジタルやAIが発達してもなお、おもちゃは最高のエンターテインメントであり、作り手の情熱が注ぎ込まれたクリエイティブの塊だ。 なぜこうも、おもちゃに心惹かれるのか、子供も大人も虜（とりこ）にする、その答えを探る。

そこで紹介されていたのがこの「ワビエビ」だ

ワビエビ とは？

www.youtube.com

"ワビエビが代わって詫び入れいたします"

反射的に謝ることを防止し、コミュニケーションを円滑にするツールであるワビエビは、あなたの「すみません」に反応して健気に頭を下げる相棒です。 あなたと共に腰を曲げるその動きは、無意識の謝罪を可視化します。 「また言っちゃった」と客観視できるのでつい謝ってしまう癖を直す効果も期 待大。結果として、あなたが本当に頭を下げる頻度を減らし、コミュニケーシ ョンを円滑にしながら、心の重荷を軽くしてくれるのです。

武蔵野美術大学 視覚伝達デザイン学科の「トイデザイン」という講座にて加藤あゆみさんが作った作品。
面白いし、エビフライのやさしい感じがよいですね。

visual-communication.design

電子工作でつくろうとするとどうなる

あんまり知識がないのだけど調べてみた。
マイコンで作る前提で考えてみた。

謝罪に反応する部分

「ワビエビ」は実は結構ハイスペックで多言語に対応している。
以下のような音声認識モジュールを使えばよさそうだ。
これで複数言語の「ごめんなさい」を登録しておけばよさそう。

denshikit.main.jp

なおこれはあらかじめ登録した人の声にのみ反応する。
なのでまじめに作るとワビエビの『くんれんモード』が必要になる。結構めんどくさそうだ。

ちなみに不特定の人の声でも対応するモジュールもあるようだ。
この場合くんれんモードは要らなくなる。

簡単! UART音声認識組込モジュール Ver.3.0 https://www.amazon.co.jp/dp/B00DS6U9M2

本製品は、お好みの不特定話者認識フレーズ(カスタムSIフレーズ)を8個まで無償で登録して発送可能です。特定話者認識フレーズはお客様で自由に登録できますが、誰の声でも認識できるカスタムSIフレーズはあらかじめ内蔵のメモリーに語を当方で登録する必要があります。そのワードをご注文頂いた後にマイクロテクニカのwebサイトから申請して頂きますと、そのワードを書き込んで発送させて頂きます。

折れ曲がる部分

どう実現すればよいのだろうか。
似たような動きの魚のおもちゃは見つけた。
これはサーボモータを埋め込んでいるでいる模様。

www.youtube.com item.rakuten.co.jp

PCでの謝罪の文字に反応する部分

動画をみるとわかるがじつは「ワビエビ」はPC上にて謝罪の言葉を入力しても動作する。
（PCとワビエビはケーブルで接続されているようだった）
これはパソコン側になにか常駐の監視アプリ的なものを埋め込むしかないのかな。
AutoHotKeyあたりで実現したいけど日本語変換処理が入るから真面目にやるとめんどくさそうだ。

その他 参考情報

👇️オフライン音声認識ライブラリVOSKの紹介記事
日本語も対応しているがモデルサイズは軽量版でも50MBとマイコンで動かすには大きい。
ラズパイとかのSBCならこれでよいのかも。
zenn.dev

👇️オフライン音声認識モジュール Gravity の製品ページ
17のカスタム指示コマンドと1つのカスタムwake-upコマンド（OK, Google に相当する部分）を学習させることができる
www.dfrobot.com

ラベルプリンタのBleutoothプロトコル解析

自分でやったわけではなく、記事の紹介です

👇️Hackaday の紹介記事 hackaday.com

👇️元ネタ blog.dbuglife.com

  • Fichero というブランドの安いラベルプリンタ
  • Android印刷アプリはなんと26の権限を要求する
    • アプリはラベルプリンタ用SDK LuckPrinter で作られている。ガワをちょっと変えただけ。
      同じコードベースでレシート/A4熱感紙/産業用ラベルのプリンターが動作し4社のメーカーにわたる159機種以上をサポートする
  • いろいろ試行錯誤した結果 解析のとっかかりはAndroidアプリをデコンパイルして生成したソースコードから
  • プロトコル解析してブラウザやCLIから印刷できるようにしたよ

https://github.com/0xMH/fichero-printer?ref=blog.dbuglife.com

というお話。
解析で試行錯誤しているところも書いてくれていて面白い。そしてAndroidアプリが手がかりになる、というのは参考になった。
クローズドなプロトコルを解析する際の手がかりになるのでは、と思ったが解析に慣れている方からすれば常套手段なのかもしれない。

いっぽう Niimblue はカスタムフォントに対応していた

そういえば Niimblue （Niimbot製プリンタ非公式webアプリ） はどうなったかなと久しぶりに見に行ったらカスタムフォントに対応していた！
wikiの履歴をみると3週間前だ。すばらしい。

https://niim.blue/

実際に印刷してみると文字が潰れちゃっている。これは印刷前のプレビュー時の調整でなんとかなるかも。

フォントは 源暎きわみゴ (GenEi Kiwami Gothic) を使わせていただきました

okoneya.jp

マイコンをモバイルバッテリー給電で動かしたい

マイコンでなにか持ち運びできるようなものを作ったとして 電源をどうするかという問題がある。
リチウムイオン充電池はもう増やしたくないからモバイルバッテリー給電がいい。
ほぼ使っていないUSB PD非対応のものがあるし。

しかし昔のモバイルバッテリーの場合 マイコンを動かすぐらいの低電流ではオートパワーオフが動作してしまう場合があるようだ。
それを回避する製品がある。自作されているかたもいる。
日本語だと、モバイルバッテリー に続けて オートパワーオフキャンセラ や 低電流オフキャンセラ、ダミー負荷 などで検索すると出てくる。

どうも以下の2つの種類がありそうだ
電力消費量的には前者のほうが少ない

  • 周期的にパルスで瞬間的に負荷を与える方式（以降、パルス負荷方式とよぶ）
  • 定常的に一定の負荷を与える方式（以降、定常負荷方式とよぶ）

頒布、販売されているもの

キット（届いた部品を自分ではんだ付けする）や完成品についていくつかここにあげる。

👇️キットを頒布しているかたのサイト 【パルス負荷方式】
いくつか種類があって500円～850円。
NE555 というタイマICを使っている。
仕組みなどについて「トランジスタ技術 2025年5月号」に寄稿されているとのこと。あとで見てみよう。
www.jh4vaj.com

👇️ビット・トレード・ワンで最近発売されたもの。2000円くらい。【パルス負荷方式】
スリープジャマーという製品名。ジャマー系名称は初めてみたかも。
製品説明に「定期的に電流を間欠的に流す」と記載がある。
bit-trade-one.co.jp

👇️aitendo【どちらの方式か不明】
安い。300円くらい。しかし私が確認したときは在庫ステータスが「準備中」だった。
どちらの方式か不明。
これは入力側：USBタイプA、出力側：USBタイプCメスとなっている。
www.aitendo.com

👇️アリエクで見つけた製品【おそらく定常負荷方式】
Power Bank Virtual Load Anti-Shutdown Module
https://ja.aliexpress.com/item/1005010152799065.html
安い。レビューしてる人がほとんどいないがどうなのだろうか
LM317 というレギュレータを使用しているようだ。
使用部品を見る限り定常負荷方式かと思われる。

なお、英語で検索する場合は power bank anti poweroff とかででてくるはず。

自作は自分にはまだ厳しいので はんだ付け練習もかねてキットを購入する予定。

参考

👇️ATTiny85を使っている海外の方。回路の説明も詳細に書いてくれていてありがたい。パルス負荷方式。
https://k4icy.com/power_bank_auto_shutoff_disabler.html

タイマーIC 555 を使うものが多いがそれとの比較を以下のように述べている。
電子回路に詳しくない私にとっては ATTiny85 を使った回路はシンプルでわかりやすい。

さて、価格面では555がやや安価ですが差は1ドル程度です。この有名で広く普及しているタイマーICは同じパッケージとピン数のマイクロコントローラと比較するといくつかの欠点があります。
まず第一に555は非安定発振器を構成するために追加の部品（抵抗器、コンデンサ、ダイオードなど）を必要とします。
また555は単に充電・放電するコンデンサ・タンク回路を測定するコンパレータであるため各パルスの「マーク」と「スペース」つまりHIGHとLOW状態のタイミング調整が煩雑です。
確かに555は設定が容易でパルス間の待機電流も小さい。しかし表面実装パッケージのLMC555のような低電圧版タイマーICを入手しない限り標準555の動作範囲下限（4.5V）である5Vでは動作上の問題が生じる可能性がある。
もちろん555を使用する利点は入手容易さ、配線してすぐに動作する品質そしてArduino IDEとプログラマを用いたプログラミングが不要な点にあります。

👇️LM317 を使った定電流を流す回路を紹介してくれているサイト
これと同じようなことをアリエクのやつはやっているのだろう
kenkitami.tonosama.jp