SDカードでイメージファイルの管理とコンテナの起動をする方法

frkw_r

2025年6月13日 10時53分

==========
製品型番：AG9130-C03Z
Debian/ABOSバージョン：3.21.3-at.9
ゲストOS : debian11
カーネルバージョン：5.10.236-2-at
==========

使用予定のコンテナのサイズが少々大きく、emmc内でイメージファイルの書き込みができなかったため、
SDカードでイメージファイルの管理とコンテナの起動を行いたいと思っております。
そのためにpodmanの参照先をSDカードにしたく設定をしていたのですがうまくいきません。
お手数おかけしますが、もし手順等があれば教えていただけないでしょうか？

以下の設定をstorage.confに書き込んでpodmanの再起動をしています。

runroot = “/run/containers/storage”
driver = “overlay”
graphroot = “/var/app/volumes/sd/podman_storage/storage”

podman ps -a を行ったときのエラー内容

Error : database static dir “var/lib/containers/storage/libpod” does not match our static dir “/var/app/volumes/sd/podman_storage/storage/libpod” : database configuration mismatch

コメントを投稿するにはログインまたは登録をしてください

at_dominique.m…

2025年6月16日 15時02分

frkw_rさん

お世話になっています、
マルティネです。

> 以下の設定をstorage.confに書き込んでpodmanの再起動をしています。

storage.conf の設定でこういう変更はできると思いますが、swupdate でコンテナをアップデートできなくなりますので正式に推奨しづらいところです。

代わりに、以下のどちらかの方法でいかがでしょうか。
* SD ブートを利用して、システムを完全に SD カードに移動できます。
https://manual.atmark-techno.com/armadillo-iot-a9e/armadillo-iotg-a9e_p…
* appfs (コンテナイメージや /var/app/volumes がはいってるパーティション）のパーティションだけを拡張できますが、こちらの場合の SD カード故障や紛失の場合の自動復帰の仕組みは標準にありませんのでご了承ください。（また、BTOサービスでも対応してません。）

パーティション拡張自体は簡単ですが、起動時のマウントのタイミングが早すぎて複数のデバイスの場合の自動認識はまだ起動してませんので、すべてのデバイスを指定する必要があります。

以下の通りに利用できます。SDカードを外したい場合はファイルを削除して「btrfs device remove /dev/mmcblk2p1 /var/app/volumes」で削除できます。

# なければパーティションを作ります
armadillo:~# gdisk /dev/mmcblk2
Command (? for help): n
Partition number (1-128, default 1): 
First sector (34-15759326, default = 2048) or {+-}size{KMGTP}: 
Last sector (2048-15759326, default = 15757311) or {+-}size{KMGTP}: 
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'
 
Command (? for help): w
 
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
 
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/mmcblk2.
The operation has completed successfully.
 
# btrfs を拡張します
armadillo:~# btrfs device add /dev/mmcblk2p1 /var/app/volumes/
Performing full device TRIM /dev/mmcblk2p1 (7.51GiB) ...
 
# 拡張の確認
armadillo:~# df -h /var/app/volumes/
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p5           10.3G      7.9M      9.8G   0% /var/app/volumes
armadillo:~# btrfs device usage /var/app/volumes/
/dev/mmcblk0p5, ID: 1
   Device size:             2.78GiB
   Device slack:            3.50KiB
   Data,single:             8.00MiB
   Metadata,DUP:          512.00MiB
   System,DUP:             16.00MiB
   Unallocated:             2.25GiB
 
/dev/mmcblk2p1, ID: 2
   Device size:             7.51GiB
   Device slack:              0.00B
   Unallocated:             7.51GiB
 
 
# 自動マウントが成功するようにデバイスをリストします。
# これもすべての行に追加する必要がありますので、sed で行ってますが、手動でも構いません。
armadillo:~# sed -i -e 's:mmcblk.p5.*discard=async:&,device=/dev/mmcblk2p1:' /etc/fstab 
 
# 確認と永続化
armadillo:~# grep p5 /etc/fstab 
/dev/mmcblk0p5	/var/lib/containers/storage_readonly	btrfs	compress=zstd,discard=async,device=/dev/mmcblk2p1,noatime,subvol=boot_0/containers_storage	0 0
/dev/mmcblk0p5	/var/app/rollback/volumes		btrfs	compress=zstd,discard=async,device=/dev/mmcblk2p1,noatime,subvol=boot_0/volumes		0 0
/dev/mmcblk0p5	/var/app/volumes		btrfs	compress=zstd,discard=async,device=/dev/mmcblk2p1,noatime,subvol=volumes		0 0
/dev/mmcblk0p5	/var/tmp			btrfs	compress=zstd,discard=async,device=/dev/mmcblk2p1,noatime,subvol=tmp			0 0
armadillo:~# persist_file -rv /etc/fstab 
removed '/target/etc/fstab'
'/mnt/etc/fstab' -> '/target/etc/fstab'

よろしくお願いします

コメントを投稿するにはログインまたは登録をしてください

frkw_r

2025年6月16日 16時02分

マルティネ様

ご返信ありがとうございます。
現状、emmcに書き込めるサイズ内でのコンテナ運用を想定している設計になっているという理解でよろしいでしょうか？

>>* appfs (コンテナイメージや /var/app/volumes がはいってるパーティション）のパーティションだけを拡張できますが、こちらの場合の SD カード故障や>>紛失の場合の自動復帰の仕組みは標準にありませんのでご了承ください。（また、BTOサービスでも対応してません。）
上記部分について恐れ入りますがもう少し説明いただけますでしょうか？
通常であればSDカードが紛失、故障があった場合は代替のSDカードで起動ができるものの上記手順を踏むとSDカードでの本体起動はできず本体交換等になるといったイメージでしょうか？

コメントを投稿するにはログインまたは登録をしてください

at_dominique.m…

2025年6月16日 16時31分

マルティネです。

> 現状、emmcに書き込めるサイズ内でのコンテナ運用を想定している設計になっているという理解でよろしいでしょうか？

はい、通常では eMMC でコンテナイメージも運用できるか、SD ブートですと OSごとにすべてを SD カードに保存する想定です。

コンテナイメージではなく、ファイル類を SD カードに保存して /var/app/volumes/sd 等にマウントすることは可能ですが、コンテナイメージに関してはアップデートの際の処理が多くて、コンテナイメージだけを別に保管すると swupdate のコンテナ管理機能を利用できなくなります。
（別のアップデート方法を用意すればそれでも問題ないですが、何かのアップデートの仕組みが必要だと考えています）

> >>* appfs (コンテナイメージや /var/app/volumes がはいってるパーティション）のパーティションだけを拡張できますが、こちらの場合の SD カード故障や>>紛失の場合の自動復帰の仕組みは標準にありませんのでご了承ください。（また、BTOサービスでも対応してません。）
> 上記部分について恐れ入りますがもう少し説明いただけますでしょうか？
> 通常であればSDカードが紛失、故障があった場合は代替のSDカードで起動ができるものの上記手順を踏むとSDカードでの本体起動はできず本体交換等になるといったイメージでしょうか？

SD カードをアクセスできなくっても、OS（ネットワーク、Armadillo Twin 等による遠隔操作、アップデート機能）としては動きます。
ただし、SDカードに保存されているデータはアクエスできなくなりますので、コンテナイメージやボリュームデータが保存している appfs をマウントできなくなります。
別のカードを投入し、Armadillo Base OS 側で appfs をゼロから作り直す処理が必要となります（起動スクリプトで何かの復帰処理を追加して SWU 等でコンテナを書き込み直すか、何かの復帰用の SWU を準備するか…）

そう考えると、拡張ではなく appfs をすべて置き換えた方が運用として楽かもしれません。
置き換えるとしてあら、 /var/app/volumes等の他の subvolumes も移動する必要がありますので、以下の用なコマンドで SD を予め準備しておいて fstab の変更で利用できます。（この場合の SD の紛失も起動できますし、置き換えはデータすでに書き込んだ状態で置き換えればいいだけですので管理が比較的に楽になります）

以下のコードは https://armadillo.atmark-techno.com/resources/software/armadillo-iot-a9… の「Alpine Linuxルートファイルシステムビルドツール」を展開して、「common/image_common/lib/rc/sh/functions-atmark.sh」の「format_app」からコピーしました。
（手順が複雑で申し訳ございません。subvolume 機能が必要のため、存在しているパーティションをそのまま cp でコピーすることはできません）

error() {
        printf "%s\n" "$@" >&2
        exit 1
}
 
label=app
dev=/dev/mmcblk2p1
mkfs.btrfs -q -f -L "$label" "$dev" \
        || error "mkfs btrfs failed" 
mount -t btrfs "$dev" /mnt
btrfs -q subvolume create /mnt/tmp \
        || error "subvolume creation failed" 
mkdir /mnt/boot_0 /mnt/boot_1
btrfs -q subvolume create /mnt/volumes \
        || error "subvolume creation failed" 
btrfs -q subvolume create /mnt/boot_0/containers_storage \
        || error "subvolume creation failed" 
btrfs -q subvolume create /mnt/boot_0/volumes \
        || error "subvolume creation failed" 
 
# work around podman being silly and throwing errors if the
# store does not look right
podman --storage-opt additionalimagestore="" \
        --root /mnt/boot_0/containers_storage image list >/dev/null 2>&1
rm -f /mnt/boot_0/containers_storage/libpod/bolt_state.db \
        /mnt/boot_0/containers_storage/db.sql
# yes it really needs that too...
mkdir -p /mnt/boot_0/containers_storage/overlay-layers /mnt/boot_0/containers_storage/overlay-images
touch /mnt/boot_0/containers_storage/overlay-images/images.lock
touch /mnt/boot_0/containers_storage/overlay-layers/layers.lock
btrfs property set /mnt/boot_0/containers_storage ro true 
 
# and prepare boot_1 as well just in case 
btrfs -q subvolume snapshot -r /mnt/boot_0/containers_storage /mnt/boot_1/containers_storage \
        || error "subvolume creation failed" 
btrfs -q subvolume create /mnt/boot_1/volumes \
        || error "subvolume creation failed" 
 
mountpoint -q /mnt/boot_0/containers_storage/overlay \
        && umount /mnt/boot_0/containers_storage/overlay
umount /mnt

上記の準備の後は fstab の mmcblk0p5 を mmcblk2p1 を置き換えれば完了です

armadillo:~# sed -i -e 's/mmcblk0p5/mmcblk2p1/' /etc/fstab 
armadillo:~# grep 2p1 /etc/fstab 
/dev/mmcblk2p1	/var/lib/containers/storage_readonly	btrfs	compress=zstd,discard=async,noatime,subvol=boot_0/containers_storage	0 0
/dev/mmcblk2p1	/var/app/rollback/volumes		btrfs	compress=zstd,discard=async,noatime,subvol=boot_0/volumes		0 0
/dev/mmcblk2p1	/var/app/volumes		btrfs	compress=zstd,discard=async,noatime,subvol=volumes		0 0
/dev/mmcblk2p1	/var/tmp			btrfs	compress=zstd,discard=async,noatime,subvol=tmp			0 0
armadillo:~# persist_file /etc/fstab 
armadillo:~# reboot
 
armadillo:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p1          300.0M    139.1M     92.7M  60% /live/rootfs
devtmpfs                 10.0M         0     10.0M   0% /dev
tmpfs                   190.1M   1004.0K    189.1M   1% /run
shm                     475.2M      4.0K    475.2M   0% /dev/shm
/dev/mmcblk0gp1           7.9M      2.0K      7.9M   0% /var/at-log
/dev/mmcblk0p3           41.8M      6.2M     32.2M  16% /var/log
tmpfs                   475.2M         0    475.2M   0% /tmp
/dev/mmcblk2p1            7.5G      3.7M      7.0G   0% /var/lib/containers/storage_readonly
/dev/mmcblk2p1            7.5G      3.7M      7.0G   0% /var/app/rollback/volumes
/dev/mmcblk2p1            7.5G      3.7M      7.0G   0% /var/app/volumes
/dev/mmcblk2p1            7.5G      3.7M      7.0G   0% /var/tmp
/dev/mmcblk0p4           20.1M     20.1M         0 100% /opt/firmware
none                    475.2M     20.0K    475.2M   0% /live
none                    475.2M     20.0K    475.2M   0% /

どのみち複雑ですので、パーティションを比較的に簡単に拡張して損失の場合に何かの対策を実装するか、SDカードを準備する時に複雑な処理をするかの２択ですね…

すでに検討されたと思いますが、コンテナの最適化で eMMC に保存できるようにするのは不可能でしょうか？
大きいサイズの原因をご存知でしたら、教えていただけますでしょうか？

よろしくお願いします。

コメントを投稿するにはログインまたは登録をしてください

frkw_r

2025年6月16日 17時09分

ご丁寧にありがとうございます。
SDカードでの対応はなかなか複雑で難しいのかなと印象を受けました。

>大きいサイズの原因をご存知でしたら、教えていただけますでしょうか？
サイズが大きい理由としましてはGreengrass,AWS関連のcomponent,java,pythonなどを入れているためコンテナサイズが大きいのだろうと考えられます。

コメントを投稿するにはログインまたは登録をしてください

at_dominique.m…

2025年6月16日 17時36分

マルティネです。

> SDカードでの対応はなかなか複雑で難しいのかなと印象を受けました。

eMMC OS + SD コンテナイメージが複雑な状態にしてしまって申し訳ございません。
SD ブートでしたらちゃんとサポートしている方法ですので、OS 部分で eMMC を利用しないのはもったいないところもありますが、今回は適切ではないかと思います。
https://manual.atmark-techno.com/armadillo-iot-a9e/armadillo-iotg-a9e_p…

> >大きいサイズの原因をご存知でしたら、教えていただけますでしょうか？
> サイズが大きい理由としましてはGreengrass,AWS関連のcomponent,java,pythonなどを入れているためコンテナサイズが大きいのだろうと考えられます。

了解しました、すぐにはできませんが今度にこれぐらいの規模のコンテナを作って色々試してみたいと思います。
インストールしている具体的な内容によりますが、コンテナのベースも alpine に切り替えるか https://github.com/canonical/chisel の様なプロジェクトでサイズを大分抑えれるのではないかと思います。
（debian は特に、python3-pip 等を入れるとデフォルトで運用に不要な gcc が入ってかなりの無駄ができますので、少し時間かかりますがサイズの改善は eMMC+SD の利用より確実だと考えています）

ひとまず SD ブートの前提で開発を進んでいただいて、サイズを改善できた時に eMMC に戻る方向でいかがでしょうか。

よろしくお願いします。

コメントを投稿するにはログインまたは登録をしてください

Armadilloフォーラム

SDカードでイメージファイルの管理とコンテナの起動をする方法

製品

コメント