r_kawai
2022年11月13日 20時21分
いつもお世話になっております。
標題の件につきまして、インストールディスクイメージによる初期化後に2面が作成されるタイミング(swupdateができるようになるタイミング)についてご教示頂けませんでしょうか。
こちらでインストールディスクイメージによる初期化後に2面側(起動面とは別側の面)にアクセスしようとしたところエラーが発生し、swupdateもできない状態のときがあったため確認でした。
以下は確認した内容となります。
■使用したインストールディスクイメージ
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/im…
■abos-ctrl mount-oldのエラー
初期化後にabos-ctrl mount-oldで2面側の領域を確認しようとしたところエラーが発生しました。
[2022-11-12 21:20:18.473] armadillo:~# abos-ctrl mount-old [2022-11-12 21:20:32.736] [ 66.339044] exFAT-fs (mmcblk2p2): invalid boot record signature [2022-11-12 21:20:32.750] [ 66.345044] exFAT-fs (mmcblk2p2): failed to read boot sector [2022-11-12 21:20:32.760] [ 66.350714] exFAT-fs (mmcblk2p2): failed to recognize exfat type [2022-11-12 21:20:32.771] [ 66.373706] F2FS-fs (mmcblk2p2): Can't find valid F2FS filesystem in 1th superblock [2022-11-12 21:20:32.777] [ 66.381547] F2FS-fs (mmcblk2p2): Can't find valid F2FS filesystem in 2th superblock [2022-11-12 21:20:32.783] mount: /target: wrong fs type, bad option, bad superblock on /dev/mmcblk2p2, missing codepage or helper program, or other error. [2022-11-12 21:20:32.794] dmesg(1) may have more information after failed mount system call. [2022-11-12 21:20:32.800] ERROR: Could not mount /dev/mmcblk2p2 to /target
■swupdateのエラー
また、swupdateでソフトをアップデートしようとしたところ以下のエラーが発生しており、この時点では2面用領域となっている/dev/mmcblk2p2にロールバック用のデータが書き込まれていなかったとの認識です。
Nov 12 21:36:09 armadillo user.notice swupdate-auto-update: Mounting sda1 on /mnt in private namespace Nov 12 21:36:09 armadillo user.notice swupdate-auto-update: Trying update /mnt/OS_update.swu Nov 12 21:36:09 armadillo user.info swupdate: START Software Update started ! Nov 12 21:36:09 armadillo kern.err kernel: [ 1002.367339] exFAT-fs (mmcblk2p2): invalid boot record signature Nov 12 21:36:09 armadillo kern.err kernel: [ 1002.373320] exFAT-fs (mmcblk2p2): failed to read boot sector Nov 12 21:36:09 armadillo kern.err kernel: [ 1002.378993] exFAT-fs (mmcblk2p2): failed to recognize exfat type Nov 12 21:36:09 armadillo kern.info kernel: [ 1002.396215] F2FS-fs (mmcblk2p2): Magic Mismatch, valid(0xf2f52010) - read(0x0) Nov 12 21:36:09 armadillo kern.err kernel: [ 1002.396223] F2FS-fs (mmcblk2p2): Can't find valid F2FS filesystem in 1th superblock Nov 12 21:36:09 armadillo kern.info kernel: [ 1002.404050] F2FS-fs (mmcblk2p2): Magic Mismatch, valid(0xf2f52010) - read(0x0) Nov 12 21:36:09 armadillo kern.err kernel: [ 1002.404056] F2FS-fs (mmcblk2p2): Can't find valid F2FS filesystem in 2th superblock Nov 12 21:36:09 armadillo kern.info kernel: [ 1002.887887] EXT4-fs (mmcblk2p2): mounted filesystem with ordered data mode. Opts: (null) Nov 12 21:36:09 armadillo user.info swupdate: RUN [read_lines_notify] : Updating base os: copying swupdate_preserve_files Nov 12 21:36:10 armadillo user.info swupdate: RUN [read_lines_notify] : Waiting for btrfs to flush deleted subvolumes
■放置後にエラーが解消
この後swupdateを何度か試しても上記エラーが出たため、電源を切らずに1時間ほど放置し、再度2面を確認したところ、以下のようにエラーは発生しませんでした。
また、swupdateも成功するようになっていました。
[2022-11-12 22:46:08.549] armadillo:~# armadillo:~# abos-ctrl statusmount-old [2022-11-12 22:46:26.864] Mounted /dev/mmcblk2p2 to /target successfully. [2022-11-12 22:46:26.864] Unmount it with 'umount -R /target' when done [2022-11-12 22:46:26.870] armadillo:~# ls -l /tararmadillo:~# ls -l /target/ [2022-11-12 22:46:37.923] total 42 [2022-11-12 22:46:37.923] drwxr-xr-x 2 root root 3072 Oct 3 10:18 bin [2022-11-12 22:46:37.923] drwxr-xr-x 3 root root 1024 Nov 12 21:36 boot [2022-11-12 22:46:37.929] drwxr-xr-x 2 root root 1024 Oct 3 10:18 dev [2022-11-12 22:46:37.934] drwxr-xr-x 40 root root 3072 Nov 12 21:36 etc [2022-11-12 22:46:37.940] drwxr-xr-x 3 root root 1024 Oct 3 10:18 home [2022-11-12 22:46:37.940] drwxr-xr-x 13 root root 3072 Oct 3 10:17 lib [2022-11-12 22:46:37.945] drwxr-xr-x 2 root root 1024 Oct 3 10:17 live [2022-11-12 22:46:37.951] drwx------ 2 root root 12288 Nov 12 21:36 lost+found [2022-11-12 22:46:37.957] drwxr-xr-x 2 root root 1024 Nov 12 21:36 mnt [2022-11-12 22:46:37.962] drwxr-xr-x 3 root root 1024 Oct 3 10:18 opt [2022-11-12 22:46:37.962] dr-xr-xr-x 2 root root 1024 Oct 3 10:17 proc [2022-11-12 22:46:37.969] drwx------ 2 root root 1024 Oct 3 10:17 root [2022-11-12 22:46:37.972] drwxr-xr-x 2 root root 1024 Oct 3 10:17 run [2022-11-12 22:46:37.979] -rw-r--r-- 1 root root 453 Oct 3 10:17 run.sh [2022-11-12 22:46:37.979] drwxr-xr-x 2 root root 6144 Oct 3 10:18 sbin [2022-11-12 22:46:37.985] drwxr-xr-x 2 root root 1024 Oct 3 10:17 sys [2022-11-12 22:46:37.991] drwxr-xr-x 2 root root 1024 Oct 3 10:17 target [2022-11-12 22:46:37.999] drwxrwxrwt 2 root root 1024 Oct 3 10:17 tmp [2022-11-12 22:46:37.999] drwxr-xr-x 9 root root 1024 Nov 12 21:36 usr [2022-11-12 22:46:38.002] drwxr-xr-x 14 root root 1024 Nov 12 21:36 var [2022-11-12 22:46:38.008] armadillo:~# cat /etc/sw-vearmadillo:~# cat /etc/sw-versions [2022-11-12 22:46:53.594] base_os 3.16.2-at.5 [2022-11-12 22:46:53.594] boot 2020.04-at10 [2022-11-12 22:46:53.594] armadillo:~# cat /etc/sw-verarmadillo:~# cat /etc/sw-versions [2022-11-12 22:47:00.591] base_os 3.16.2-at.5 [2022-11-12 22:47:00.591] boot 2020.04-at10
■ログ
ご参考までにインストールディスクイメージの書き込み時のログ(diskimage.log)と/var/log/messages(messages.log)を貼付いたします。
| ファイル | ファイルの説明 |
|---|---|
| diskimage.log | |
| messages.log |
コメント
r_kawai
マルティネ様
お忙しいところご回答いただきありがとうございます。
>そのの「Waiting for btrfs to flush deleted subvolumes」で少し時間かかることもありますが、数秒すれば続くはずで、その後は swu の中身をインストールするはずですがその後のメッセージがないですね… ログでは何も行っていませんが、USBディスクを挿した後に何かなさいましたか？
>swupdate がその段階で失敗すればログも出力はずですし、成功の場合にもメッセージがありますので、気になりますね。
申し訳ありません。OS_update.swuはpodmanコンテナイメージ(2GB程度)を含むためswupdateに10分程度時間がかかりますが、exFAT/F2FS エラーが出ていたのでswupdateも失敗したと思い込み、その時点でのmessageを取得しておりました。
別途インストールディスクイメージによる初期化⇒swupdateした際のログが残っていましたので貼付いたします。
Nov 13 19:51:19 armadillo user.notice swupdate-auto-update: Mounting sdb1 on /mnt in private namespace Nov 13 19:51:19 armadillo user.notice swupdate-auto-update: Trying update /mnt/OS_update.swu Nov 13 19:51:19 armadillo user.info swupdate: START Software Update started ! Nov 13 19:51:19 armadillo kern.err kernel: [ 702.902979] exFAT-fs (mmcblk2p2): invalid boot record signature Nov 13 19:51:19 armadillo kern.err kernel: [ 702.909062] exFAT-fs (mmcblk2p2): failed to read boot sector Nov 13 19:51:19 armadillo kern.err kernel: [ 702.914752] exFAT-fs (mmcblk2p2): failed to recognize exfat type Nov 13 19:51:19 armadillo kern.info kernel: [ 702.932401] F2FS-fs (mmcblk2p2): Magic Mismatch, valid(0xf2f52010) - read(0x0) Nov 13 19:51:19 armadillo kern.err kernel: [ 702.932410] F2FS-fs (mmcblk2p2): Can't find valid F2FS filesystem in 1th superblock Nov 13 19:51:19 armadillo kern.info kernel: [ 702.940301] F2FS-fs (mmcblk2p2): Magic Mismatch, valid(0xf2f52010) - read(0x0) Nov 13 19:51:19 armadillo kern.err kernel: [ 702.940306] F2FS-fs (mmcblk2p2): Can't find valid F2FS filesystem in 2th superblock Nov 13 19:51:20 armadillo kern.info kernel: [ 703.364658] EXT4-fs (mmcblk2p2): mounted filesystem with ordered data mode. Opts: (null) Nov 13 19:51:20 armadillo user.info swupdate: RUN [read_lines_notify] : Updating base os: copying swupdate_preserve_files Nov 13 19:51:20 armadillo user.info swupdate: RUN [read_lines_notify] : Waiting for btrfs to flush deleted subvolumes Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Command 'command podman load --root /target/var/lib/containers/storage_readonly --storage-opt additionalimagestore= -i /mnt/test.podman.tar' output: Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Getting image source signatures Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Copying blob sha256:0991e1daab05b30b471362c6198cfc08d47d8812b55b967a4949435aaa713a40 Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Copying blob sha256:85b12675e3d61e42bdaddc234788e4a058c1587fa8b076811d2fb23d7b3f6b25 Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Copying blob sha256:8afc88fd93584bd63c4caa7029efde62c9d9f3d0bba3736e48b756bee07bd737 Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Copying blob sha256:bfce960e646c723ea41687172376a0c1f2ac78930ad1d94b9015dee98598a11e Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Copying blob sha256:0450d33c2f5b3cfefdba9381c13d059025f6efdbd773f56cbf86eb1c18e12f18 Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Copying blob sha256:0cbc370f1c3feea2c04af16ecf80f1130aa683b3b3c1939268efeb0755f91866 Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Copying config sha256:2c37070e402d2fadde40bdad227bdbb1d1189151024611115fb9b72143c90ea4 Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Writing manifest to image destination Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Storing signatures Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Loaded image: localhost/at-debian-image:test Nov 13 20:01:53 armadillo user.info swupdate: RUN [read_lines_notify] : Removing unused containers Nov 13 20:01:57 armadillo user.info swupdate: RUN [read_lines_notify] : swupdate triggering reboot! Nov 13 20:01:57 armadillo daemon.info init: starting pid 2384, tty '': '/sbin/openrc shutdown' Nov 13 20:01:57 armadillo user.debug : Will stop /usr/bin/connection-recover Nov 13 20:01:57 armadillo user.debug : Will stop PID 1549 Nov 13 20:01:57 armadillo user.debug : Sending signal 15 to PID 1549 Nov 13 20:01:57 armadillo daemon.info supervise-daemon[1693]: stopping /usr/sbin/ModemManager, pid 1694 Nov 13 20:01:57 armadillo daemon.debug supervise-daemon[1693]: Will stop PID 1694 Nov 13 20:01:57 armadillo daemon.debug supervise-daemon[1693]: Sending signal 15 to PID 1694 Nov 13 20:01:57 armadillo daemon.info [1694]: <info> caught signal, shutting down... Nov 13 20:01:57 armadillo daemon.info NetworkManager[1372]: <info> [1668337317.9713] modem-manager: ModemManager no longer available Nov 13 20:01:57 armadillo daemon.info NetworkManager[1372]: <info> [1668337317.9715] device (ttyCommModem): state change: unavailable -> unmanaged (reason 'removed', sys-iface-state: 'removed') Nov 13 20:01:57 armadillo daemon.info [1694]: <info> ModemManager is shut down Nov 13 20:01:57 armadillo daemon.warn NetworkManager[1372]: <warn> [1668337317.9846] modem-manager: error poking ModemManager: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ModemManager1 was not provided by any .service files Nov 13 20:01:57 armadillo user.debug : Will stop /usr/bin/buttond Nov 13 20:01:57 armadillo user.debug : Will stop PID 1500 Nov 13 20:01:57 armadillo user.debug : Sending signal 15 to PID 1500 Nov 13 20:01:57 armadillo user.debug : Will stop PID 1586 Nov 13 20:01:57 armadillo user.debug : Sending signal 15 to PID 1586 Nov 13 20:01:57 armadillo daemon.info chronyd[1586]: chronyd exiting Nov 13 20:01:58 armadillo kern.info kernel: [ 1341.036178] zram0: detected capacity change from 1073741824 to 0 Nov 13 20:01:58 armadillo kern.info kernel: [ 1341.036382] zram: Removed device: zram0 Nov 13 20:01:58 armadillo user.debug : Will stop /usr/sbin/dnsmasq Nov 13 20:01:58 armadillo user.debug : Will stop PID 1401 Nov 13 20:01:58 armadillo user.debug : Sending signal 15 to PID 1401 Nov 13 20:01:58 armadillo daemon.info dnsmasq[1401]: exiting on receipt of SIGTERM Nov 13 20:01:58 armadillo user.debug : Will stop /sbin/klogd Nov 13 20:01:58 armadillo user.debug : Will stop PID 1335 Nov 13 20:01:58 armadillo user.debug : Sending signal 15 to PID 1335 Nov 13 20:01:58 armadillo kern.notice kernel: klogd: exiting Nov 13 20:01:58 armadillo user.debug : Will stop /usr/sbin/rngd Nov 13 20:01:58 armadillo user.debug : Will stop PID 645 Nov 13 20:01:58 armadillo user.debug : Sending signal 15 to PID 645 Nov 13 20:01:58 armadillo daemon.info supervise-daemon[1370]: stopping /usr/sbin/NetworkManager, pid 1372 Nov 13 20:01:58 armadillo daemon.debug supervise-daemon[1370]: Will stop PID 1372 Nov 13 20:01:58 armadillo daemon.debug supervise-daemon[1370]: Sending signal 15 to PID 1372 Nov 13 20:01:58 armadillo daemon.info NetworkManager[1372]: <info> [1668337318.1266] caught SIGTERM, shutting down normally. Nov 13 20:01:58 armadillo user.debug : Will stop /sbin/syslogd Nov 13 20:01:58 armadillo user.debug : Will stop PID 1238 Nov 13 20:01:58 armadillo user.debug : Sending signal 15 to PID 1238 Nov 13 20:01:58 armadillo syslog.info syslogd exiting Nov 13 20:02:44 armadillo syslog.info syslogd started: BusyBox v1.35.0 Nov 13 20:02:44 armadillo kern.notice kernel: klogd started: BusyBox v1.35.0 (2022-08-01 15:14:44 UTC) Nov 13 20:02:44 armadillo kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
エラーメッセージを確認してからUSBメモリを挿して放置したままだったので、アップデートが成功してリブートまで進んでいることに気づいておりませんでした。
お騒がせいたしました。
sw-versionsもテスト用のバージョン(3.17-at.3)になっていることを確認しました。
armadillo:~# cat /etc/sw-versions base_os 3.17-at.3 other_boot 2020.04-at10 boot 2020.04-at9 armadillo:~# abos-ctrl mount-old Mounted /dev/mmcblk2p1 to /target successfully. Unmount it with 'umount -R /target' when done armadillo:~# cat /target/etc/sw-versions base_os 3.16.2-at.5 boot 2020.04-at10
>結論から言うと、swupdate がその2面目を作ります。
>初期化でインストールスピードを優先するために rootfs_0 面しか書きませんが、swupdate を実行するときに rootfs_0 の中身を rootfs_1 にコピーして使えるようになります。
>
>なので、
>- 初期化状態で mount-old を使えませんエラーは現在の設計どおりです。
>- swupdate を実行する際に、2面側をそのまま使えるかを確認するためにマウントしようとして、その時に「exFAT-fs」と「F2FS-fs」のエラーがでるのも、普通です。
現状exFAT/F2FS エラーが出てもご回答の通り、swupdateは実行されていると理解いたしました。
アップデートについても検討されているとのこと承知いたしました。
at_dominique.m…
r_kawaiさん
> 申し訳ありません。OS_update.swuはpodmanコンテナイメージ(2GB程度)を含むためswupdateに10分程度時間がかかりますが、exFAT/F2FS エラーが出ていたのでswupdateも失敗したと思い込み、その時点でのmessageを取得しておりました。
なるほど、時間不足で切っていただけですね。ご確認ありがとうございました。
勘違いだけでよかったです。使いやすくしたいので、何でもフィードバックをください！
> Nov 13 20:01:57 armadillo user.info swupdate: RUN [read_lines_notify] : swupdate triggering reboot!
この行は成功に終了した合図ですが、これも改めてみると分かりにくいですね。「install success」などのメッセージもどこにもないですしね。
すでにどこかの製造でログを確認するスクリプトがあるかもしれませんので、追加メッセージで改善したいと思います。
> sw-versionsもテスト用のバージョン(3.17-at.3)になっていることを確認しました。
ちなみ baseos のバージョンの最初の部分は alpine のバージョンで、今月中に alpine 3.17 がリリースされる予定です。baseos 3.17.x ももう少ししたら出てきます。
アットマークからのアップデートを使わない限りには問題ないですが、サポート的には `3.16.3-hoge.x` を使っていただければ中身のソフトウェアのバージョンをある程度わかって便利かと思います。（hoge が alphabet順で at より後の場合はちゃんと上のバージョンとして認められますが、最初のアップデートで swdesc_tar --install-if different を使った方がいいと思います…これも細かくてあまり説明してないので申し訳ございません…）
よろしくお願いします
r_kawai
マルティネ様
>より後の場合はちゃんと上のバージョンとして認められますが、最初のアップデートで
>swdesc_tar --install-if different
>を使った方がいいと思います…これも細かくてあまり説明してないので申し訳ございません…）
情報頂きありがとうございます。バージョンが低い場合はアップデートできないと考えておりました。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
9.7.5. mkswu の desc ファイル
にも記載頂いていますね。
現在量産向け書き込み、アップデートについて検討しており、いくつか追加で確認させていただきたいことがあります。
以下に質問を追記しましたので、お忙しいところ色々とお手数おかけしますが、ご確認頂けますと幸いです。
(長くなるのでコメントは分割させて頂きました)
r_kawai
【追加質問①】
G4のイメージをSDカードに作成したいと考えており、
https://armadillo.atmark-techno.com/blog/15288/12134
を参考にabos-ctrl make-installerを試していますが「No space left on device」というが発生しています。
podmanコンテナイメージを含めたイメージを作成しようとしていますが、書き込み用データを格納するパーティション(/dev/mmcblk1p1)が404MBに対して、コンテナイメージが2.2GBなので「No space left on device」が発生している認識です。
/usr/sbin/abos-ctrlのinstaller_resize_and_mount_sd_rootあたりでパーティションサイズを決めているのかと推測していますが、エラーの回避方法があればご教示いただけませんでしょうか。
現在使用している環境のベースは以下となります。
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/to…
また、SDカードは新品でフォーマットしていない状態で使用しました。
以下確認内容となります。
■abos-ctrl make-installer時のログ
[2022-11-14 16:12:05.085] It looks like your SD card does not contain an installer image [2022-11-14 16:12:05.092] Download base SD card image from https://armadillo.atmark-techno.com (~200MB) ? [y/N] [2022-11-14 16:12:05.098] WARNING: it will overwrite your sd card!! [2022-11-14 16:12:08.276] y [2022-11-14 16:12:08.614] Downloading installer image [2022-11-14 16:12:08.632] % Total % Received % Xferd Average Speed Time Time Time Current [2022-11-14 16:12:08.638] Dload Upload Total Spent Left Speed #進捗状況ログが大量に出力されたため省略 [2022-11-14 16:17:32.775] % Total % Received % Xferd Average Speed Time Time Time Current [2022-11-14 16:17:32.781] Dload Upload Total Spent Left Speed [2022-11-14 16:17:32.786] 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0100 70 100 70 0 0 292 0 --:--:-- --:--:-- --:--:-- 291 [2022-11-14 16:17:33.948] Writing baseos-x2-installer-3.16.2-at.5.img to SD card (446M) #進捗状況ログが大量に出力されたため省略 [2022-11-14 16:18:00.197] 425+0 records in [2022-11-14 16:18:00.197] 425+0 records out [2022-11-14 16:18:00.197] 445644800 bytes (446 MB, 425 MiB) copied, 26.2426 s, 17.0 MB/s [2022-11-14 16:18:00.205] Verifying written image is correct [2022-11-14 16:18:00.611] [23779.114095] udevd[5156]: failed to execute '/usr/libexec/XXXXX-update-conf' '/usr/libexec/XXXXX-update-conf mmcblk1p1': Permission denied #進捗状況ログが大量に出力されたため省略 [2022-11-14 16:18:11.801] 425+0 records in [2022-11-14 16:18:11.801] 425+0 records out [2022-11-14 16:18:11.801] 445644800 bytes (446 MB, 425 MiB) copied, 11.5999 s, 38.4 MB/s [2022-11-14 16:18:12.031] [23790.534806] udevd[5218]: failed to execute '/usr/libexec/XXXXX-update-conf' '/usr/libexec/XXXXX-update-conf mmcblk1p1': Permission denied [2022-11-14 16:18:12.061] Copying boot image [2022-11-14 16:18:12.241] Copying rootfs #進捗状況ログが大量に出力されたため省略 [2022-11-14 16:18:24.398] 300+0 records in [2022-11-14 16:18:24.398] 300+0 records out [2022-11-14 16:18:24.398] 314572800 bytes (315 MB, 300 MiB) copied, 10.8774 s, 28.9 MB/s [2022-11-14 16:18:27.429] Copying /opt/firmware filesystem [2022-11-14 16:18:27.585] Copying appfs [2022-11-14 16:18:27.659] At subvol app/snapshots/volumes [2022-11-14 16:18:27.659] At subvol app/snapshots/boot_volumes [2022-11-14 16:18:27.666] At subvol app/snapshots/boot_containers_storage [2022-11-14 16:18:42.564] lzop: write error: No space left on device [2022-11-14 16:18:42.564] ERROR: Failed compressing or writing lzo file
■ディスクサイズ
[2022-11-14 16:27:02.365] armadillo:~# lsblk [2022-11-14 16:27:11.236] NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS [2022-11-14 16:27:11.236] mmcblk2 179:0 0 9.8G 0 disk [2022-11-14 16:27:11.243] tqmmcblk2p1 179:1 0 300M 0 part /target [2022-11-14 16:27:11.250] tqmmcblk2p2 179:2 0 300M 0 part /live/rootfs [2022-11-14 16:27:11.253] tqmmcblk2p3 179:3 0 50M 0 part /target/var/log [2022-11-14 16:27:11.260] x /var/log [2022-11-14 16:27:11.260] tqmmcblk2p4 179:4 0 200M 0 part /opt/firmware [2022-11-14 16:27:11.264] mqmmcblk2p5 179:5 0 9G 0 part /target/var/tmp [2022-11-14 16:27:11.270] /target/var/app/volumes [2022-11-14 16:27:11.277] /target/var/app/rollback/volumes [2022-11-14 16:27:11.282] /target/var/lib/containers/storage_readonly [2022-11-14 16:27:11.294] /var/tmp [2022-11-14 16:27:11.294] /var/app/volumes [2022-11-14 16:27:11.299] /var/app/rollback/volumes [2022-11-14 16:27:11.304] /var/lib/containers/storage_readonly [2022-11-14 16:27:11.313] mmcblk2boot0 [2022-11-14 16:27:11.315] 179:32 0 31.5M 1 disk [2022-11-14 16:27:11.315] mmcblk2boot1 [2022-11-14 16:27:11.315] 179:64 0 31.5M 1 disk [2022-11-14 16:27:11.322] mmcblk2gp0 179:96 0 8M 0 disk [2022-11-14 16:27:11.328] mmcblk2gp1 179:128 0 8M 0 disk /var/at-log [2022-11-14 16:27:11.328] mmcblk2gp2 179:160 0 8M 0 disk [2022-11-14 16:27:11.337] mmcblk2gp3 179:192 0 8M 0 disk [2022-11-14 16:27:11.345] mmcblk1 179:224 0 115.8G 0 disk [2022-11-14 16:27:11.345] mqmmcblk1p1 179:225 0 404M 0 part [2022-11-14 16:27:11.352] zram0 254:0 0 1G 0 disk [SWAP] [2022-11-14 16:27:11.360] armadillo:~# podman images [2022-11-14 16:28:30.298] REPOSITORY TAG IMAGE ID CREATED SIZE R/O [2022-11-14 16:28:30.305] localhost/at-debian-image XXXXX 2c37070e402d 6 weeks ago 2.44 GB true [2022-11-14 16:59:32.492] armadillo:~# df [2022-11-14 16:59:34.162] Filesystem 1K-blocks Used Available Use% Mounted on [2022-11-14 16:59:34.162] /dev/root 277623 194089 64078 76% /live/rootfs [2022-11-14 16:59:34.168] devtmpfs 10240 0 10240 0% /dev [2022-11-14 16:59:34.177] tmpfs 340616 11496 329120 4% /run [2022-11-14 16:59:34.180] shm 851532 84 851448 1% /dev/shm [2022-11-14 16:59:34.185] tmpfs 851532 0 851532 0% /tmp [2022-11-14 16:59:34.193] /dev/mmcblk2p3 42851 436 38831 2% /var/log [2022-11-14 16:59:34.199] /dev/mmcblk2p5 9441260 1488428 7538564 17% /var/lib/containers/storage_readonly [2022-11-14 16:59:34.202] /dev/mmcblk2p5 9441260 1488428 7538564 17% /var/app/rollback/volumes [2022-11-14 16:59:34.210] /dev/mmcblk2p5 9441260 1488428 7538564 17% /var/app/volumes [2022-11-14 16:59:34.213] /dev/mmcblk2p5 9441260 1488428 7538564 17% /var/tmp [2022-11-14 16:59:34.219] /dev/mmcblk2gp1 8162 2 8160 1% /var/at-log [2022-11-14 16:59:34.227] /dev/mmcblk2p4 24448 24448 0 100% /opt/firmware [2022-11-14 16:59:34.231] none 851532 84 851448 1% /live [2022-11-14 16:59:34.236] none 851532 84 851448 1% / [2022-11-14 16:59:34.247] /dev/mmcblk2p1 277623 162074 96093 63% /target [2022-11-14 16:59:34.249] /dev/mmcblk2p5 9441260 1488428 7538564 17% /target/var/lib/containers/storage_readonly [2022-11-14 16:59:34.253] /dev/mmcblk2p5 9441260 1488428 7538564 17% /target/var/app/rollback/volumes [2022-11-14 16:59:34.265] /dev/mmcblk2p5 9441260 1488428 7538564 17% /var/lib/containers/storage [2022-11-14 16:59:34.271] /dev/mmcblk1p1 413696 339664 80 100% /mnt
■/var/log/messages
abos-ctrl make-installer失敗時のログを含む/var/log/messagesを貼付します(messages_make-installer.log)。
| ファイル | ファイルの説明 |
|---|---|
| messages_make-installer.log |
r_kawai
【追加質問②】
量産にあたり複数台に書き込むためにインストールディスクイメージを作成するのが追加質問①の背景となります。
おおまかではありますが、現状量産書き込み、アップデートを以下のような方針で行うことを考えております。
あいまいな質問となってしまいますが、問題となりそうな点がありましたらご指摘頂けますと幸いです。
また、★をつけている箇所につきまして、ご意見を頂けますとありがたいです。
■方針
①ソフト構成
・uboot：基本変更しない想定のため、アットマークテクノ様提供イメージを使用します
・imx_lib：変更はしない想定です。make-imxlibimageでビルドして作成します
・rootfs：弊社独自のファイルを組み込むため、build-rootfs環境でビルドして作成します
・kernel：カーネルモジュールを追加しconfigを変更するため、ビルドして作成します
・podmanイメージ：弊社で使用するアプリを組み込みます
②量産以降のソフト更新タイミング
・弊社の不具合、機能追加時
・アットマークテクノ様アップデートで取り込み必要と思わるものがあった場合
③量産時書き込み方法
・上記ソフト構成をSDカードにインストールディスクイメージとして格納し、SDカードによる書き込みを想定しています
★G4初期状態のバージョンが弊社rootfsより新しい場合swuアップデートできないと考えていましたが、
swdesc_tar --install-if differentを指定すれば古いバージョンでもアップデート可能とのことなので、
swupdate_preserve_filesで指定したファイルが上書きされないこと以外はswupdateでもSDカードによる書き込みと同等なことが可能でしょうか？
④アップデート方法
・顧客のネットワーク環境が不安定な可能性があるので、自動アップデートは無効とすることを想定しています
・アップデートが必要な場合は顧客にswuパッケージを提供して、USBメモリでアップデートしてもらうことを想定しています
★顧客はLinuxの知識がなくコンソールも使えない可能性があるので、書き込み中はswupdate-usb内でLEDを点滅させる等して、外見から分かるようにして頂けますとありがたいです
★swuパッケージに組み込むpodmanイメージのサイズを削減したいと考えています。
https://armadillo.atmark-techno.com/blog/15288/12148
の差分を提供する方法を検討しましたが、こちらはベースとなるpodmanイメージが同じ場合しか使用できない認識です。
podmanイメージを圧縮して格納する方法を考えておりますが、他に案がありましたらご教示頂けますと幸いです。
at_dominique.m…
テクスト内にコメントをさせていただきました。
長くなってしまって申し訳ございませんが、せっかく意見をいただけるのはこちらもありがたいと思って追加情報をいくつか聞いてみました。
時間がなければ後回しでも構いませんので、時間がある時に是非お願いします。
> ■方針
> ①ソフト構成
> ・uboot：基本変更しない想定のため、アットマークテクノ様提供イメージを使用します
> ・imx_lib：変更はしない想定です。make-imxlibimageでビルドして作成します
（変更ない場合は購入時の /opt/firmware を make-installer によってコピーされますので、make-imxlibimage は開発に必要な場合（atde上にライブラリが必要）だけにおすすめします。特に問題もないので、どちらでも使ってください）
> ・rootfs：弊社独自のファイルを組み込むため、build-rootfs環境でビルドして作成します
個人的に気になるだけですが、rootfs の変更ってどういう変更を行いましたか？
できるだけコンテナで対応できる環境を作って、swu でいくつかの設定ファイルを置くだけでコンテナで対応していただく想定で開発していますが、
rootfs に足りない物があったら標準のイメージを使えるようにしたいです。
> ・kernel：カーネルモジュールを追加しconfigを変更するため、ビルドして作成します
確認だけですが、カーネルをどうインストールしていますか？
build-rootfs の ax2/packages から linux-at-x2 を外して、ファイルをそのまま ax2/resources に書きましたか? それか直接に build-rootfs のアップデートの後に直接に armadillo にコピーしましたか？
カーネルにいくつかのモジュールもありますので、arch/arm64/boot/Image だけではなく、 modules_install もしているかどうかも気になります。そこの情報についても改善する余地がありますので確認していただければ助かります。
INSTALL_MOD_PATH=/path/to/build-rootfs/ax2/resources make modules_install
> ・podmanイメージ：弊社で使用するアプリを組み込みます
ちなみに podmanイメージは今月まで (swuか）abos-ctrl make-installer でしか取得できませんでしたが、
最新の build-rootfs でしたら、そこの build_image.sh も使って直接にインストールディスクを作成できます。
v3.16-at.5 以降では ax2/image_installer/ に swu ファイルをコピーすれば、インストールディスクに含まれてインストールされます。
インストールディスクを作っていただいていたらこれも便利かもしれないと思っていましたが、以下の続きを読んで直接に swu でインストールした方がらくかもしれません。情報として残しておきますが、無視しても構いません。
（これは先月、社内用に追加したばかり機能でマニュアルにまだ説明してません…）
> ②量産以降のソフト更新タイミング
> ・弊社の不具合、機能追加時
> ・アットマークテクノ様アップデートで取り込み必要と思わるものがあった場合
（個人の意見で、現実的ではないのは承知の上で）
セキュリティアップデートもよく出ていますので、ネットワークに接続されているのであれば定期的なアップデートもおすすめします。
セキュリティ以外の面では、例えば一年後に不具合でて修正しようと思った場合は、ほぼ必ず手順を忘れたり、アップデートが失敗したりしますので、定期的に行うことで本当に必要な時にスムースにできるようになると思います。
そうは言っても、ネットワークが不安定な環境で手動アップデートが面倒のもよく分かります。難しい問題です…
> ③量産時書き込み方法
> ・上記ソフト構成をSDカードにインストールディスクイメージとして格納し、SDカードによる書き込みを想定しています
> ★G4初期状態のバージョンが弊社rootfsより新しい場合swuアップデートできないと考えていましたが、
> swdesc_tar --install-if differentを指定すれば古いバージョンでもアップデート可能とのことなので、
> swupdate_preserve_filesで指定したファイルが上書きされないこと以外はswupdateでもSDカードによる書き込みと同等なことが可能でしょうか？
はい、swu の base_os のアップデートと、SD カードのインストーラーによる書き込みの違いは swupdate_preserve_files に乗っているファイルのリストだけです。
そこもマニュアルにまだ入れてませんが、mkswu の .desc ファイルの上に `swdesc_option NO_PRESERVE_FILES` を入れるか、/etc/atmark/baseos.conf に MKSWU_NO_PRESERVE_FILES=1 を設定する場合には swupdate_preserve_files も無効化されますので結果としてはほぼ同じになるはずです。
例外はいくつかあります。
swuで行う時の変更で、installer にない物：
- /etc/swupdate.pem (swupdate のインストール可能な証明書）の後処理がありますが、基本的にはアップデートの中身が優先されて、その上に swu に組み込まれている証明書があればそれを足すだけです。自分の鍵を必ずしてください。
- /etc/passwd と shadow の rootfs のユーザー情報が現在のシステムからコピーされます。
- /etc/sw-versions, /etc/containers/storage.conf や /etc/fstab, /etc/fw_env.config の細かい修正（1か2面側の調整）もありますが、こちらは問題にならないと思います。
逆に、swuになくてインストールディスクで作成されるファイルがいくつかあります（本来 swupdate_preserve_files で保存されます）：
- /etc/hwrevision (モデルなどの情報が入ってますので、一つのモデルでしたらコピーしていただいても問題ありません）
- /etc/fstab に /opt/firmware パーティションの追加
- （今回必要ないと思いますが） /boot/overlays.txt のハードウェア設定ファイル
- /etc/machine-id （ランダムされるだけですが、同じになっていても問題ないと思います）
- /etc/runlevels/sysinit/fsck_atlog (/var/at-log のチェックスクリプトの有効化、これも固定でもいいです）
この説明したところで、購入状態の armadillo に swudpate_preserve_files で問題になりそうなファイルがないと思いますので、その設定をしなくてもいいと思います。
単に install-if different を使っていただいて、製造の時に USB ディスクと swu ファイルだけでもいいと思います。
> ④アップデート方法
> ・顧客のネットワーク環境が不安定な可能性があるので、自動アップデートは無効とすることを想定しています
> ・アップデートが必要な場合は顧客にswuパッケージを提供して、USBメモリでアップデートしてもらうことを想定しています
> ★顧客はLinuxの知識がなくコンソールも使えない可能性があるので、書き込み中はswupdate-usb内でLEDを点滅させる等して、外見から分かるようにして頂けますとありがたいです
ATDE の /usr/share/mkswu/examples/enable_notify_led.desc を参考にしていただいて、build-rootfs の (ax2/resources)/etc/atmark/baseos.conf に NOTIFY_xx_CMD を設定していただければ LED で分かるようになります。
> ★swuパッケージに組み込むpodmanイメージのサイズを削減したいと考えています。
> https://armadillo.atmark-techno.com/blog/15288/12148
> の差分を提供する方法を検討しましたが、こちらはベースとなるpodmanイメージが同じ場合しか使用できない認識です。
おっしゃるとおりに、差分アップデートは基本的に docker/podman pull と同じ仕組みで、layer で分けているだけです。ベースになるレイヤーが変われば、上のレイヤーも使えなくなります。
なので、イメージが大きい場合はしばらく前のイメージ + 「apt update/upgrade」の差分だけで更新していただいて、合計が大きくなったらゼロから作り直すしかないですね…
> podmanイメージを圧縮して格納する方法を考えておりますが、他に案がありましたらご教示頂けますと幸いです。
podman イメージを圧縮する場合は、G4 で一同圧縮を /var/tmp で解凍してからインストールされるので、 圧縮ないままの swdesc_usb_container が一番効率がいいです。
ネットワークの場合は swdesc_embed_container しか使えないため、swu内に組み込まれてるイメージを zst で圧縮されますが、これもやっぱり一度 /var/tmp で解凍しますのであまり嬉しくない設計です。（podman のロードコマンドの制限です）
あまりおすすめしませんが、レイヤーを使わずに /var/app/volumes/rollback/myapp にコンテナの rootfs を展開して普通のファイルシステムとして運用することも可能です（set_image --rootfs /var/app/...で起動できます）
その場合はイメージが書き込み可能もなりますので、普通の debian として apt update などを実行できるようになります。ネットワークが不安定な場合はあまりべんりとは思えませんが、可能性としてあります。
何か分かりにくいことがあれば聞いてください！
よろしくお願いします。
at_dominique.m…
r_kawaiさん
先に①に答えさせていただきます。
> abos-ctrl make-installerを試していますが「No space left on device」というが発生しています。
これは大変失礼致しました。
解析までしていただいてありがとうございます。イメージが少し大きくなったことで、リサイズのチェックを通らなくなってしまいました。完全にこちらのミスでお手数をおかけしました。
make-installer にもチェックを直して、今月のアップデートでインストールディスクを再び小さくして現在の make-installer でも再び動くようにしたいと思います。
とりあえず、すぐにできる修正方法が三つあります：
- 手動でパーティションをリサイズすれば、当たり前ですが保存が成功します。abos-ctrl make-installer の最初のチェックの『イメージをそのまま使いますか？」に y を返事すればそのままリサイズしたディスクを使えます。
- 前のイメージを一度 sd カードに書き込んで、サイズのチェックが通りますので使えます。インストールされてる物が変わりませんので、製造に影響がありません。（新しいバージョンでは swu ファイルを書き込みの流れの一部としてインストールできますが、make-installer を使う場合には不要でしょう…）
armadillo:~# curl -O https://download.atmark-techno.com/armadillo-iot-g4/image/baseos-x2-installer-3.16.2-at.4.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 138M 100 138M 0 0 93.6M 0 0:00:01 0:00:01 --:--:-- 93.6M
armadillo:~# unzip baseos-x2-installer-3.16.2-at.4.zip
Archive: baseos-x2-installer-3.16.2-at.4.zip
inflating: baseos-x2-installer-3.16.2-at.4.img
inflating: baseos-x2-installer-3.16.2-at.4.img.sig
armadillo:~# dd if=baseos-x2-installer-3.16.2-at.4.img of=/dev/mmcblk1 bs=1M status=progress oflag=sync
428867584 bytes (429 MB, 409 MiB) copied, 16 s, 26.8 MB/s
421+0 records in
421+0 records out
441450496 bytes (441 MB, 421 MiB) copied, 16.6708 s, 26.5 MB/s
armadillo:~# rm -f baseos*
armadillo:~# abos-ctrl make-installer
An installer system is already available on SD card. Use it? [Y/n]
y
Would you like to create a windows partition?
That partition would only be used for customization script at the end of
install, leave at 0 to skip creating it.
Custom partition size (MB, [0] or 16 - 59886):
...- 今月末リリース予定の abos-base パッケージを添付しましたので、これを使えば書き込みが成功します。以下のログではシステムに影響しないようにメモリ上だけにインストールしました（書き込んだイメージに含まれないですし、再起動すればなくなります）
armadillo:~# tar xf abos-base-1.12-r1.apk_.tar
armadillo:~# apk add ./abos-base-1.12-r1.apk
(1/1) Installing abos-base (1.12-r1)
Executing busybox-1.35.0-r17.trigger
Executing eudev-3.2.11-r0.trigger
OK: 173 MiB in 222 packages
armadillo:~# abos-ctrl make-installer
An installer system is already available on SD card. Use it? [Y/n]
n
Download base SD card image from https://armadillo.atmark-techno.com (~200MB) ? [y/N]
WARNING: it will overwrite your sd card!!
y
Downloading installer image
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 139M 100 139M 0 0 79.1M 0 0:00:01 0:00:01 --:--:-- 79.1M
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 70 100 70 0 0 1396 0 --:--:-- --:--:-- --:--:-- 1428
Writing baseos-x2-installer-3.16.2-at.5.img to SD card (446M)
427819008 bytes (428 MB, 408 MiB) copied, 26 s, 16.4 MB/s
425+0 records in
425+0 records out
445644800 bytes (446 MB, 425 MiB) copied, 26.8825 s, 16.6 MB/s
Verifying written image is correct
420478976 bytes (420 MB, 401 MiB) copied, 11 s, 38.2 MB/s
425+0 records in
425+0 records out
445644800 bytes (446 MB, 425 MiB) copied, 11.6721 s, 38.2 MB/s
Would you like to create a windows partition?
That partition would only be used for customization script at the end of
install, leave at 0 to skip creating it.
Custom partition size (MB, [0] or 16 - 59882):
...ご迷惑をおかけして申し訳ございません。
お手数ですが、よろしくお願いします。
| ファイル | ファイルの説明 |
|---|---|
| abos-base-1.12-r1.apk_.tar | abos-ctrl make-installer を修正するアップデート |
r_kawai
マルティネ様
詳細なご回答をいただきありがとうございます。
【追加質問②】へご回答頂いた内容については確認中のため、別途返信させていただきます。
【追加質問①】へのご回答についてこちらで試したところでは、
・abos-base-1.12-r1.apk_.tarをインストール
・fdiskでSDカードのパーティションをクリア
・Custom partition sizeを聞かれたときに、最大サイズにしない
(0を指定してskipすべきでしょうか?)
でディスクイメージは作成されました。
ただ、作成したディスクイメージでG4初期化後にpodmanイメージが復元されていないように見えております。
こちらの手順ミスがあるかもしれませんが、ひとまず確認した内容について以下記載いたします。
■
>- 前のイメージを一度 sd カードに書き込んで、サイズのチェックが通りますので使えます。
こちらを試してみましたが、エラーが発生してしまいました。
SDカードには事前に
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/im…
を書き込んだ状態となります。
[2022-11-15 15:10:51.299] armadillo:/home/atmark/at-debian-image-dockerfile# podman images
[2022-11-15 15:12:02.750] REPOSITORY TAG IMAGE ID CREATED SIZE
[2022-11-15 15:12:02.755] localhost/at-debian-image XXXXX e054e055463f 2 minutes ago 2.34 GB
[2022-11-15 15:12:02.761] docker.io/library/debian bullseye ef39063a944d 5 hours ago 123 MB
[2022-11-15 15:12:37.299] armadillo:/home/atmark# lsblk
[2022-11-15 15:12:47.821] NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
[2022-11-15 15:12:47.821] mmcblk2 179:0 0 9.8G 0 disk
[2022-11-15 15:12:47.826] tqmmcblk2p1 179:1 0 300M 0 part /live/rootfs
[2022-11-15 15:12:47.834] tqmmcblk2p2 179:2 0 300M 0 part
[2022-11-15 15:12:47.838] tqmmcblk2p3 179:3 0 50M 0 part /var/log
[2022-11-15 15:12:47.838] tqmmcblk2p4 179:4 0 200M 0 part /opt/firmware
[2022-11-15 15:12:47.844] mqmmcblk2p5 179:5 0 9G 0 part /var/lib/containers/storage
[2022-11-15 15:12:47.851] /var/tmp
[2022-11-15 15:12:47.855] /var/app/volumes
[2022-11-15 15:12:47.861] /var/app/rollback/volumes
[2022-11-15 15:12:47.868] /var/lib/containers/storage_readonly
[2022-11-15 15:12:47.871] mmcblk2boot0 179:32 0 31.5M 1 disk
[2022-11-15 15:12:47.879] mmcblk2boot1 179:64 0 31.5M 1 disk
[2022-11-15 15:12:47.879] mmcblk2gp0 179:96 0 8M 0 disk
[2022-11-15 15:12:47.886] mmcblk2gp1 179:128 0 8M 0 disk /var/at-log
[2022-11-15 15:12:47.890] mmcblk2gp2 179:160 0 8M 0 disk
[2022-11-15 15:12:47.890] mmcblk2gp3 179:192 0 8M 0 disk
[2022-11-15 15:12:47.895] mmcblk1 179:224 0 14.8G 0 disk
[2022-11-15 15:12:47.902] mqmmcblk1p1 179:225 0 404M 0 part
[2022-11-15 15:12:47.902] zram0 254:0 0 1G 0 disk [SWAP]
[2022-11-15 15:15:42.331] armadillo:/home/atmark# abos-ctrl make-installer
[2022-11-15 15:15:47.116] An installer system is already available on SD card. Use it? [Y/n]
[2022-11-15 15:15:52.241] y
[2022-11-15 15:15:52.865] Copying boot image
[2022-11-15 15:15:53.039] Copying rootfs
#省略
[2022-11-15 15:16:16.846] 300+0 records in
[2022-11-15 15:16:16.846] 300+0 records out
[2022-11-15 15:16:16.846] 314572800 bytes (315 MB, 300 MiB) copied, 23.679 s, 13.3 MB/s
[2022-11-15 15:16:20.065] Copying /opt/firmware filesystem
[2022-11-15 15:16:20.215] Copying appfs
[2022-11-15 15:16:20.284] At subvol app/snapshots/volumes
[2022-11-15 15:16:20.284] At subvol app/snapshots/boot_volumes
[2022-11-15 15:16:20.293] At subvol app/snapshots/boot_containers_storage
[2022-11-15 15:16:23.456] lzop: write error: No space left on device
[2022-11-15 15:16:23.456] ERROR: Failed compressing or writing lzo file
[2022-11-15 15:18:21.640] armadillo:/home/atmark# aboc-cs-ctrarmadillo:/home/atmark# abos-ctrl --version
[2022-11-15 15:20:04.263] abos-base-1.12-r0 aarch64 {abos-base} (MIT) [installed]■
>- 今月末リリース予定の abos-base パッケージを添付しましたので、これを使えば書き込みが成功します
fdiskでSDカードのパーティションを消去し、 Custom partition sizeで最大値より小さい値を指定すると成功しました。
[2022-11-15 15:33:56.108] armadillo:/home/atmark# resizeabos-ctarmadillo:/home/atmark# abos-ctrl make-installer [2022-11-15 15:35:20.852] It looks like your SD card does not contain an installer image [2022-11-15 15:35:20.855] Download base SD card image from https://armadillo.atmark-techno.com (~200MB) ? [y/N] [2022-11-15 15:35:20.862] WARNING: it will overwrite your sd card!! [2022-11-15 15:35:22.920] y [2022-11-15 15:35:24.388] Downloading installer image [2022-11-15 15:35:24.399] % Total % Received % Xferd Average Speed Time Time Time Current [2022-11-15 15:35:24.406] Dload Upload Total Spent Left Speed #省略 [2022-11-15 15:37:02.400] % Total % Received % Xferd Average Speed Time Time Time Current [2022-11-15 15:37:02.405] Dload Upload Total Spent Left Speed [2022-11-15 15:37:02.415] 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0100 70 100 70 0 0 369 0 --:--:-- --:--:-- --:--:-- 370 [2022-11-15 15:37:03.527] Writing baseos-x2-installer-3.16.2-at.5.img to SD card (446M) #省略 [2022-11-15 15:37:31.223] 425+0 records in [2022-11-15 15:37:31.223] 425+0 records out [2022-11-15 15:37:31.223] 445644800 bytes (446 MB, 425 MiB) copied, 27.6918 s, 16.1 MB/s [2022-11-15 15:37:31.228] Verifying written image is correct #省略 [2022-11-15 15:37:42.915] 425+0 records in [2022-11-15 15:37:42.915] 425+0 records out [2022-11-15 15:37:42.915] 445644800 bytes (446 MB, 425 MiB) copied, 11.685 s, 38.1 MB/s [2022-11-15 15:37:43.003] Would you like to create a windows partition? [2022-11-15 15:37:43.003] That partition would only be used for customization script at the end of [2022-11-15 15:37:43.009] install, leave at 0 to skip creating it. [2022-11-15 15:37:43.021] Custom partition size (MB, [0] or 16 - 118207): 10000 [2022-11-15 15:39:51.371] Checking and growing installer main partition [2022-11-15 15:39:52.400] GPT data structures destroyed! You may now partition the disk using fdisk or [2022-11-15 15:39:52.406] other utilities. [2022-11-15 15:39:53.424] The operation has completed successfully. [2022-11-15 15:39:53.463] Resize device id 1 (/dev/mmcblk1p1) from 404.00MiB to max [2022-11-15 15:39:53.549] Copying boot image [2022-11-15 15:39:53.720] Copying rootfs #省略 [2022-11-15 15:40:13.343] 300+0 records in [2022-11-15 15:40:13.343] 300+0 records out [2022-11-15 15:40:13.343] 314572800 bytes (315 MB, 300 MiB) copied, 19.379 s, 16.2 MB/s [2022-11-15 15:40:16.324] Copying /opt/firmware filesystem [2022-11-15 15:40:16.427] Copying appfs [2022-11-15 15:40:16.485] At subvol app/snapshots/volumes [2022-11-15 15:40:16.485] At subvol app/snapshots/boot_volumes [2022-11-15 15:40:16.491] At subvol app/snapshots/boot_containers_storage [2022-11-15 15:43:19.706] Cleaning up and syncing changes to disk... [2022-11-15 15:43:20.193] Installer updated successfully! [2022-11-15 15:43:20.193] armadillo:/home/atmark# lslblk [2022-11-15 15:49:51.561] NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS [2022-11-15 15:49:51.561] mmcblk2 179:0 0 9.8G 0 disk [2022-11-15 15:49:51.567] tqmmcblk2p1 179:1 0 300M 0 part /live/rootfs [2022-11-15 15:49:51.573] tqmmcblk2p2 179:2 0 300M 0 part [2022-11-15 15:49:51.579] tqmmcblk2p3 179:3 0 50M 0 part /var/log [2022-11-15 15:49:51.579] tqmmcblk2p4 179:4 0 200M 0 part /opt/firmware [2022-11-15 15:49:51.583] mqmmcblk2p5 179:5 0 9G 0 part /var/lib/containers/storage_readonly [2022-11-15 15:49:51.594] /var/tmp [2022-11-15 15:49:51.594] /var/app/volumes [2022-11-15 15:49:51.601] /var/app/rollback/volumes [2022-11-15 15:49:51.607] mmcblk2boot0 179:32 0 31.5M 1 disk [2022-11-15 15:49:51.612] mmcblk2boot1 179:64 0 31.5M 1 disk [2022-11-15 15:49:51.617] mmcblk2gp0 179:96 0 8M 0 disk [2022-11-15 15:49:51.617] mmcblk2gp1 179:128 0 8M 0 disk /var/at-log [2022-11-15 15:49:51.623] mmcblk2gp2 179:160 0 8M 0 disk [2022-11-15 15:49:51.629] mmcblk2gp3 179:192 0 8M 0 disk [2022-11-15 15:49:51.629] mmcblk1 179:224 0 115.8G 0 disk [2022-11-15 15:49:51.634] tqmmcblk1p1 179:225 0 106.1G 0 part [2022-11-15 15:49:51.641] mqmmcblk1p2 179:226 0 9.8G 0 part [2022-11-15 15:49:51.641] zram0 254:0 0 1G 0 disk [SWAP] [2022-11-15 16:04:55.382] armadillo:/home/atmark# mount /dev/mmcblk1p1 /mnarmadillo:/home/atmark# mount /dev/mmcblk1p1 /mnt/ [2022-11-15 16:05:01.145] armadillo:/home/atmark# ls -l /mnarmadillo:/home/atmark# ls -l /mnt/ [2022-11-15 16:05:03.348] total 1473612 [2022-11-15 16:05:03.348] -rw-r--r-- 1 root root 1281207268 Nov 15 15:42 appfs.lzo [2022-11-15 16:05:03.359] -rw-r--r-- 1 root root 28 Nov 15 15:42 appfs.xxh [2022-11-15 16:05:03.361] drwxr-xr-x 1 root root 988 Oct 26 09:16 bin [2022-11-15 16:05:03.361] drwxr-xr-x 1 root root 660 Oct 26 09:17 boot [2022-11-15 16:05:03.372] -rw-r--r-- 1 root root 54 Nov 15 15:39 boot.filename [2022-11-15 16:05:03.375] -rw-r--r-- 1 root root 996512 Nov 15 15:39 boot.lzo [2022-11-15 16:05:03.386] -rw-r--r-- 1 root root 25 Nov 15 15:39 boot.xxh [2022-11-15 16:05:03.387] drwxr-xr-x 1 root root 0 Oct 26 09:16 dev [2022-11-15 16:05:03.387] drwxr-xr-x 1 root root 1338 Oct 26 09:17 etc [2022-11-15 16:05:03.399] -rw-r--r-- 1 root root 25034752 Nov 15 15:40 firm.squashfs [2022-11-15 16:05:03.401] -rw-r--r-- 1 root root 17 Nov 15 15:40 firm.squashfs.xxh [2022-11-15 16:05:03.413] drwxr-xr-x 1 root root 12 Oct 26 09:16 home [2022-11-15 16:05:03.413] -rw-r--r-- 1 root root 54 Nov 15 15:40 image.filename [2022-11-15 16:05:03.414] -rw-r--r-- 1 root root 201694471 Nov 15 15:40 image.lzo [2022-11-15 16:05:03.425] -rw-r--r-- 1 root root 27 Nov 15 15:40 image.xxh [2022-11-15 16:05:03.427] -rw-r--r-- 1 root root 27 Oct 26 09:17 installer.conf [2022-11-15 16:05:03.438] -rw-r--r-- 1 root root 5756 Oct 26 09:17 installer_overrides.sh.sample [2022-11-15 16:05:03.445] -rw-r--r-- 1 root root 404 Oct 26 09:17 ip_config.txt.sample [2022-11-15 16:05:03.445] drwxr-xr-x 1 root root 1766 Oct 26 09:16 lib [2022-11-15 16:05:03.447] drwxr-xr-x 1 root root 0 Oct 26 09:16 live [2022-11-15 16:05:03.458] drwxr-xr-x 1 root root 0 Oct 26 09:17 mnt [2022-11-15 16:05:03.458] drwxr-xr-x 1 root root 16 Oct 26 09:16 opt [2022-11-15 16:05:03.469] dr-xr-xr-x 1 root root 0 Oct 26 09:16 proc [2022-11-15 16:05:03.477] drwx------ 1 root root 0 Oct 26 09:16 root [2022-11-15 16:05:03.477] drwxr-xr-x 1 root root 0 Oct 26 09:16 run [2022-11-15 16:05:03.479] drwxr-xr-x 1 root root 4080 Oct 26 09:16 sbin [2022-11-15 16:05:03.490] drwxr-xr-x 1 root root 0 Oct 26 09:16 sys [2022-11-15 16:05:03.492] drwxr-xr-x 1 root root 0 Oct 26 09:16 target [2022-11-15 16:05:03.492] drwxrwxrwt 1 root root 0 Oct 26 09:16 tmp [2022-11-15 16:05:03.499] drwxr-xr-x 1 root root 68 Oct 26 09:16 usr [2022-11-15 16:05:03.499] drwxr-xr-x 1 root root 98 Oct 26 09:16 var
ちなみにですが、Custom partition sizeで最大値を指定するとエラーとなりました。
[2022-11-15 15:29:33.338] Custom partition size (MB, [0] or 16 - 118207): 118207 #省略 [2022-11-15 15:30:20.109] Copying /opt/firmware filesystem [2022-11-15 15:30:20.212] Copying appfs [2022-11-15 15:30:20.274] At subvol app/snapshots/volumes [2022-11-15 15:30:20.274] At subvol app/snapshots/boot_volumes [2022-11-15 15:30:20.281] At subvol app/snapshots/boot_containers_storage [2022-11-15 15:30:22.655] lzop: write error: No space left on device [2022-11-15 15:30:22.655] ERROR: Failed compressing or writing lzo file
■作成したディスクイメージで初期化
podman imageが復旧していないように見えています。
ディスクイメージ書き込み時に自動で復旧されるわけではなく、別途コマンド実行等が必要でしょうか。
[2022-11-15 16:18:25.968] armadillo:~# podman images [2022-11-15 16:18:37.781] REPOSITORY TAG IMAGE ID CREATED SIZE [2022-11-15 16:18:37.891] armadillo:~# podman ps -a [2022-11-15 16:18:42.217] CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES [2022-11-15 16:19:53.178] armadillo:~# podman_swarmadillo:~# podman_switch_storage --status [2022-11-15 16:19:59.464] Currently in tmpfs mode, run with --disk to switch [2022-11-15 16:19:59.464] armadillo:~# armadillo:~# podman_switch_storage --disk [2022-11-15 16:20:03.879] ERROR: Could not find appfs
また、/etc/atmark/containers/配下に格納していたconfファイルが消えていました。
(対象のconfファイルはpersist_fileしていなかったかもしれません)
[2022-11-15 16:27:48.554] armadillo:# ls -l /etc/atmark/containers/ [2022-11-15 16:28:03.921] total 3 [2022-11-15 16:28:03.921] -rw-r--r-- 1 root root 101 Oct 20 15:59 README [2022-11-15 16:28:03.921] -rw-r--r-- 1 root root 92 Oct 20 15:59 alpine.conf.example [2022-11-15 16:28:03.931] -rw-r--r-- 1 root root 577 Oct 20 15:59 at-debian-image.conf.example
書き換え時のログ(install_diskimage-20221115.log)と、その後の起動時のログ(messages_after_install_diskimage-20221115.log)を貼付いたします。
| ファイル | ファイルの説明 |
|---|---|
| install_diskimage-20221115.log | |
| messages_after_install_diskimage-20221115.log |
at_dominique.m…
r_kawaiさん
> ・Custom partition sizeを聞かれたときに、最大サイズにしない
> (0を指定してskipすべきでしょうか?)
custom partition は、 /dev/mmcblk1p2 を exfat で作って windows から installer_override.conf や swu の変更をできるためのパーティションです。
/dev/mmcblk1p1 が btrfs のため、製造担当者が linux のマシンを手元になければファイルの編集が難しいため用意したオプションです。その問題がなければ skip でいいと思います。
（ちなみに、最大のサイズを選ぶ場合は /dev/mmcblk1p2 に空き量全部を渡しますので、本来のインストーラーのパーティションはリサイズされてないと同じで容量が足りないでしたね）
> ■
> >- 前のイメージを一度 sd カードに書き込んで、サイズのチェックが通りますので使えます。
>
> こちらを試してみましたが、エラーが発生してしまいました。
> SDカードには事前に
> https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/im…
> を書き込んだ状態となります。
文章には「前のイメージ」しかかいてませんが、3.16.2-at.5 が最新のイメージでエラーの原因となっています。 3.16.2-at.4 以前のイメージなら動くはずです。
（make-installer が自動に取得するイメージも、最新のイメージです）
> ■
> >- 今月末リリース予定の abos-base パッケージを添付しましたので、これを使えば書き込みが成功します
> fdiskでSDカードのパーティションを消去し、 Custom partition sizeで最大値より小さい値を指定すると成功しました。
>
> [2022-11-15 15:40:16.427] Copying appfs > [2022-11-15 15:40:16.485] At subvol app/snapshots/volumes > [2022-11-15 15:40:16.485] At subvol app/snapshots/boot_volumes > [2022-11-15 15:40:16.491] At subvol app/snapshots/boot_containers_storage > [2022-11-15 15:43:19.706] Cleaning up and syncing changes to disk... > [2022-11-15 15:43:20.193] Installer updated successfully!
これは大丈夫そうですね。
> ■作成したディスクイメージで初期化
> podman imageが復旧していないように見えています。
> ディスクイメージ書き込み時に自動で復旧されるわけではなく、別途コマンド実行等が必要でしょうか。
必要ないはずです…
> [2022-11-15 16:19:53.178] armadillo:~# podman_swarmadillo:~# podman_switch_storage --status > [2022-11-15 16:19:59.464] Currently in tmpfs mode, run with --disk to switch > [2022-11-15 16:19:59.464] armadillo:~# armadillo:~# podman_switch_storage --disk > [2022-11-15 16:20:03.879] ERROR: Could not find appfs
このエラーも気になります。このエラーでは /var/tmp がマウントされてないので、app パーティション（/dev/mmcblk2p5)に何か問題あるかもしれません。
いただいた messages_after_install_diskimage-20221115.log に 「BTRFS: device label app devid 1 transid 33 /dev/mmcblk2p5 scanned by udevd」のメッセージがありますので、そのパーティション自体が正常に見えますが、マウントされる記録が無いのは気になります。そのすぐ後にBTRFS info のメッセージが何行かでるはずです…
インストールログも正常に見えます（コンテナイメージも書き込んだ記録があります）
/etc/fstab の中身を見せていただけますか？
> また、/etc/atmark/containers/配下に格納していたconfファイルが消えていました。
> (対象のconfファイルはpersist_fileしていなかったかもしれません)
これもおかしいですね。
同じ messages のログでも、mmcblk1p1 をなぜかマウントしているように見えます（mmcblk2p5に無かったメッセージがその名前であります）ので、何かが混乱してそのパーティションをマウントしたかもしれません？
その状態の「findmnt」があれば何か分かるかもしれません。
こちらも、提供した make-installer でイメージを作ってインストールしてみましたが再現できてません。お手数ですが、追加情報をお願いします：
- /etc/fstab の中身
- findmnt の出力
- ついでに、「cat /etc/sw-versions /var/at-log/atlog」もお願いします
よろしくお願いします
r_kawai
マルティネ様
ご確認いただきありがとうございます。
>custom partition は、 /dev/mmcblk1p2 を exfat で作って windows から installer_override.conf や swu の変更をできるためのパーティションです。
>/dev/mmcblk1p1 が btrfs のため、製造担当者が linux のマシンを手元になければファイルの編集が難しいため用意したオプションです。その問題がなければ skip でいいと思います。
>（ちなみに、最大のサイズを選ぶ場合は /dev/mmcblk1p2 に空き量全部を渡しますので、本来のインストーラーのパーティションはリサイズされてないと同じで容量が足りないでしたね）
承知いたしました。
>文章には「前のイメージ」しかかいてませんが、3.16.2-at.5 が最新のイメージでエラーの原因となっています。 3.16.2-at.4 以前のイメージなら動くはずです。
失礼しました。「前のイメージ」は私が前に使っていたイメージと勘違いしていました。
3.16.2-at.4 以前のイメージとのことで承知いたしました。
>こちらも、提供した make-installer でイメージを作ってインストールしてみましたが再現できてません。お手数ですが、追加情報をお願いします：
>- /etc/fstab の中身
>- findmnt の出力
>- ついでに、「cat /etc/sw-versions /var/at-log/atlog」もお願いします
こちら取得しましたので以下に貼付いたします。
armadillo:~# cat /etc/fstab /dev/mmcblk2gp1 /var/at-log vfat defaults 0 0 /dev/mmcblk2p4 /opt/firmware squashfs defaults 0 0 armadillo:~# LANG=C findmnt TARGET SOURCE FSTYPE OPTIONS / none overlay rw,relatime,lowerdir=/,upperdir= |-/dev devtmpfs devtmpf rw,nosuid,noexec,relatime,size=1 | |-/dev/mqueue mqueue mqueue rw,nosuid,nodev,noexec,relatime | |-/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5, | `-/dev/shm shm tmpfs rw,nosuid,nodev,noexec,relatime |-/proc proc proc rw,nosuid,nodev,noexec,relatime |-/run tmpfs tmpfs rw,nosuid,nodev,size=340628k,nr_ |-/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime | |-/sys/kernel/security securityfs securit rw,nosuid,nodev,noexec,relatime | |-/sys/kernel/config configfs configf rw,nosuid,nodev,noexec,relatime | |-/sys/fs/fuse/connections | | fusectl fusectl rw,nosuid,nodev,noexec,relatime | `-/sys/fs/cgroup none cgroup2 rw,nosuid,nodev,noexec,relatime, |-/var/at-log /dev/mmcblk2gp1 | vfat rw,relatime,fmask=0022,dmask=002 |-/opt/firmware /dev/mmcblk2p4 squashf ro,relatime `-/live none tmpfs rw,relatime `-/live/rootfs /dev/mmcblk2p1 ext4 rw,relatime armadillo:~# cat /etc/sw-versions armadillo:~# ls -l /etc/sw-versions -rw-r--r-- 1 root root 0 Nov 15 16:11 /etc/sw-versions armadillo:~# cat /var/at-log/atlog abos-ctrl make-rootfs on Tue Nov 15 15:39:53 JST 2022 4194304 252324ef42adda8c abos-ctrl make-rootfs on Tue Nov 15 15:40:16 JST 2022 314572800 404a2ac430899bbc firm f3485e7780fa22fe appfs 2367040492 e56b57fb18680855 installer.conf 8f6a853024ba7be9
r_kawai
マルティネ様
【追加質問②】についてご回答いただきありがとうございます。
以下内容についてコメントさせていただきます。
>（変更ない場合は購入時の /opt/firmware を make-installer によってコピーされますので、make-imxlibimage は開発に必要な場合（atde上にライブラリが必要）だけにおすすめします。特に問題もないので、どちらでも使ってください）
kernel、rootfsがimx_libのバージョンと依存している場合、リリース時期の違うソフトを使うとバージョン不整合が起きないか懸念していたため、自前でビルドを考えておりました。
例：手元にあるG4が2022年4月製造、弊社環境のkernel、rootfsがアットマークテクノ様10月リリースがベース、のようにバージョンが離れている場合、G4から取得したimx_libが古いことにより(または逆に新しいことにより)kernelとrootfsがおかしな動きとならないかを懸念しています。
>個人的に気になるだけですが、rootfs の変更ってどういう変更を行いましたか？
>できるだけコンテナで対応できる環境を作って、swu でいくつかの設定ファイルを置くだけでコンテナで対応していただく想定で開発していますが、
>rootfs に足りない物があったら標準のイメージを使えるようにしたいです。
ホストとコンテナの両方で使う機能の場合、基本的にはホスト側で対応するという方針でおりました。
また、ディスクイメージ書き換え後の手作業をできるだけ減らすために、端末共通の設定もあらかじめrootfsに組み込んでおきたいと考えています。
そのため、例として以下のようなファイルをrootfsに組み込むことを考えています。
・ネットワーク設定(iptablesのrules-save等)
・独自に追加したカーネルモジュール、modprobeファイル
・デフォルトで起動したいサービス(/etc/unlevels/default)
・udev rules
・独自に追加するサービス(ネットワーク関連等)
・/etc/atmark/containers配下のconf
>確認だけですが、カーネルをどうインストールしていますか？
>build-rootfs の ax2/packages から linux-at-x2 を外して、ファイルをそのまま ax2/resources に書きましたか? それか直接に build-rootfs のアップデートの後に直接に armadillo にコピーしましたか？
>カーネルにいくつかのモジュールもありますので、arch/arm64/boot/Image だけではなく、 modules_install もしているかどうかも気になります。そこの情報についても改善する余地がありますので確認していただければ助かります。
build-rootfsのax2/packagesからlinux-at-x2は外しています。
ビルドしたarch/arm64/boot/Imageやdtbはbuild-rootfsにコピーしています。また、moduleビルド後にbuild-rootfs配下ax2/resources/にmodules_installでインストールし、その後build-rootfs上でdepmodしています。
depmodはfixupで行えないか考えましたが、現状は上記の流れは手作業で行っています。
>ちなみに podmanイメージは今月まで (swuか）abos-ctrl make-installer でしか取得できませんでしたが、
>最新の build-rootfs でしたら、そこの build_image.sh も使って直接にインストールディスクを作成できます。
>v3.16-at.5 以降では ax2/image_installer/ に swu ファイルをコピーすれば、インストールディスクに含まれてインストールされます。
podmanイメージ自体をbuild-rootfsで作成できるのではなく、swuファイルからイメージを作成できるという理解でよろしいでしょうか。
>セキュリティアップデートもよく出ていますので、ネットワークに接続されているのであれば定期的なアップデートもおすすめします。
>セキュリティ以外の面では、例えば一年後に不具合でて修正しようと思った場合は、ほぼ必ず手順を忘れたり、アップデートが失敗したりしますので、定期的に行うことで本当に必要な時にスムースにできるようになると思います。
>そうは言っても、ネットワークが不安定な環境で手動アップデートが面倒のもよく分かります。難しい問題です…
ご指摘の通り定期的なアップデートは必要と考えてはおりますが、あまり頻繁にアップデートを依頼するとユーザの手間になること等もあり、どうすれば正解かは見えていないところです。
>はい、swu の base_os のアップデートと、SD カードのインストーラーによる書き込みの違いは swupdate_preserve_files に乗っているファイルのリストだけです。
>そこもマニュアルにまだ入れてませんが、mkswu の .desc ファイルの上に `swdesc_option NO_PRESERVE_FILES` を入れるか、/etc/atmark/baseos.conf に MKSWU_NO_PRESERVE_FILES=1 を設定する場合には swupdate_preserve_files も無効化されますので結果としてはほぼ同じになるはずです。
swuでもインストールディスクと同等のことができる旨承知いたしました。
基本的にはswupdate_preserve_filesに記載のファイルは変更しない見込みですが、一部(/etc/iptables/rules-save)は変更予定です。
既にG4に格納されているswupdate_preserve_filesから対象ファイルを削除し、swu経由でコピーしたい場合、swuのdescファイルに
swdesc_script update_preserve_files.sh --del /etc/iptables/rules-save
のように記載しておけばよいでしょうか。その場合、descファイル中のどこに記載すべきか(どのコマンドの前/後に記載すべきか)指定はありますでしょうか。
>ATDE の /usr/share/mkswu/examples/enable_notify_led.desc を参考にしていただいて、build-rootfs の (ax2/resources)/etc/atmark/baseos.conf に NOTIFY_xx_CMD を設定していただければ LED で分かるようになります。
承知しました。試してみたいと思います。
>おっしゃるとおりに、差分アップデートは基本的に docker/podman pull と同じ仕組みで、layer で分けているだけです。ベースになるレイヤーが変われば、上のレイヤーも使えなくなります。
>なので、イメージが大きい場合はしばらく前のイメージ + 「apt update/upgrade」の差分だけで更新していただいて、合計が大きくなったらゼロから作り直すしかないですね…
コンテナイメージをそのまま提供するよりは、ユーザ環境でコンテナをapt update等で更新してもらう方が、提供時のファイルサイズは小さくなりそうですね。
LTE回線のみしか使えない環境の場合、ダウンロード容量に制約がありそうなので、どちらの方針がよいかは検討してみたいと思います。
>podman イメージを圧縮する場合は、G4 で一同圧縮を /var/tmp で解凍してからインストールされるので、 圧縮ないままの swdesc_usb_container が一番効率がいいです。
>ネットワークの場合は swdesc_embed_container しか使えないため、swu内に組み込まれてるイメージを zst で圧縮されますが、これもやっぱり一度 /var/tmp で解凍しますのであまり嬉しくない設計です。（podman のロードコマンドの制限です）
ここでの「効率」はスピードになりますでしょうか。かなり時間に影響しますでしょうか。
また、/var/tmpに一度解凍するとありますが/var/tmpはtmpfsだと思いますので、RAMのサイズより小さいファイルしか格納できないでしょうか。
例えば圧縮前に2GB程度あるpodmanイメージをzstで圧縮してswupに組み込んだ場合、/var/tmpに2GBのファイルを解凍しようとしてエラーとなる可能性はあるでしょうか。
>あまりおすすめしませんが、レイヤーを使わずに /var/app/volumes/rollback/myapp にコンテナの rootfs を展開して普通のファイルシステムとして運用することも可能です（set_image --rootfs /var/app/...で起動できます）
set_imageはpodman_startのコマンドでしょうか。
変則的な方法になるかと思いますので現状は通常のコンテナでの運用を検討しようと思いますが、参考とさせていただきます。
at_dominique.m…
r_kawaiさん
【追加質問②】の続きです。お待たせしました。
（このスレッドは長くなりましたね…）
> kernel、rootfsがimx_libのバージョンと依存している場合、リリース時期の違うソフトを使うとバージョン不整合が起きないか懸念していたため、自前でビルドを考えておりました。
> 例：手元にあるG4が2022年4月製造、弊社環境のkernel、rootfsがアットマークテクノ様10月リリースがベース、のようにバージョンが離れている場合、G4から取得したimx_libが古いことにより(または逆に新しいことにより)kernelとrootfsがおかしな動きとならないかを懸念しています。
imx_lib は基本的にアップデートできません（ライセンス上で、弊社がアップデートとして配れません）ので、とんでもない問題がない限りはカーネルに依存しませんが、
make-installer を使う場合に手元の armadillo を保存して新しい armadillo に書き込みますのでその心配がありません。
swu のみでの最初の設定を考えたら、確かに購入した新しい imx_lib を使うことになりますので ATDE の /usr/share/mkswu/examples/firmware_update.desc を参考にして swdesc_exec_nochroot の行を自分の .desc ファイルにいれてもいいかもしれません。
> ホストとコンテナの両方で使う機能の場合、基本的にはホスト側で対応するという方針でおりました。
> また、ディスクイメージ書き換え後の手作業をできるだけ減らすために、端末共通の設定もあらかじめrootfsに組み込んでおきたいと考えています。
> そのため、例として以下のようなファイルをrootfsに組み込むことを考えています。
>
> ・ネットワーク設定(iptablesのrules-save等)
> ・独自に追加したカーネルモジュール、modprobeファイル
> ・デフォルトで起動したいサービス(/etc/unlevels/default)
> ・udev rules
> ・独自に追加するサービス(ネットワーク関連等)
> ・/etc/atmark/containers配下のconf
ありがとうございます！
iptables, udev rules やコンテナの conf 、またカーネルも差分だけでいいと思いますが、
追加のサービスは難しいですね。動作確認が必要ですね。
了解しました。説明ありがとうございました。
> build-rootfsのax2/packagesからlinux-at-x2は外しています。
> ビルドしたarch/arm64/boot/Imageやdtbはbuild-rootfsにコピーしています。また、moduleビルド後にbuild-rootfs配下ax2/resources/にmodules_installでインストールし、その後build-rootfs上でdepmodしています。
> depmodはfixupで行えないか考えましたが、現状は上記の流れは手作業で行っています。
このままでもいいと思いますが、depmod はハードウェアに依存しませんので、ATDE上でも実行できるはずです。
具体的なコマンドを確認しないといけませんが…必要でしたら聞いてください。
> >ちなみに podmanイメージは今月まで (swuか）abos-ctrl make-installer でしか取得できませんでしたが、
> >最新の build-rootfs でしたら、そこの build_image.sh も使って直接にインストールディスクを作成できます。
> >v3.16-at.5 以降では ax2/image_installer/ に swu ファイルをコピーすれば、インストールディスクに含まれてインストールされます。
>
> podmanイメージ自体をbuild-rootfsで作成できるのではなく、swuファイルからイメージを作成できるという理解でよろしいでしょうか。
はい。
abos-ctrl make-installer ではちょっとズルして、appfs のコンテナのストレージの subvolume をまるごとコピー（btrfs send)しますが、build-rootfs で rootfs を作成する場合は使えません。
方法としては、 https://armadillo.atmark-techno.com/forum/armadillo/13546 の用に installer_overrides.sh の postinstall に podman load を直接に使うか swu しかないです。
> swuでもインストールディスクと同等のことができる旨承知いたしました。
> 基本的にはswupdate_preserve_filesに記載のファイルは変更しない見込みですが、一部(/etc/iptables/rules-save)は変更予定です。
> 既にG4に格納されているswupdate_preserve_filesから対象ファイルを削除し、swu経由でコピーしたい場合、swuのdescファイルに
>
> swdesc_script update_preserve_files.sh --del /etc/iptables/rules-save >
> のように記載しておけばよいでしょうか。その場合、descファイル中のどこに記載すべきか(どのコマンドの前/後に記載すべきか)指定はありますでしょうか。
デフォルトの swupdate_preserve_files はどれも新しい rootfs を展開する前にコピーされてますので、rootfs から削除しない限りは特に対応がいらないと思います。（いつか、iptables を外すと考えたら空のファイルでも優先されます）
念のために swupdate_preserve_files から削除したい場合はそのコマンドでもいいんですが、/etc/swupdate_preserve_files も自分によってコピーされるだけですので、ax2/resources にコピーして編集していただいても問題ないです。
一応、mkswu によって（/usr/share/mkswu/scripts/pre_rootfs.sh) で swupdate_preserve_files のリストの更新もありますが、PRESERVE_FILES_VERSION をチェックして追加するだけですので、その行を消さない限りは消した行が戻りません。アップデートを完全に無効化する仕組みもないですので、汚いやりかたですが、「PRESERVE_FILES_VERSION 99999」などに変更したら追加のルールもありません。
> >おっしゃるとおりに、差分アップデートは基本的に docker/podman pull と同じ仕組みで、layer で分けているだけです。ベースになるレイヤーが変われば、上のレイヤーも使えなくなります。
> >なので、イメージが大きい場合はしばらく前のイメージ + 「apt update/upgrade」の差分だけで更新していただいて、合計が大きくなったらゼロから作り直すしかないですね…
>
> コンテナイメージをそのまま提供するよりは、ユーザ環境でコンテナをapt update等で更新してもらう方が、提供時のファイルサイズは小さくなりそうですね。
> LTE回線のみしか使えない環境の場合、ダウンロード容量に制約がありそうなので、どちらの方針がよいかは検討してみたいと思います。
コンテナイメージを使う場合は安全性を上げる変わりにデータの量が大きくなりますね。
アップデートを USB で提供していたらサイズの問題は多少なくなりますが、これからはネットワークも考えていますね？
安全性は、/var/app/rollback/volumes を使って mkswu の swdesc_command_nochroot で頑張ればある程度の保証はできますが、apt のアップデートを USB で提供するのは難しいので、USBアップデートを基本にしたら逆にデータの量が増えそうですね…
独り言で考えてますが、差分アップデートを podman build の --squash-all オプションに合わせたら永遠に使いつづけそうで何かできるかもしれないですね…
すみません、この点は今後の課題でもありますが、「ストレージの半分ぐらいを使うまで差分アップデートで、イメージが大きくなったら改めてゼロから」が今のおすすめです。
今回は差分をネットワークで行って、大きいアップデートだけに USB を使うのも考えられますね。
> >podman イメージを圧縮する場合は、G4 で一同圧縮を /var/tmp で解凍してからインストールされるので、 圧縮ないままの swdesc_usb_container が一番効率がいいです。
> >ネットワークの場合は swdesc_embed_container しか使えないため、swu内に組み込まれてるイメージを zst で圧縮されますが、これもやっぱり一度 /var/tmp で解凍しますのであまり嬉しくない設計です。（podman のロードコマンドの制限です）
>
> ここでの「効率」はスピードになりますでしょうか。かなり時間に影響しますでしょうか。
> また、/var/tmpに一度解凍するとありますが/var/tmpはtmpfsだと思いますので、RAMのサイズより小さいファイルしか格納できないでしょうか。
> 例えば圧縮前に2GB程度あるpodmanイメージをzstで圧縮してswupに組み込んだ場合、/var/tmpに2GBのファイルを解凍しようとしてエラーとなる可能性はあるでしょうか。
/var/tmp は btrfs (appfs の一部）です。
スピードの問題より、単純にサイズの問題ですね。
例えば、現在のコンテナが 3GB で、新しい 3GB のコンテナを買い込もうとする場合は、一度コピーしたら確実に失敗します。USB を直接に使うことでアップデートが可能になります。
（アップデートは A/B のため、前のコンテナをすぐに削除しません。削除してから書き込む場合は、一度コンテナを消すアップデートを入れてから再びコンテナを追加する必要がありますし、失敗の場合も戻れなくなります）
スピードとしては試してませんが、USB ディスクが遅い場合でしたら逆に圧縮してコピーさせた方が早いかもしれません。サイズの問題がなければ、swdesc_embed_container で試してみてください。 embed の場合は zstd で圧縮されます。
(ZSTD_CLEVEL の変数で圧縮も強くさせます。デフォルトは zstd のデフォルトの 3 ですが、例えば「export ZSTD_LEVEL=10; mkswu xxx.desc」でファイルがかなり小さくなると思います。その分作成が遅くなりますがよろしければ試してみてください）
> >あまりおすすめしませんが、レイヤーを使わずに /var/app/volumes/rollback/myapp にコンテナの rootfs を展開して普通のファイルシステムとして運用することも可能です（set_image --rootfs /var/app/...で起動できます）
> set_imageはpodman_startのコマンドでしょうか。
> 変則的な方法になるかと思いますので現状は通常のコンテナでの運用を検討しようと思いますが、参考とさせていただきます。
はい、podman_start のコマンドです: https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
podman run の --rootfs と同じ使い方です。
よろしくお願いします。
at_dominique.m…
r_kawaiさん
> armadillo:~# cat /etc/fstab > /dev/mmcblk2gp1 /var/at-log vfat defaults 0 0 > /dev/mmcblk2p4 /opt/firmware squashfs defaults 0 0
これはおかしいですね…まるで /etc/fstab が make-installer で保存した rootfs に入ってないように見えます。
本来ならはこういう中身があるはずです：
/dev/root / ext4 ro 0 0 tmpfs /tmp tmpfs nosuid,nodev 0 0 /dev/mmcblk2p3 /var/log ext4 defaults,noatime 0 0 /dev/mmcblk2p5 /var/lib/containers/storage_readonly btrfs compress=zstd,discard=async,noatime,subvol=boot_0/containers_storage 0 0 /dev/mmcblk2p5 /var/app/rollback/volumes btrfs compress=zstd,discard=async,noatime,subvol=boot_0/volumes 0 0 /dev/mmcblk2p5 /var/app/volumes btrfs compress=zstd,discard=async,noatime,subvol=volumes 0 0 /dev/mmcblk2p5 /var/tmp btrfs compress=zstd,discard=async,noatime,subvol=tmp0 0 /dev/mmcblk2gp1 /var/at-log vfat defaults 0 0 /dev/mmcblk2p4 /opt/firmware squashfs defaults 0 0
なので、installer で追加された at-log / firmware だけがあって、元の rootfs にあるはずの部分が全部抜けましたね…
この場合にもっと早くエラーさせたいと思いますが、原因がなぞのままですね…
> armadillo:~# LANG=C findmnt > TARGET SOURCE FSTYPE OPTIONS > / none overlay rw,relatime,lowerdir=/,upperdir > `-/live/rootfs /dev/mmcblk2p1 ext4 rw,relatime
こちらはただしですね。sd カードもマウントされてないので、間違ってそちらの rootfs を使ってることもないでしょう。
> armadillo:~# cat /etc/sw-versions > armadillo:~# ls -l /etc/sw-versions > -rw-r--r-- 1 root root 0 Nov 15 16:11 /etc/sw-versions
これも、最低でも boot (ファイルのバージョン）と base_os (/etc/atmark-release の中身)で初期化されるはずですよね…
rootfs の故障で /etc/atmark-release がない場合は base_os を書かないこともありますが、 boot がないことを考えれません…
あ！そこの原因が分かりました！ busybox sed は、filesystem の容量がなくなってもエラーしません！！！！
armadillo:/tmp# strace -f sed -i -e 's/.*/bad/' bar
...
writev(3, [{iov_base="bad\n", iov_len=4}, {iov_base=NULL, iov_len=0}], 2) = -1 ENOSPC (No space left on device)
close(3) = 0
munmap(0xffffaf22e000, 4096) = 0
renameat(AT_FDCWD, "barhchojN", AT_FDCWD, "bar") = 0
exit_group(0) = ?
+++ exited with 0 +++「まったく問題ない」と… がっかりです。fstab も同じ理由でなくなりましたね。
busybox sed もこれから直します………
お手数ですが、もう一度アットマークのインストールディスクでインストールして、swu で baseos の更新の状態を確認したいですが、よろしいでしょうか？
swupdate で baseos などのファイルを書き込む時に ENOSPC のエラーはちゃんと確認しているはずですので、swuの書き込みが無事に成功したと思いますが、installer の処理で少しだけ（100KB程度でいいと思います）の空き容量が必要です。
自分の rootfs を書き込んだ後の「df /live/rootfs」を確認したいと思います。
よろしくお願いします。
r_kawai
マルティネ様
> お手数ですが、もう一度アットマークのインストールディスクでインストールして、swu で baseos の更新の状態を確認したいですが、よろしいでしょうか？
こちらは別途確認して連絡させていただきたいと思います。
お忙しいところ何度も申し訳ありませんが、追加で質問となります。
(当初の話題とずれてきている気もしますが、ひとまずこのスレッドで確認させてください)
①build-rootfs/ax2/resourcesに含めてはいけないファイルはあるでしょうか
②書き換え時にsw-versionsが更新されるタイミングはいつとなるでしょうか
ドキュメントに既に記載がありましたら申し訳ありません。
確認した内容は以下となります。
■G4側
build-rootfs/ax2/resources/etc/atmark/containersにコンテナ起動用のconfファイルを格納してrootfsを作成し、そのrootfsを組み込んだswuで書き換えを行おうとしたところ以下のエラーが発生しました。
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/im…
で初期化した後にswuアップデートしています。
armadillo:~# tail -n 20 /var/log/messages ... Nov 16 15:32:11 armadillo user.info swupdate: RUN [read_lines_notify] : Updating base os: copying swupdate_preserve_files Nov 16 15:32:11 armadillo user.info swupdate: RUN [read_lines_notify] : Waiting for btrfs to flush deleted subvolumes Nov 16 15:32:18 armadillo user.info swupdate: RUN [read_lines_notify] : Removing unused containers Nov 16 15:32:19 armadillo user.err swupdate: FAILURE ERROR : image localhost/at-debian-image:XXXXX in /target/etc/atmark/containers/XXXXX.conf not found in image store ! Nov 16 15:32:19 armadillo user.err swupdate: FAILURE ERROR : ---------------------------------------------- Nov 16 15:32:19 armadillo user.err swupdate: FAILURE ERROR : /!\ cleanup of old images failed: mismatching configuration/container update? Nov 16 15:32:19 armadillo user.err swupdate: FAILURE ERROR : ---------------------------------------------- Nov 16 15:32:20 armadillo user.err swupdate: FAILURE ERROR : Command failed: sh -c 'sh $1 ' -- /var/tmp/swupdate-usb.A2VBaT//scripts_post.sh.zst Nov 16 15:32:20 armadillo user.err swupdate: FAILURE ERROR : Error streaming scripts_post.sh.zst Nov 16 15:32:20 armadillo user.err swupdate: FATAL_FAILURE Image invalid or corrupted. Not installing ...
/targetに2面をマウントして、そちらに新しいswuパッケージを書き込むと考えておりますが、
上記エラー後に2面側を確認すると、新しいカーネルモジュール(5.10.149-g4a2ff5842a97)は格納されていたので、途中までは書き換えされている認識です。
ただ、sw-versionsは更新されてないように見えています。
sw-versionsは書き換えが成功したタイミングで更新されるでしょうか。
armadillo:~# cat /etc/sw-versions base_os 3.16.2-at.5 boot 2020.04-at10 armadillo:~# abos-ctrl mount-old Mounted /dev/mmcblk2p2 to /target successfully. Unmount it with 'umount -R /target' when done armadillo:~# cat /etc/sw-versions base_os 3.16.2-at.5 boot 2020.04-at10 armadillo:~# cat /etc/sw-versions base_os 3.16.2-at.5 boot 2020.04-at10 armadillo:~# ls -l /lib/modules/ total 1 drwxr-xr-x 3 root root 1024 Oct 26 09:16 5.10.149-2-at armadillo:~# ls -l /target/lib/modules total 1 drwxr-xr-x 3 root root 1024 Nov 16 11:56 5.10.149-g4a2ff5842a97
■ATDE9側
build-rootfs、descファイルは以下のようになっています。
atmark@atde9:~/work/G4/build-rootfs$ cat alpine-version
v3.16
atmark@atde9:~/work/G4/build-rootfs$ cat atmark-version
at.5.XXXXX.v1
atmark@atde9:~/work/G4/build-rootfs$ ls ax2/resources/etc/atmark/containers/
README XXXXX.conf
1 atmark@atde9:~/mkswu$ cat initial_setup.desc
# Initial update is done with the onetime public key and no encryption, override used keys
swdesc_option PRIVKEY="$SCRIPT_DIR/swupdate-onetime-public.key"
ORIG_PUBKEY="$PUBKEY"
swdesc_option PUBKEY="$SCRIPT_DIR/swupdate-onetime-public.pem"
ORIG_ENCRYPT_KEYFILE="$ENCRYPT_KEYFILE"
swdesc_option ENCRYPT_KEYFILE=""
swdesc_option component=extra_os.initial_setup version=2
# Set our own swupdate certificate.
# change the '>>' to '>' if you do not want to keep the Armadillo
# Base OS update certificate. You will no longer be able to update
# directly from atmark-techno.com servers.
swdesc_exec "$ORIG_PUBKEY" 'cat $1 > /etc/swupdate.pem'
# If encryption is setup, also send encryption key
if [ -n "$ORIG_ENCRYPT_KEYFILE" ]; then
swdesc_files --dest /etc "$ORIG_ENCRYPT_KEYFILE"
swdesc_command \
"sed -i -e 's/# aes-key-file/aes-key-file/' /etc/swupdate.cfg"
fi
# Set your own passwords for root and atmark users.
# /!\ The install will fail if either passwords are left unset
# You can generate your own hash with the following command:
# python3 -c 'import crypt,getpass; print(crypt.crypt(getpass.getpass(), crypt.METHOD_SHA512))'
# and update the part within the inner quotes e.g.
# "usermod -p '"'$6$hfq6eDj4DpwIbn./$ER9tNgX0BYM1WDpYkV2CsI5tK3BWLIjjhbzJ5qlz8QooDJvwfM39KPDr4GKbKQzQB8TzMwlFwBRIekdENJ1/3.'"' root"
# You can also lock the account, e.g.
# "usermod -L atmark"
swdesc_command \
"usermod -p '"'$6$51kNOtS0v8kBlKZS$iD/KxM/Uete9rE98.pJeXQqYd3NYXJytpCJK.IFvp3km4yq0JL83N4KmryImXYgntG6v/knJO5c383Oa/G78T.'"' root" \
"usermod -L atmark"
# uncomment if you would like to poweroff the system after the update is complete
#POST_ACTION=poweroff
atmark@atde9:~/mkswu$ cat OS_update.desc
# boot image can be generated with atmark imx-boot script
#swdesc_boot imx-boot-2020.04-at1_armadillo_x2
swdesc_boot /home/atmark/work/G4/imx-boot/image/imx-boot_armadillo_x2_2020.04-at10
# base OS is a tar that will be extracted on a blank filesystem,
# after copying just a few key config files.
#
# OS updates are only installed if version is greater than previous update
# so if you install your own updates atmark-techno provided Armadillo Base OS
# updates might not get installed
swdesc_tar --install-if different "/home/atmark/work/G4/build-rootfs/baseos-x2-3.16.3-at.5.XXXXX.v1.20221116.tar.zst" \
--version base_os 3.16.3-at.5.XXXXX.v1 \
--preserve-attributesmkswuバージョンは以下となります。本日アップデートしています。
atmark@atde9:~/work/G4/build-rootfs$ mkswu --version mksvu バージョン 4.6
/usr/share/mkswu/scripts/post_appfs.sh
の以下のコードで古いイメージを削除しようとしてエラーとなっているかと思いますが、初回swu書き込み時はpodmanイメージが存在していない状態ですが、以下処理は必要でしょうか。
cleanup_appfs() {
local dev basemount
local cleanup_fail="--fail-missing"
if grep -q 'graphroot = "/var/lib/containers/storage' /etc/containers/storage.conf 2>/dev/null; then
# make sure mount point exists in destination image
mkdir -p /target/var/lib/containers/storage
# .. and do not complain if an image is not in readonly store
cleanup_fail=""
fi
stdout_info echo "Removing unused containers"
stdout_info "$SCRIPTSDIR/podman_cleanup" --storage /target/var/lib/containers/storage_readonly \
--confdir /target/etc/atmark/containers $cleanup_fail \
|| error "cleanup of old images failed: mismatching configuration/container update?"at_dominique.m…
r_kawaiさん
> ①build-rootfs/ax2/resourcesに含めてはいけないファイルはあるでしょうか
インストール方法によります。
「普通」の installer や mkswu に使う場合には特に追加ファイルはいりません
mkswu で swupdate_preserve_files を無効にした場合は、先日リストしたファイル類ぐらいですかね…あの時に言ったように、あまりおすすめしません。
> ②書き換え時にsw-versionsが更新されるタイミングはいつとなるでしょうか
installer の途中に base_os/boot を更新しますが、swupdate の場合は swupdate の最後の処理となります。
（なので、以下のエラーの場合はファイルの中身を展開したとしても、sw-versionsがまだ更新されてません。エラーしたので、OSとして使えません）
そのエラーについてはそちらでもうちょっと説明します。
> Nov 16 15:32:19 armadillo user.err swupdate: FAILURE ERROR : image localhost/at-debian-image:XXXXX in /target/etc/atmark/containers/XXXXX.conf not found in image store !
>
> post_appfs.sh の以下のコードで古いイメージを削除しようとしてエラーとなっているかと思いますが、初回swu書き込み時はpodmanイメージが存在していない状態ですが、以下処理は必要でしょうか。
このメッセージを日本語にすると、「/etc/atmark/containers のコンフィグファイルに xxx を起動するように設定してありますが、そのコンテナのイメージがないために起動させません」というエラーです。
podman_cleanup で古いイメージの掃除のスクリプトですが、掃除の問題ではなく、次の再起動のエラーを防ぐためですね。その OS の状態で起動しても、アプリケーションが動かないので最初からアップデートを失敗させた方が分かりやすいと考えていました。
アップデートに swdesc_usb_container も追加したら動きますが、何か別けてアップデートを行いたい理由がありますか？
別ける必要があったら、ax2/resources から /etc/atmark/containers のファイルも外していただいて、コンテナを入れる swu に swdesc_files でそのコンフィグだけを追加する形でどうでしょうか？
（一応、オプションでチェックを外す事も技術的には簡単ですが、できればオプションをこれ以上あまり増やしたくないですね…アップデートの仕組みがすでに充分複雑だと思います。）
よろしくお願いします。
r_kawai
マルティネ様
当方からの色々な質問についてお忙しいなかご回答いただきありがとうございます。大変勉強になり助かります。
ご回答頂いた内容については確認させて頂きますが、私の方で基本的な知識(btrfs、mkswu、swupdate等)について不足しているため、再度質問させて頂くかもしれません。
お手数をおかけしてしまい申し訳ありませんが、その際はよろしくお願いいたします。
ちなみに、本日10:14にマルティネ様のコメントがメールで送信されてきましたが、その内容がスレッドには登録されていないようです。(スレッドが長すぎるから？)
再度質問がある場合は別途スレッド作成させて頂く予定でおります。
at_dominique.m…
r_kawaiさん
> ご回答頂いた内容については確認させて頂きますが、私の方で基本的な知識(btrfs、mkswu、swupdate等)について不足しているため、再度質問させて頂くかもしれません。
いいえいいえ、こちらも意見をいただいて助かります。
Armadillo Base OS はまだ新しいのでドキュメンテーションも使い方の例が少ないと思いますので、お客様の使い方を参考にして役に立ちそうな情報を広げたいと思います。
> ちなみに、本日10:14にマルティネ様のコメントがメールで送信されてきましたが、その内容がスレッドには登録されていないようです。(スレッドが長すぎるから？)
> 再度質問がある場合は別途スレッド作成させて頂く予定でおります。
返事したコメントのすぐしたになったようですので、スレッドの真ん中に登録されました。
この URL で表示できると思います： https://armadillo.atmark-techno.com/forum/armadillo/13485#comment-12102
長いスレッドは使いにくいので、別途でいいと思います。
よろしくお願いします。
at_dominique.m…
2022年11月14日 10時48分
r_kawai さん、
お世話になっています、
アットマークテクノのマルティネです。
結論から言うと、swupdate がその2面目を作ります。
初期化でインストールスピードを優先するために rootfs_0 面しか書きませんが、swupdate を実行するときに rootfs_0 の中身を rootfs_1 にコピーして使えるようになります。
なので、
- 初期化状態で mount-old を使えませんエラーは現在の設計どおりです。
- swupdate を実行する際に、2面側をそのまま使えるかを確認するためにマウントしようとして、その時に「exFAT-fs」と「F2FS-fs」のエラーがでるのも、普通です。
いただいたログでは、そのエラーの後にちゃんと「Updating base os」のメッセージのところで2面側を作ったはずです。
そのの「Waiting for btrfs to flush deleted subvolumes」で少し時間かかることもありますが、数秒すれば続くはずで、その後は swu の中身をインストールするはずですがその後のメッセージがないですね… ログでは何も行っていませんが、USBディスクを挿した後に何かなさいましたか？
swupdate がその段階で失敗すればログも出力はずですし、成功の場合にもメッセージがありますので、気になりますね。
お手数ですが、失敗を再現できるようであれば、失敗した後（か自動アップデートを無効化するためにサブディレクトリに置いて）に以下のコマンドで試していただけますか？
手動で実行してかつ swupdate の -v オプションで何かが分かるかもしれません。
また、いただいたコメントで確かに dmesg の exFAT/F2FS エラーが紛らわしと思って、出力させないようにしたいと思います。11 月末のアップデート以降のインストールディスクが必要になりますが、ご連絡いただいてとても助かります。
実行中のログももう少し増やした方がいいと思って、今後のバージョンにステップ毎にいいメッセージを出力できないか調べてみます。
今の問題には関係ないですし、もう少し先のことですが、2面側が使えない状態の場合に現在の OS をコピーする仕組みも準備中です。アップデートの後に、攻撃者が前のバージョンに戻れないための安全装置ですが、初期化インストール直後の起動にも使えそうです。
よろしくお願いします。