Armadillo-IoT G3/G3L、あるいはArmadillo-X1では、x1-debian-builderというツールを使用してルートファイルシステムアーカイブを作成します。
この記事では、その主たる処理を行うbuild.shの動きについて、簡単に概要を説明いたします。
debootstrap
build.shは、そのほとんどがdebootstrapというツールのための処理です。
debootstrapは、Debianのルートファイルシステムアーカイブを作成するツールです。(Debianのインストーラーにも採用されているユーティリティです。)
debootstrapの処理を追うと、build.sh内の処理が分かりやすいです。
first stage
debootstrapの処理は、first stageとsecond stageに分かれています。
これは、Armadilloの場合、ルートファイルシステムアーカイブを作成するアーキテクチャ(ATDE6のx86アーキテクチャ)と、ルートファイルシステムアーカイブを実行する環境(ArmadilloのARMアーキテクチャ)が異なるためです。
first stageでは、second stageを実行するための最低限の環境を構築します。
build.shでfirst stageを実行しているのが以下の箇所(108行目)です。
debootstrap --arch=armhf --variant=minbase --include=$PKGS --foreign jessie $ABSP $MIRROR
"--foreign"が、debootstrapを実行している環境(ホスト環境)と作成されるルートファイルシステムが実行される環境(ターゲット環境)が異なることを指定しています。
そして、変数"$ABSP"の場所にルートファイルシステムアーカイブが構築されます。 ($ABSPの設定は、これより上の行で行っています。)
second stage
second stageでは、first stageで構築した最低限の環境を使用して、残りの処理を行います。
その際、ルートディレクトリ("/")を変更するchrootというコマンドを使用し、構築した環境内で処理を行います。
ただし、first stageで$ABSPへはARMの実行バイナリを配置していますので、QEMUというCPUのエミュレータを使用して、残りの処理を行います。
そのために、エミュレータを配置しているのが、111行目の処理です。
cp /usr/bin/qemu-arm-static $ABSP/usr/bin
なお、そのあとの処理(114行目)で、aiotg3l_resources等のボード固有ディレクトリ内のファイルを$ABSPへコピーしています。
cp -r $RES/* $ABSP
($RESへaiotg3l_resources等のディレクトリのパスが格納されています。)
そして、116行目でsecond stageを実行します。
chroot $ABSP sh -c "/debootstrap/debootstrap --second-stage"
(first stageにて、$ABSP/debootstrap/debootstrapにスクリプトが作成されています。)
packages等のインストール処理
以降のpackagesファイルへ記載したパッケージのインストールなども、chrootを使用して$ABSP環境内で行われます(132～134行目)。
chroot $ABSP sh -c "/resources/fixup" chroot $ABSP sh -c "apt-get clean" chroot $ABSP sh -c "LANG=C COLUMNS=150 dpkg -l > /resources/installed_pkgs.list"
なお、packages記載のパッケージのインストール等はボード固有ディレクトリ内の"resources/fixup"スクリプトに記載されています。