0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kaz32

Qua Station(RTD1295)をClaude CodeでUbuntu 26.04＋mainline Linux 6.18導入記録（3）SSD移行編

0
Last updated at Posted at 2026-09-21

(1)(2)では、シリアルコンソール無しでの診断手法と、SATA/PCIe/Wi-Fi/LEDといったハードウェアを1つずつ復活させる過程を書きました。本編では、当初からの最終ゴールだったrootfsを内蔵SSDへ移す作業を扱います。

⚠️ 先に注記しておくと、USBメモリは今も外せません。U-Bootのブートコマンドが常にUSBのBOOTパーティションからuImage/DTBを読む固定仕様で、SATA上のパーティションからは直接カーネルを起動できないためです。今回動いたのは「rootfs(OS本体)がUSBからSSDへ移った」ことで、カーネル/DTBの読み込み元(BOOT)はUSBのまま、という構成です。それでもUSBメモリの耐久性・速度がボトルネックだったrootfs側がSSDになる意味は大きく、ここでプロジェクトは一区切りを迎えます。

USB起動で使っていたUbuntuイメージについて

ここまでの(1)(2)で動作確認してきたUbuntu環境がどこから来たものか、改めて書いておきます。同じ機種で試す人が再現できるように、序盤に必要な情報だと考えたためです。

  • ベースイメージ: ISOでもクラウドイメージでもなく、公式のUbuntu Base（ubuntu-base-24.04.5-base-arm64、cdimage.ubuntu.comで配布されているchroot構築用の最小rootfs tarball）を使いました
  • 26.04への移行: QuaStation実機上の作業ディレクトリにchroot環境を作り、その中で26.04系のプロビジョニングを実施。できあがったrootfsをrootfs26-qua618.tar.gzとしてtar化しています
  • USBメモリへの書き込み: ddでディスク全体を複製する方式は実際にUSBメモリを1本壊しました（syncが18分以上固まった末にI/O error）。以後はsfdiskでパーティションテーブルだけを複製し、BOOTパーティションはcatでイメージを流し込み、rootfsパーティションはtarで展開する方式に切り替えています。書き込み後はddを使わずcmpで内容を照合しました
  • 起動方法: U-Bootのfatloadコマンドで、USBメモリのBOOTパーティションからカーネルImageとDTBを読み込む方式です。4.9側のbootcmdをそのまま流用し、ロードするファイル名だけ切り替えています

rootfsのSSD移行 — 「モジュール化」が引き起こす循環デッドロック

USB起動でハードウェアが一通り動くようになった後、いよいよ本来のゴールであるrootfsの内蔵SSDへの移行に取り組みました。

やったこと

  1. 4.9本番用パーティション(sdb2, 100GB)を50GBに縮小し、新規にsdb4(50GB, PARTUUID=20a83e9c-04)を作成（4.9本番データは無傷のまま）
  2. USB上で動いていたUbuntu 26.04のrootfsをsdb4へrsyncでコピー
  3. fstabの参照先を旧PARTUUID(dcef5c15-03)から新PARTUUID(20a83e9c-04)へ書き換え

つまずいたポイント: SATAディスクが永遠に出現しない

再起動してroot=PARTUUID=20a83e9c-04を待たせても、60秒待ってもsdbディスクが出現せず起動に失敗しました。

原因は.configの1行でした。

CONFIG_PHY_RTK_RTD_SATAPHY=m   # モジュール

SATA PHYドライバがモジュールになっていたため、rootfsをマウントした後でなければロードできません。しかし今回rootfsを置く先はまさにそのSATAディスクの上です。つまり「SATAを使うにはrootfsが必要、rootfsを読むにはSATAが必要」という循環デッドロックに陥っていました。USB起動の時はrootfsがUSB側にあったため表面化しなかった問題です。

対処は単純で、この1行を組み込み化するだけでした。

CONFIG_PHY_RTK_RTD_SATAPHY=y   # 組み込み

再ビルド・再起動すると、

[qua-init] root=/dev/sdb4 (partuuid=20a83e9c-04) after 3s

60秒待っても出なかったものが3秒で解決しました。findmnt /が/dev/sdb4を指し、旧環境(4.9側のsdb2)への参照がfstab・mount・cron・systemdユニットのどこにも残っていないことも確認しました。ただし前述の通り、カーネル/DTB自体は引き続きUSB(sda)側のBOOTパーティションから読み込む構成です。

教訓: 「ブートに必要なストレージコントローラのドライバは、そのストレージ自体をrootにする場合は必ず組み込みにする」という、初期ramdisk(initrd/initramfs)を使わない構成では基本的な注意点ですが、USB起動で動作確認していた時は問題が隠れていた、という点が今回の落とし穴でした。

おわりに

USB起動でのハードウェア動作確認から、rootfsを内蔵SSDへ移す本番構成へ移行し、当初からの最終ゴールに到達しました（カーネル/DTBの読み込み元がUSBのままである点は前述の通りです）。次回(4)では実際に起きた本番障害の復旧を扱います。

ビルド成果物の公開

同じ機種で試したい方向けに、ここまでの全修正（SSD移行・SATA/PCIe/Wi-Fi/LED・USB2.0/PCIe診断ログ対応）を含む最終版のカーネルソース・Image・DTBをGitHubで公開しました。ソースは(2)で触れた通りGPL-2.0の派生物としてsymops/monarch-6.18をフォークする形で公開し、コンパイル済みのバイナリもReleaseとして添付しています。rootfs側については公開していませんが、公開の基準を満たせる状態になればこちらも公開しようと考えています。それまでは(1)(3)に書いた手順（公式Ubuntu Baseからの構築）で各自作成していただければと思います。

公開ファイルのハッシュ値（実機の稼働中BOOTパーティションから直接取得した、現在動いているビルドそのものです）:

30f74fe861f129ce4b8cf7e25dc6fd33ea5d22cd0738a436256f20c38583c19b  uImage (17,166,848 bytes)
e0a71d92fd98f5fcaa2b331e8e94b4b24d23dfe038b4150c27df56e8ce88984f  QuaStation.dtb (33,639 bytes)

Releaseに添付したファイルのハッシュと一致することを確認しています。

参考文献（シリーズ共通）

今回の移植は先人の資産の上に成り立っています。ベースにしたもの・参照したものを、実機（Qua Station）に近い国内発の情報源、同じSoCの海外コミュニティ情報源、および各種公式ドキュメントに分けて挙げます。

国内（Qua Station実機ベース）

海外（同じRTD1295系SoCのコミュニティ資産）

Wi-Fiファームウェアのライセンス

Bluetooth / D-Bus

ファイルシステム復旧（e2fsprogs）

シリーズ目次

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?