はじめに
ほとんど使っていないSIE製nasne(CECH-ZNR2J)ですが、2027年7月には使い物にならなくなってしまう。

たまたま、Xで以下のリポジトリの情報が流れてきた。どうもnasneを普通のDebian Linuxサーバーとして動かせるようにしたプロジェクトで、mirakurunも動かせるらしいので、これを使って延命チャレンジしてみる。

環境
改造にはLinuxPCが必要とのこと。ただ、報告を読むとWSL2からもイケるっぽい。以下の記事でWSL2はセットアップ済みなので、これをそのまま使う。

ビルド環境の作成
まずは、WSL2を起動してGitリポジトリをクローンして、不足資源を確認するチェックプログラムを実行する。
【実行するコマンド】
git clone https://github.com/mar1mo-41414/SonyNasne-debian.git
cd SonyNasne-debian
python3 scripts/nasne_setup.py check【実行結果】
[OK] python3 このツール、.dlm の作成
[OK] curl GPLソース・公式ファームの取得
[OK] bzip2 カーネルソースの展開
[OK] tar
[OK] file ツリー作成時のバイナリ検査
[NG] docker ← apt: docker.io カーネルのビルド(古いgcc 4.3.2のコンテナ)
[NG] debootstrap ← apt: debootstrap Debian wheezy (mipsel) の作成
[NG] qemu-mipsel-static ← apt: qemu-user-static mipselのDebianをPC上で実行(debootstrapの第2段階)
[--] mipsel-linux-gnu-gcc ← apt: gcc-mipsel-linux-gnu MIPS用ツールのビルド(無ければDockerのgccで代用)
[NG] binfmt の qemu-mipsel が未登録 ← apt: binfmt-support(登録されない場合は update-binfmts --enable qemu-mipsel)
足りないもの(Debian/Ubuntu): sudo apt install binfmt-support debootstrap docker.io qemu-user-static足りないモノがあったので、追加でインストール必要があるとのこと。まずは、aptパッケージ一覧を更新した上で、不足する資源をインスコする。
【実行するコマンド】
sudo apt update
sudo apt install binfmt-support debootstrap docker.io qemu-user-binfmt終わったら、もう一度チェックする。
【実行するコマンド】
python3 scripts/nasne_setup.py check【実行結果】
-rwxr-xr-x 1 root root 4211448 Sep 2 18:18 /usr/bin/qemu-mipsel
/usr/bin/qemu-mipsel-static: cannot open `/usr/bin/qemu-mipsel-static' (No such file or directory)
enabled
interpreter /usr/bin/qemu-mipsel
flags: POF
offset 0
magic 7f454c46010101000000000000000000020008000100000000000000000000000000000000000000
mask ffffffffffffff0000fffffffffffffffeffffffffffffff00000000000000000000000020000000
[OK] python3 このツール、.dlm の作成
[OK] curl GPLソース・公式ファームの取得
[OK] bzip2 カーネルソースの展開
[OK] tar
[OK] file ツリー作成時のバイナリ検査
[OK] docker カーネルのビルド(古いgcc 4.3.2のコンテナ)
[OK] debootstrap Debian wheezy (mipsel) の作成
[NG] qemu-mipsel-static ← apt: qemu-user-static mipselのDebianをPC上で実行(debootstrapの第2段階)
[--] mipsel-linux-gnu-gcc ← apt: gcc-mipsel-linux-gnu MIPS用ツールのビルド(無ければDockerのgccで代用)
[NG] docker を実行できない(権限またはデーモン): permission denied while trying to connect to the docker API at unix:///var/run/docker.sock
足りないもの(Debian/Ubuntu): sudo apt install qemu-user-static
(dockerの権限: sudo usermod -aG docker $USER など) qemu-mipsel-staticがないと言われているが、新しいUbuntuだとファイル名が変わって/usr/bin/qemu-mipselにあるが、ツール側は古いファイルを探そうとして失敗しているらしい。
以下のコマンドを実行して/usr/local/binにコピーする。
【実行するコマンド】
sudo ln -s /usr/bin/qemu-mipsel /usr/local/bin/qemu-mipsel-staticあと、dockerの権限がないといわれているので、dockerグループに権限を付ける。
【実行するコマンド】
sudo usermod -aG docker $USERここまで来たら、WSL2を再起動する。WSL2をシャットダウンするには、管理者権限で起動したPowerShellでコマンドを叩く。
wsl --shutdown立ち上げ直したら、チェックプログラムを実行する。
【実行するコマンド】
cd ~/SonyNasne-debian
python3 scripts/nasne_setup.py check【実行結果】
docker OK
[OK] python3 このツール、.dlm の作成
[OK] curl GPLソース・公式ファームの取得
[OK] bzip2 カーネルソースの展開
[OK] tar
[OK] file ツリー作成時のバイナリ検査
[OK] docker カーネルのビルド(古いgcc 4.3.2のコンテナ)
[OK] debootstrap Debian wheezy (mipsel) の作成
[OK] qemu-mipsel-static mipselのDebianをPC上で実行(debootstrapの第2段階)
[--] mipsel-linux-gnu-gcc ← apt: gcc-mipsel-linux-gnu MIPS用ツールのビルド(無ければDockerのgccで代用)
必要なものはそろっています。ビルド
nasne用のRSA鍵を作る。途中でパスフレーズを求められるが、設定しても空欄のままでもどっちでもOK。
【実行するコマンド】
ssh-keygen -t rsa -b 4096 -f ~/.ssh/nasne_rsa作成したRSA鍵を使ってビルドを実行する。
【実行するコマンド】
cd ~/SonyNasne-debian
python3 scripts/nasne_setup.py build --download-official \
--ssh-pubkey ~/.ssh/nasne_rsa.pub --work build_nasne 2>&1 | tee build.log滝のようなログが流れた後、私の環境では以下の内容が出力されてビルドが止まってしまった。
Get:20 http://archive.debian.org/debian/ wheezy/main openssh-client mipsel 1:6.0p1-4+deb7u4 [979 kB]
Get:21 http://archive.debian.org/debian/ wheezy/main openssh-server mipsel 1:6.0p1-4+deb7u4 [318 kB]
Get:22 http://archive.debian.org/debian/ wheezy/main tcpd mipsel 7.6.q-24 [26.3 kB]
Get:23 http://archive.debian.org/debian/ wheezy/main xauth mipsel 1:1.0.7-1 [35.6 kB]
Preconfiguring packages ...
Fetched 9230 kB in 1s (7718 kB/s)
Can not write log, openpty() failed (/dev/pts not mounted?) Claudeにログを解析させたら、chroot内のapt-getがqemu経由で端末(今開いているWSLのウィンドウ)の設定を変えようとして、Linuxの端末制御によって一時停止させられたとのこと。ビルドは続きから出来るようなので、一度WSL2を立ち上げ直して、前回のビルドツリーを吹っ飛ばして、再ビルドさせる。
【実行するコマンド】
cd ~/SonyNasne-debian
sudo rm -rf build_nasne/tree
python3 scripts/nasne_setup.py build --download-official \
--ssh-pubkey ~/.ssh/nasne_rsa.pub --work build_nasne < /dev/null 2>&1 | tee build.log【実行結果】
== ステップ 1: 公式ファームパッケージ
/home/xxx/SonyNasne-debian/build_nasne/KRST3101_0260_SECURE.dlm (36119466 バイト)
== ステップ 2: カーネルのGPLソース(Sony公開)
展開済み
== ステップ 3: カーネル用ツールチェーン(Dockerイメージ nasne-kcc:gcc432。gcc 4.3.2 + binutils 2.19.1 をビルド。30分〜1時間)
イメージあり
== ステップ 4: 自作カーネルのビルド(直起動用の内蔵initramfs入り)
/home/xxx/SonyNasne-debian/gpl_src/build/out/vmlinux_new.bin あり
== ステップ 5: KNLセグメント(公式のKNLを雛形に、自作カーネルを包む)
$ /usr/bin/python3 /home/xxx/SonyNasne-debian/scripts/build_knl.py verify /home/xxx/SonyNasne-debian/build_nasne/knl_new.bin
== ステップ 6: Debian wheezy (mipsel) のツリー(debootstrap。数分)
$ sudo /home/xxx/SonyNasne-debian/scripts/stage1/prepare_tree.sh --out /home/xxx/SonyNasne-debian/build_nasne/tree --knl /home/xxx/SonyNasne-debian/build_nasne/knl_new.bin --official /home/xxx/SonyNasne-debian/build_nasne/KRST3101_0260_SECURE.dlm --ssh-pubkey /home/xxx/.ssh/nasne_rsa.pub
$ sudo tar --numeric-owner -cpf /home/xxx/SonyNasne-debian/build_nasne/debian_tree.tar -C /home/xxx/SonyNasne-debian/build_nasne/tree .
$ sudo chown 1000:1000 /home/xxx/SonyNasne-debian/build_nasne/debian_tree.tar
== ステップ 7: 00550066.dlm の作成
--hdd-dlm が無いので、ここで止めます。ビルドは完了しています。HDDの00550066.dlmを用意して、もう一度 build を実行してください(以前のステップは飛ばされます)。ビルドかんりょ~
SPIのバックアップ
nasneをバラして、HDDをPCに接続する。
もし、フォーマット確認が出ても、絶対絶対ぜ~ったいにキャンセルする。
PowerShellを管理者権限で立ち上げて、以下のコマンドを実行してHDDの制御をWSL2に渡す。
【実行するコマンド】
PCにつながっているストレージ一覧が出る。モデル名やサイズからnasneのHDDのDeviceIDを調べる。
Get-CimInstance -Query "SELECT * from Win32_DiskDrive" | Select-Object DeviceID, Model, Size【実行結果】
DeviceID Model Size
-------- ----- ----
\\.\PHYSICALDRIVE5 HGST HTS 541010A9E680 USB Device 1000202273280続けて、PowerShellで以下のコマンドを入力して、実際に制御をWSL2に渡す。今回はDeviceIDが5なので以下のコマンドになっているが、環境によって数字は異なるので読み替えること。
【実行するコマンド】
wsl --mount \\.\PHYSICALDRIVE5 --bareこの操作を正しく終了しました、と表示されればOK
ここからは、WSL2に戻ってHDDが認識されているか確認する。
【実行するコマンド】
lsblk -o NAME,SIZE,FSTYPE,LABEL【実行結果】
NAME SIZE FSTYPE LABEL
sda 356.9M ext4
sdb 159.4M ext4
sdc 48.8G swap
sdd 1T ext4
sde 931.5G
├─sde1 256M ext3 sys1
├─sde2 1G ext3 sys2
└─sde3 930.3G xfs user sdeで認識された(ここも環境によって何番で出るかは変わる)。
sys1をマウントして、中身を確認する。
【実行するコマンド】
cd ~/SonyNasne-debian
sudo mkdir -p /mnt/nasne_sys1
sudo mount /dev/sde1 /mnt/nasne_sys1
findmnt /mnt/nasne_sys1
ls -la /mnt/nasne_sys1
df -h /mnt/nasne_sys1【実行結果】
TARGET SOURCE FSTYPE OPTIONS
/mnt/nasne_sys1 /dev/sde1 ext3 rw,relatime,stripe=4
total 31047
drwxr-xr-x 5 root root 1024 Jan 1 1970 .
drwxr-xr-x 10 root root 4096 Oct 28 03:17 ..
-rw-r--r-- 1 root root 148 Apr 28 2018 00110022.dlm
-rwxr-xr-x 1 root root 31646110 Apr 28 2018 00550066.dlm
drwx------ 2 root root 1024 Apr 28 2018 11002200
drwx------ 2 root root 1024 May 20 2017 33004400
drwx------ 2 root root 12288 Jul 26 2013 lost+found
Filesystem Size Used Avail Use% Mounted on
/dev/sde1 238M 100M 126M 45% /mnt/nasne_sys1オリジナルの00550066.dlmをバックアップしておく。念のため、WindowsのCドライブにもC:\nasne_backupにコピーしておく。
【実行するコマンド】
mkdir -p backup
cp /mnt/nasne_sys1/00550066.dlm backup/00550066.dlm.orig
sha256sum /mnt/nasne_sys1/00550066.dlm backup/00550066.dlm.orig
mkdir -p /mnt/c/nasne_backup
cp backup/00550066.dlm.orig /mnt/c/nasne_backup/【実行結果】
オリジナルとバックアップのsha256が一致していることを確認する
39a3a436bace9c3fa4a252a9272cf5715afb6e0b3af695c76d73050aa22014c8 /mnt/nasne_sys1/00550066.dlm
39a3a436bace9c3fa4a252a9272cf5715afb6e0b3af695c76d73050aa22014c8 backup/00550066.dlm.orig SPIバックアップ版の.dlmを作る
【実行するコマンド】
python3 scripts/stage1/make_stage1_dlm.py build --official backup/00550066.dlm.orig \
--out spi_backup.dlm --mode backup【実行結果】
公式rootfs: tar 86026240 bytes、ヘッダ date='Tue Oct 24 11:13:25 2017\x00\x00\x00\x00\x00\x00\x00\x00' +8(major)=2
rcS のエントリ: 2個(最後の #474 を差し替える)
新しいボディ: 31605881 bytes (31.6MB) 公式のエントリ数 1289
spi_backup.dlm: 31605945 bytes 自己検証=OK flag=0 crc=True
読み戻し検証OK: エントリ 1289(元 1289)、rcS 差し替え済み、mode=backupsys1へ差し替えを行う。
【実行するコマンド】
sudo bash scripts/stage1/install_dlm.sh /mnt/nasne_sys1 spi_backup.dlm --backup-dir ./backup_sys1
ls -la /mnt/nasne_sys1
sync
sudo umount /mnt/nasne_sys1【実行結果】
検査OK: hwtype・日付が一致、CRC OK
退避: ./backup_sys1/00550066.dlm.orig
書き込み完了: /mnt/nasne_sys1/00550066.dlm
/dev/sde1 238M 100M 126M 45% /mnt/nasne_sys1
total 31008
drwxr-xr-x 5 root root 1024 Oct 28 03:24 .
drwxr-xr-x 10 root root 4096 Oct 28 03:17 ..
-rw-r--r-- 1 root root 148 Apr 28 2018 00110022.dlm
-rw-r--r-- 1 root root 31605945 Oct 28 03:24 00550066.dlm
drwx------ 2 root root 1024 Apr 28 2018 11002200
drwx------ 2 root root 1024 May 20 2017 33004400
drwx------ 2 root root 12288 Jul 26 2013 lost+found管理者権限のPowerShellからHDD取り出しコマンドを叩く。IDは読み替えること。
【実行するコマンド】
wsl --unmount \\.\PHYSICALDRIVE5 ここまで来たら、nasneの基板にHDDをつないで起動するか確認する。nasneが起動すれば差し替えた.dlmによって、nasne自身がSPIの中身をHDDのsys1/spi_backupに書き出しているはず。
問題なければまたPCにHDDをつなぎ直す。
管理者権限のPowerShellで以下のコマンドを叩いてHDDのDeviceIDを調べる。
【実行するコマンド】
Get-CimInstance -Query "SELECT * from Win32_DiskDrive" | Select-Object DeviceID, Model, Size続けて、またWSL2にHDDを渡す。DriveIDは読み替えること。
【実行するコマンド】
wsl --mount \\.\PHYSICALDRIVE5 --bareWSL2に戻って、以下のコマンドを叩いてドライブ構成を確認する。
【実行するコマンド】
cd ~/SonyNasne-debian
lsblk -o NAME,SIZE,FSTYPE,LABEL【実行結果】
NAME SIZE FSTYPE LABEL
sda 356.9M ext4
sdb 159.4M ext4
sdc 48.8G swap
sdd 1T ext4
sde 931.5G
├─sde1 256M ext3 sys1
├─sde2 1G ext3 sys2
└─sde3 930.3G xfs userバックアップをPCにコピーする。
【実行するコマンド】
mkdir -p backup/spi_backup
cp -a /mnt/nasne_sys1/spi_backup/. backup/spi_backup/
cp -r backup/spi_backup /mnt/c/nasne_backup/
sha256sum backup/spi_backup/spi_mtd0.bin /mnt/c/nasne_backup/spi_backup/spi_mtd0.bin【実行結果】
total 16392
drwxr-xr-x 2 root root 1024 Jan 1 1970 .
drwxr-xr-x 6 root root 1024 Jan 1 1970 ..
-rw-r--r-- 1 root root 97 Jan 1 1970 MD5SUMS
-rw-r--r-- 1 root root 440 Jan 1 1970 README.txt
-rw-r--r-- 1 root root 113 Jan 1 1970 SHA1SUMS
-rw-r--r-- 1 root root 500 Jan 1 1970 backup.log
-rw-r--r-- 1 root root 13631488 Jan 1 1970 spi_mtd0.bin
-rw-r--r-- 1 root root 3080192 Jan 1 1970 spi_mtd1_nv.bin
1970-01-01 09:00:27 SPIバックアップ開始 (保存先: sys1)
1970-01-01 09:00:27 mtd0=13631488 mtd1=3080192 (/proc/mtd)
1970-01-01 09:00:27 sys1 をマウント: /dev/sda1 -> /mnt/bk_sys1
1970-01-01 09:00:27 mtd0 を読み出す(2回読んで比較)
208+0 records in
208+0 records out
1970-01-01 09:01:35 mtd0 結果 rc=0
1970-01-01 09:01:35 mtd1(NV領域)を読み出す(稼働中のjffs2なので2回目の比較は参考)
47+0 records in
47+0 records out
1970-01-01 09:01:50 mtd1 結果 rc=0
spi_mtd0.bin: OK
spi_mtd1_nv.bin: OK
spi_mtd0.bin: OK
spi_mtd1_nv.bin: OK【実行するコマンド】
mkdir -p backup/spi_backup
cp -a /mnt/nasne_sys1/spi_backup/. backup/spi_backup/
cp -r backup/spi_backup /mnt/c/nasne_backup/
sha256sum backup/spi_backup/spi_mtd0.bin /mnt/c/nasne_backup/spi_backup/spi_mtd0.bin【実行結果】
6e4f32ddd01dc5019fcca017d2d8cf4eb966fb424121fc792b6b132d9bf180ca backup/spi_backup/spi_mtd0.bin
6e4f32ddd01dc5019fcca017d2d8cf4eb966fb424121fc792b6b132d9bf180ca /mnt/c/nasne_backup/spi_backup/spi_mtd0.binsha256が一致していればOK。
録画を残す方式では、XFSの中に8GBのイメージファイルを作るとのことで空き容量を確認する。
ただ、nasneのフォーマット形式(Deprecated V4 format)から読み取るためにxfsprogsをWSL2にインスコ・容量を抽出する。
【実行するコマンド】
sudo apt install xfsprogs
sudo xfs_db -r -c "sb 0" -c "print blocksize fdblocks" /dev/sde3【実行結果】
blocksize = 4096
fdblocks = 71878052空き容量は以下のコマンドでGB単位に換算できる。
【実行するコマンド】
sudo xfs_db -r -c "sb 0" -c "print blocksize fdblocks" /dev/sde3 \
| awk -F' = ' '{v[$1]=$2} END {printf "空き: %.1f GB\n", v["blocksize"]*v["fdblocks"]/1e9}'【実行結果】
空き: 294.4 GBDebian版の.dlmを作る
ここから本格的に改造していく。まずはDebian版の.dlmを作る。
【実行するコマンド】
python3 scripts/nasne_setup.py build --download-official \
--hdd-dlm backup/00550066.dlm.orig --ssh-pubkey ~/.ssh/nasne_rsa.pub \
--work build_nasne --telnet fail < /dev/null 2>&1 | tee build2.log【実行結果】
公式rootfs: tar 86026240 bytes、ヘッダ date='Tue Oct 24 11:13:25 2017\x00\x00\x00\x00\x00\x00\x00\x00' +8(major)=2
rcS のエントリ: 2個(最後の #474 を差し替える)
同梱したDebianのエントリ数: 9388
新しいボディ: 93938124 bytes (93.9MB) 公式のエントリ数 1289
/home/xxx/SonyNasne-debian/build_nasne/custom_00550066.dlm: 93938188 bytes 自己検証=OK flag=0 crc=True
読み戻し検証OK: エントリ 10678(元 1289)、rcS 差し替え済み、mode=embed
== ステップ 1: 公式ファームパッケージ
/home/xxx/SonyNasne-debian/build_nasne/KRST3101_0260_SECURE.dlm (36119466 バイト)
== ステップ 2: カーネルのGPLソース(Sony公開)
展開済み
== ステップ 3: カーネル用ツールチェーン(Dockerイメージ nasne-kcc:gcc432。gcc 4.3.2 + binutils 2.19.1 をビルド。30分〜1時間)
イメージあり
== ステップ 4: 自作カーネルのビルド(直起動用の内蔵initramfs入り)
/home/xxx/SonyNasne-debian/gpl_src/build/out/vmlinux_new.bin あり
== ステップ 5: KNLセグメント(公式のKNLを雛形に、自作カーネルを包む)
$ /usr/bin/python3 /home/xxx/SonyNasne-debian/scripts/build_knl.py verify /home/xxx/SonyNasne-debian/build_nasne/knl_new.bin
== ステップ 6: Debian wheezy (mipsel) のツリー(debootstrap。数分)
/home/xxx/SonyNasne-debian/build_nasne/debian_tree.tar あり
== ステップ 7: 00550066.dlm の作成
$ /usr/bin/python3 /home/xxx/SonyNasne-debian/scripts/stage1/make_stage1_dlm.py build --official /home/xxx/SonyNasne-debian/backup/00550066.dlm.orig --out /home/xxx/SonyNasne-debian/build_nasne/custom_00550066.dlm --mode embed --image-size 8G --telnet fail --debian-tree-tar /home/xxx/SonyNasne-debian/build_nasne/debian_tree.tar
完了: /home/xxx/SonyNasne-debian/build_nasne/custom_00550066.dlm
次はHDDに入れます(HDDをPCにつなぐ。sdX は lsblk で必ず確認):
sudo mkdir -p /mnt/nasne_sys1 && sudo mount /dev/sdX1 /mnt/nasne_sys1
mkdir -p backup && cp /mnt/nasne_sys1/00550066.dlm backup/00550066.dlm.orig # 元に戻す手段
sudo bash /home/xxx/SonyNasne-debian/scripts/stage1/install_dlm.sh /mnt/nasne_sys1 /home/xxx/SonyNasne-debian/build_nasne/custom_00550066.dlm --backup-dir backup
sudo umount /mnt/nasne_sys1
その後、HDDを nasne に挿して電源を入れ、約5分待ちます(docs/13)。事前に SPI のバックアップ(docs/16)を取っておくことを強くお勧めします。改造した.dlmをsys1に入れる前に空き容量を確認する。新しい.dlmは約94MBなので、それ以上の空きがあるか確認。
【実行するコマンド】
df -h /mnt/nasne_sys1【実行結果】
Filesystem Size Used Avail Use% Mounted on
/dev/sde1 238M 116M 110M 52% /mnt/nasne_sys1110MB空いていたのでOK。
実際に.dlmを差し替えてアンマウントする。
【コマンド】
sudo bash scripts/stage1/install_dlm.sh /mnt/nasne_sys1 build_nasne/custom_00550066.dlm --backup-dir ./backup_sys1_stage2
ls -la /mnt/nasne_sys1
sync
sudo umount /mnt/nasne_sys1【実行結果】
検査OK: hwtype・日付が一致、CRC OK
退避: ./backup_sys1_stage2/00550066.dlm.orig
書き込み完了: /mnt/nasne_sys1/00550066.dlm
/dev/sde1 238M 175M 51M 78% /mnt/nasne_sys1
total 92120
drwxr-xr-x 6 root root 1024 Oct 28 04:05 .
drwxr-xr-x 11 root root 4096 Oct 28 03:57 ..
-rw-r--r-- 1 root root 148 Apr 28 2018 00110022.dlm
-rw-r--r-- 1 root root 93938188 Oct 28 04:05 00550066.dlm
drwx------ 2 root root 1024 Apr 28 2018 11002200
drwx------ 2 root root 1024 May 20 2017 33004400
drwx------ 2 root root 12288 Jul 26 2013 lost+found
drwxr-xr-x 2 root root 1024 Jan 1 1970 spi_backup管理者権限のPowerShellでHDDをアンマウントする。DriveIDは(ry
wsl --unmount \\.\PHYSICALDRIVE5nasneにHDDをつないで起動する。この時、SPIカーネル領域の書き換えが行われるので絶対に電源を切らないこと。大体、書き換えは5分程度かかる。
| 時間 | 処理 |
|---|---|
| ~1分 | 公式カーネルで起動 |
| ~3分 | p3にDebianのイメージを作成・展開 |
| ~4分 | SPIの全体をバックアップし、カーネル領域を書き換えて再起動 |
| ~5分 | 改造したカーネルでDebianが起動し、SSHが拓く |
改造に成功したか確認
WSL2からSSHを叩いて、起動したか確認する。
IPアドレスは読み替えること。
【実行するコマンド】
ssh -i ~/.ssh/nasne_rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa root@192.168.100.xx【実行結果】
The authenticity of host '192.168.100.xx (192.168.100.xx)' can't be established.
ECDSA key fingerprint is: SHA256:v/3+0ie5b0sISn8uV93ZfEmWYAbSZB6TIj6pdWDU26Y
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? こんな感じになればsshdが応答しているので、Debianは起動している。初回接続時に必ず出る確認が末尾にあり、ここはyesと入力してEnterを押す。
もう一度同じコマンドを叩いて、nasneのSSHに接続する。
【実行するコマンド】
ssh -i ~/.ssh/nasne_rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa root@192.168.100.xx【実行結果】
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
Linux nasne-debian 2.6.29-ts-mipsisa32r2el #1 Tue Oct 27 17:32:03 UTC 2026 mips
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@nasne-debian:~#続けて以下のコマンドを1行ずつ入力する。
【実行するコマンド】
uname -a
tail -5 /var/log/nasne-stage1.log
cat /var/log/nasne-mcu-wd.log【実行結果】
root@nasne-debian:~# uname -a
Linux nasne-debian 2.6.29-ts-mipsisa32r2el #1 Tue Oct 27 17:32:03 UTC 2026 mips GNU/Linux
root@nasne-debian:~# tail -5 /var/log/nasne-stage1.log
erased 00100000+00210000
wrote 00207368 bytes at 00100000
verify OK 00207368 bytes at 00100000
1970-01-01 00:03:22 flash + verify OK
1970-01-01 00:03:22 rebooting into the new kernel
root@nasne-debian:~# cat /var/log/nasne-mcu-wd.log
== Thu Jan 1 00:02:09 UTC 1970 start
mcui2c write addr8=20 n=02 ioctl=01 return_value=01 (COMPLETE)
MCU watchdog disabled
mcui2c write addr8=20 n=02 ioctl=01 return_value=01 (COMPLETE)
PWR LED on (code 0x32)
== Thu Jan 1 00:00:19 UTC 1970 start
Found module file xcode4drv.ko
Loaded xcode4 driver module xcode4drv
Created directory /dev/vixs
Created device node /dev/vixs/xcodedrv
Done! Enjoy!
mcui2c write addr8=20 n=02 ioctl=01 return_value=01 (COMPLETE)
MCU watchdog disabled
mcui2c write addr8=20 n=02 ioctl=01 return_value=01 (COMPLETE)
PWR LED on (code 0x32)
root@nasne-debian:~#テレビを試す
テレビ局スキャン
ブラウザで以下のURLを入力する。IPアドレスは読み替え。
http://192.168.100.xx:8301/scan以下のような感じで、チャンネルがスキャンされる。
ch=27 freq=557142kHz sid=0x400(tv) name="NHK総合1・東京" sid=0x401(tv) name="NHK総合2・東京" sid=0x580(1seg) name="NHK携帯G・東京" sid=0xfff0(data)テレビを見る(VLC)
ネットワークストリームに以下を入力する。IPアドレスは読み替え。
http://192.168.100.xx:8301/playlist.m3u8純正アプリを使う場合
SSHで以下のコマンドを叩いて再起動すると、次回だけ公式アプリで起動する。電源を入れ直すとDebianで起動する。
nasne-boot-switch official-onceおまけ mirakurun+KonomiTVの視聴環境を構築する
mirakurun
nasne側でチャンネル設定を作る
WSL2で以下のコマンドを実行して、チャンネル設定を作る。BS/CSもスキャンするなら、–scanの前に–satを追加する。
【実行するコマンド】
cd ~/SonyNasne-debian
mkdir -p mirakurun-conf
python3 scripts/nasne_mirakurun_conf.py 192.168.100.xx --scan -o mirakurun-conf
cat mirakurun-conf/channels.yml | head -30【実行結果】
スキャン中(約80秒)...
mirakurun-conf/tuners.yml と channels.yml を書きました(サービス 36 件: GR 36 件, BS 0 件, CS 0 件)Synology NASにmirakurunをインストールする
dockerフォルダ内にmirakurunフォルダを作成する。さらにその中にconfとdataフォルダを作る。
mirakurun\confの中に、WSL2の\wsl$\Ubuntu\home\UserName\SonyNasne-debian\mirakurun-conf内のデータをコピーする。
Container Managerでプロジェクトを作成する。
プロジェクト名:mirakurun
パス:\docker\mirakurun
ソース:docker-compose.ymlを作成で、以下のコードを貼り付ける。
services:
mirakurun:
image: chinachu/mirakurun:latest
container_name: mirakurun
cap_add:
- SYS_ADMIN
- SYS_NICE
ports:
- "40772:40772"
volumes:
- ./conf:/app-config
- ./data:/app-data
environment:
TZ: Asia/Tokyo
restart: unless-stoppedconfフォルダには、前段のWSL2で作成した「channels.yml」と「tuners.yml」を格納する。
Synologyでmirakurunコンテナを起動し、ブラウザで、http://<NASのIP>:40772/ を開くと、MirakurunのWeb画面が表示される。
ここからめっちゃハマったが、ジョブを確認すると「Service Add Check GR/xxx」が失敗しまくって、チューナー側のドライバがフリーズする。1個も成功しない。
nasneのログを見ると、Mirakurunからの要求は届いていて、約1秒で映像も流れ始め、20秒後にMirakurun側から切断されていた。
Mirakurunのソースを確認したところ、20秒以内に次の3つがそろわないとエラーになるようだった。
①PAT(番組の一覧)に、NIT(ネットワーク情報)の場所が書かれていること
②NITが届くこと
③SDT(局名などの情報)が届き、その中の TSID(放送波の番号)がPATのTSIDと一致すること
nasneのストリームは、局を指定(?sid=)されると、チップが作り直した簡易版のPATを送っている。このPATのTSIDがSDTと食い違っており、MirakurunはSDTを無視するために、上の③が永久に合致しないため、全局の情報取得に延々と失敗していた。
以下の、PATを修正するパッチを作成して、confフォルダに入れてあげる。
// nasne の TS を受け取り、PAT の NIT の PID を 0x10 に直して標準出力へ流す(Mirakurun の tuners.yml から呼ぶ)
// 使い方: node /app-config/nasne-fix.js http://<nasne>:8301/tuner/<channel><sid_query>
// 動作の記録: /app-config/nasne-fix.log(1MBを超えたら作り直す)
const http = require('http');
const fs = require('fs');
const LOG = '/app-config/nasne-fix.log';
const url = process.argv[2];
const t0 = Date.now();
let bytes = 0, pats = 0, fixed = 0, status = '-';
function log(msg) {
try {
if (fs.existsSync(LOG) && fs.statSync(LOG).size > 1048576) fs.truncateSync(LOG, 0);
fs.appendFileSync(LOG, new Date().toISOString() + ' pid=' + process.pid + ' ' + msg + '\n');
} catch (e) { /* 記録できなくても配信は続ける */ }
}
function finish(code, why) {
log('exit=' + code + ' reason=' + why + ' status=' + status + ' bytes=' + bytes + ' pats=' + pats + ' fixed=' + fixed + ' ms=' + (Date.now() - t0) + ' url=' + url);
process.exit(code);
}
const T = new Uint32Array(256);
for (let i = 0; i < 256; i++) { let c = i << 24; for (let k = 0; k < 8; k++) c = (c & 0x80000000) ? ((c << 1) ^ 0x04C11DB7) : (c << 1); T[i] = c >>> 0; }
function crc32(b, s, e) { let c = 0xFFFFFFFF; for (let i = s; i < e; i++) c = ((c << 8) ^ T[((c >>> 24) ^ b[i]) & 0xff]) >>> 0; return c >>> 0; }
function fix(p) {
if (p[0] !== 0x47 || (p[1] & 0x1f) !== 0 || p[2] !== 0 || !(p[1] & 0x40) || !(p[3] & 0x10)) return;
let off = 4; if (p[3] & 0x20) off += 1 + p[4];
off += 1 + p[off];
if (off + 8 > 188 || p[off] !== 0x00) return;
const end = off + 3 + (((p[off + 1] & 0x0f) << 8) | p[off + 2]);
if (end > 188) return;
pats++;
let changed = false;
for (let j = off + 8; j + 4 <= end - 4; j += 4) {
if (p[j] === 0 && p[j + 1] === 0 && (((p[j + 2] & 0x1f) << 8) | p[j + 3]) !== 0x10) {
p[j + 2] = 0xe0; p[j + 3] = 0x10; changed = true;
}
}
if (changed) { p.writeUInt32BE(crc32(p, off, end - 4), end - 4); fixed++; }
}
module.exports = { fix, crc32 };
if (require.main === module) {
process.on('SIGTERM', () => finish(0, 'SIGTERM(Mirakurunが終了を指示)'));
process.on('uncaughtException', e => finish(1, 'exception:' + (e && e.stack || e)));
process.stdout.on('error', e => finish(0, 'stdout-error:' + e.code));
let rest = Buffer.alloc(0);
log('start url=' + url);
const req = http.get(url, res => {
status = String(res.statusCode);
if (res.statusCode !== 200) {
let body = '';
res.on('data', d => { if (body.length < 200) body += d.toString(); });
res.on('end', () => finish(1, 'http-status body=' + JSON.stringify(body.trim())));
return;
}
res.on('data', chunk => {
bytes += chunk.length;
const buf = rest.length ? Buffer.concat([rest, chunk]) : chunk;
let i = 0; while (i < buf.length && buf[i] !== 0x47) i++;
const n = Math.floor((buf.length - i) / 188) * 188;
for (let k = i; k < i + n; k += 188) fix(buf.subarray(k, k + 188));
if (n) process.stdout.write(buf.subarray(i, i + n));
rest = Buffer.from(buf.subarray(i + n));
});
res.on('end', () => finish(0, 'stream-end'));
res.on('aborted', () => finish(1, 'stream-aborted'));
});
req.on('error', e => finish(1, 'request-error:' + e.code + ' ' + e.message));
}
また、tuners.ymlの内容を以下の内容に書き換える。
- name: nasne
types:
- GR
command: node /app-config/nasne-fix.js http://192.168.100.xxx:8301/tuner/<channel><sid_query>
isDisabled: falseこれでようやくmirakurunでEPGの取得ができるようになった。
EPGStation
録画できるように、EPGStationをインストールしていく。
EPGStationの設定ファイルを作成
WSL2で以下のコマンドをを実行する。
mkdir -p ~/epgstation-config && cd ~/epgstation-config
docker create --name tmp-epg l3tnun/epgstation:master-debian
docker cp tmp-epg:/app/config/. . && docker rm tmp-epg
cp config.yml.template config.yml && cp enc.js.template enc.js
cp operatorLogConfig.sample.yml operatorLogConfig.yml
cp serviceLogConfig.sample.yml serviceLogConfig.yml
cp epgUpdaterLogConfig.sample.yml epgUpdaterLogConfig.yml
sed -i 's#^mirakurunPath:.*#mirakurunPath: http://mirakurun:40772/#' config.yml
grep mirakurunPath config.yml以下の内容が出力されればOK。
mirakurunPath: http://mirakurun:40772/Synology NASにEPGStationの設定ファイルを配置
docker/mirakurunの中に「epgstation」と「epgstation-build」フォルダを作成する。epgstationの中に「config」「data」「recorded」「thumbnail」「logs」フォルダを作成する。
WSL2の「\wsl$\Ubuntu\home\USERNAME\epgstation-config」の中身を、すべてconfigフォルダにコピーする。
epgstation-buildフォルダの中には、以下のファイルを作成する。拡張子は「なし」。
FROM l3tnun/epgstation:master-debian
RUN apt-get update \
&& apt-get install -y --no-install-recommends ffmpeg \
&& ln -sf /usr/bin/ffmpeg /usr/local/bin/ffmpeg \
&& ln -sf /usr/bin/ffprobe /usr/local/bin/ffprobe \
&& rm -rf /var/lib/apt/lists/*ContainerManagerのプロジェクト→mirakurunを開き、プロジェクトを停止する。そしてYAMLを以下の内容に編集する。
services:
mirakurun:
image: chinachu/mirakurun:latest
container_name: mirakurun
cap_add:
- SYS_ADMIN
- SYS_NICE
ports:
- "40772:40772"
volumes:
- ./conf:/app-config
- ./data:/app-data
environment:
TZ: Asia/Tokyo
restart: unless-stopped
epgstation:
build: ./epgstation-build
image: epgstation-ffmpeg:local
container_name: epgstation
ports:
- "8888:8888"
volumes:
- ./epgstation/config:/app/config
- ./epgstation/data:/app/data
- ./epgstation/recorded:/app/recorded
- ./epgstation/thumbnail:/app/thumbnail
- ./epgstation/logs:/app/logs
environment:
TZ: Asia/Tokyo
depends_on:
- mirakurun
restart: unless-stopped保存して、プロジェクトを再構築・起動する。
ブラウザから「http://NASのIPアドレス:8888」にアクセスすれば、EPGStationにアクセスでき、録画予約などできるようになる。
KonomiTVのインストール

Releaseページからインストーラを落として、指示通りに操作するだけ。

コメント