生成物を確認する
ビルドが終わったら、書き込む前に成果物を点検します。ls -lh で出力ディレクトリを眺め、カーネルイメージ・rootfsアーカイブ・SDカード用イメージのサイズが妥当かを確かめます。rootfsの中身は tar tf rootfs.tar で展開せずに一覧でき、目的のコマンドやライブラリが入っているかを確認できます。file コマンドでイメージの種別やアーキテクチャを照合しておくと、ターゲット違いの取り違えを防げます。確認を習慣にすると、起動しない原因を書き込み後ではなくビルド直後に切り分けられます。
ビルドが無事に終わったら、すぐにストレージへ書き込みたくなりますが、その前にひと呼吸おいて成果物を点検する習慣をつけると、後々のトラブルがぐっと減ります。組込み開発では、イメージを書き込んで実機の電源を入れても起動しない、という場面によく出くわします。そのとき、原因がビルドの段階にあったのか、それとも書き込みの段階にあったのかが切り分けられないと、調査はたちまち迷走します。書き込む前に生成物(bs-image)を確認しておけば、「少なくともビルドの出力そのものはおかしくない」という土台ができ、問題の切り分けが格段に楽になります。点検といっても特別な道具は要りません。CLIトラックで学んだ ls・file・tar といったおなじみのコマンドが、そのまま強力な検査ツールとして役立ちます。学んだ基礎が、上級の現場でそのまま生きる好例です。
サイズを眺める ls -lh
最初の点検は、出力ディレクトリ(Buildrootなら output/images/)に対して ls -lh(ls-images)を打ち、並んでいるファイルのサイズをざっと眺めることです。-l で1ファイル1行の詳細表示にし、-h を足すと 6.2M や 120M のように人間が読みやすい単位でサイズが出ます。ここで見るのは、おおよその妥当性です。カーネル(bs-kernel)イメージが数MBある、rootfs(bs-rootfs)が想定どおりの数十MBある、SDカード用イメージがそれらを足した程度のサイズになっている、といった具合に、桁が常識の範囲かを確かめます。もしrootfsのアーカイブが極端に小さく数KBしかなければ、パッケージがほとんど選ばれていない設定ミスの可能性が高く、書き込む前にその場で気づけます。逆にサイズがターゲットのストレージ容量を超えていれば、そもそも書き込めないことも事前に分かり、無駄な書き込みの試行を省けます。あわせて更新日時(タイムスタンプ)も確認しておくと、今回のビルドで実際に作り直されたものなのか、前回の古い成果物がそのまま残っているだけなのか、を見分けられます。意図せず古いイメージを書き込んでしまう取り違えは、案外起きがちな失敗です。
中身を一覧する tar tf
rootfsが tar アーカイブとして出力されている場合は、わざわざ展開しなくても中身を一覧できます。tar tf rootfs.tar(tar-rootfs)とすると、アーカイブに含まれるファイルとディレクトリの一覧だけが表示されます。t は list(目次を出す)、f は対象アーカイブの指定で、x(展開)と違ってディスクには何も書き出さないため、安全かつ高速です。これを使えば、目的のコマンドが /bin や /usr/bin に入っているか、それが必要とする共有ライブラリが /lib にあるか、自分で追加したアプリや設定ファイルが意図した場所に正しく配置されているか、を書き込み前に確認できます。一覧が多くて画面を流れてしまうときは、tar tf rootfs.tar | less でページ送りしながら眺めたり、tar tf rootfs.tar | grep 名前 で目当てのものだけを絞り込んだりすると、落ち着いて探せます。CLIで学んだパイプが、ここでも自然に効いてきます。
種別を照合する file
もうひとつ欠かせないのが file コマンドによる種別の確認です。file はファイルの中身の特徴を読み取って、それが何者なのかを判定してくれます。たとえば file zImage とすれば「Linux kernel ARM boot executable zImage」のような説明が返り、これが確かにArm向けのカーネルイメージであることが分かります。rootfsのイメージに対して使えば、それが ext4 なのか squashfs なのかといったファイルシステムの種別も教えてくれます。とくに重要なのが、アーキテクチャの照合です。クロスツールチェーン(bs-cross-toolchain)の設定を取り違えると、Arm向けのつもりが別アーキテクチャ向けの実行ファイルが出来てしまうことがあります。rootfsを展開して中の実行ファイルに file を使い、「ARM」「ARM aarch64」など狙ったアーキテクチャ名が表示されるかを確かめておけば、ターゲット違いの成果物を誤って書き込む事故を未然に防げます。もし母艦のx86向けバイナリが紛れ込んでいれば、ここで「x86-64」と表示されて、はっきり気づけます。アーキテクチャ違いの実行ファイルは、実機に書き込んで起動して初めて「実行できない」と分かることが多く、その手戻りは小さくありません。だからこそ、file による事前の照合が効くのです。
確認を習慣にする意味
これらの点検は、慣れればすべて合わせて1分もかかりません。ls -lh でサイズの桁を見て、tar tf で必要なものが入っているかを確かめ、file でアーキテクチャを照合する——この3点を書き込み前のルーティンにしておくだけで、起動しない原因の多くを「書き込んだ後」ではなく「ビルドした直後」に切り分けられるようになります。組込み開発では、SDカードに書いて実機に挿し、電源を入れてシリアルコンソールを眺める、という確認サイクルが1回ごとに重く、失敗のたびにまとまった時間を失います。書き込みや実機起動は、コストの高い工程なのです。だからこそ、安価で速いCLIでの事前点検が効いてきます。生成物を黙って信じてストレージに書き込むのではなく、一度自分の目で確かめてから次へ進む——この小さなひと手間が、結果として開発全体のテンポと信頼性を支えることになります。ここで使った ls・tar・file は、いずれもCLIの基礎トラックで学んだ汎用コマンドそのものです。新しい専用ツールを覚えるのではなく、すでに手になじんだ道具を組込みの成果物に向けるだけで点検が成り立つ——この地続き感も、基礎を固めておく価値を物語っています。