yasuda0108
2022年5月12日 13時14分
podman_switch_storage --tmpfs
にて、読み取り専用で動作させようと考えております。
--diskで作成したイメージを--tmpfsに変更すると、下記イメージが使用できない状態になります。
armadillo:~# podman_switch_storage --status Currently in disk mode, run with --tmpfs to switch armadillo:~# podman images REPOSITORY TAG IMAGE ID CREATED SIZE R/O localhost/gk_moni v0.03 5b07177c9ff3 Less than a second ago 1.95 GB false localhost/gk_moni v0.02 7f25bba9ade6 Less than a second ago 1.85 GB true localhost/gk-ioctrl v0.00 060cb650a022 Less than a second ago 234 MB true localhost/gk_ioctrl v0.01 bf808cb7534c Less than a second ago 234 MB false armadillo:~# podman_switch_storage --status Currently in tmpfs mode, run with --disk to switch armadillo:~# podman images REPOSITORY TAG IMAGE ID CREATED SIZE R/O localhost/gk_moni v0.02 7f25bba9ade6 4 weeks ago 1.85 GB true localhost/gk-ioctrl v0.00 060cb650a022 4 weeks ago 234 MB true
R/Oをfalse→trueにすればよいと思うのですが、どの様に変更すれば良いでしょうか。
コメント
yasuda0108
ご丁寧に解説頂き大変ありがとうございます。
--tmpfsと--diskで表示されるコンテナが異なる件、内容理解いたしました。
mkswuを使用してtarファイルを送信しimageを導入しようと試みておりますが、下記の通り、容量が足らずエラーとなってしまいます。
解決方法について案がありましたらご教示いただけますでしょうか。
armadillo:~# podman images REPOSITORY TAG IMAGE ID CREATED SIZE R/O localhost/gk_moni v0.02 7f25bba9ade6 Less than a second ago 1.85 GB true localhost/gk-ioctrl v0.00 060cb650a022 Less than a second ago 234 MB true localhost/gk_moni v0.04 07824c3dd9d3 Less than a second ago 1.9 GB false localhost/gk_ioctrl v0.01 bf808cb7534c Less than a second ago 234 MB false armadillo:~# podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 99784ad26b37 localhost/gk_ioctrl:v0.01 ./initIO.sh 21 seconds ago Exited (0) 20 seconds ago io-auto 0e4d83be529c localhost/gk_moni:v0.04 /bin/bash 20 seconds ago Exited (137) Less than a second ago qt-auto 64445e248adb localhost/gk_moni:v0.02 /bin/bash Less than a second ago Exited (0) Less than a second ago cvTest 6dc821a0cd3e localhost/gk-ioctrl:v0.00 /bin/bash Less than a second ago Exited (0) Less than a second ago ioCtrl armadillo:~# df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/root ext4 272M 204M 49M 81% /live/rootfs devtmpfs devtmpfs 10M 0 10M 0% /dev tmpfs tmpfs 333M 844K 332M 1% /run shm tmpfs 831M 84K 831M 1% /dev/shm cgroup_root tmpfs 10M 0 10M 0% /sys/fs/cgroup none tmpfs 831M 20K 831M 1% /live none overlay 831M 20K 831M 1% / tmpfs tmpfs 831M 0 831M 0% /tmp /dev/mmcblk2p3 ext4 42M 430K 38M 2% /var/log /dev/mmcblk2p5 btrfs 9.1G 952M 7.9G 11% /var/lib/containers/storage_readonly /dev/mmcblk2p5 btrfs 9.1G 952M 7.9G 11% /var/app/rollback/volumes /dev/mmcblk2p5 btrfs 9.1G 952M 7.9G 11% /var/app/volumes /dev/mmcblk2p5 btrfs 9.1G 952M 7.9G 11% /var/tmp /dev/mmcblk2gp1 vfat 8.0M 2.0K 8.0M 1% /var/at-log /dev/mmcblk2p4 squashfs 24M 24M 0 100% /opt/firmware /dev/mmcblk2p5 btrfs 9.1G 952M 7.9G 11% /var/lib/containers/storage armadillo:~# podman_partial_image -o gk_moni_v004.tar gk_moni:v0.04 tar: write error: No space left on device Could not extract images: gk_moni:v0.04
at_dominique.m…
> mkswuを使用してtarファイルを送信しimageを導入しようと試みておりますが、下記の通り、容量が足らずエラーとなってしまいます。
df の出力をみると、 /var/tmp に充分容量ありますので、そちらかUSBメモリで実行すればどうでしょうか？
/root はoverlayでtmpfsになってますので、800MBぐらいしか使えません。
armadillo:~# cd /var/tmp armadillo:/var/tmp# podman_partial_image -o gk_moni_v004.tar gk_moni:v0.04 か armadillo:~# mount /dev/sda1 /mnt armadillo:~# podman_partial_image -o /mnt/gk_moni_v004.tar gk_moni:v0.04 armadillo:~# umount /mnt
よろしくお願いします
yasuda0108
USBメモリは事前に試みておりましたが、以下の通り同様のエラーが出ておりました。
armadillo:~# mount -t vfat /dev/sda1 /mnt armadillo:~# podman_partial_image -o /mnt/gk_moni_v004.tar gk_moni:v0.04 tar: write error: No space left on device Could not extract images: gk_moni:v0.04 armadillo:~# df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/root ext4 272M 204M 49M 81% /live/rootfs devtmpfs devtmpfs 10M 0 10M 0% /dev tmpfs tmpfs 333M 844K 332M 1% /run shm tmpfs 831M 84K 831M 1% /dev/shm cgroup_root tmpfs 10M 0 10M 0% /sys/fs/cgroup none tmpfs 831M 48K 831M 1% /live none overlay 831M 48K 831M 1% / tmpfs tmpfs 831M 0 831M 0% /tmp /dev/mmcblk2p3 ext4 42M 447K 38M 2% /var/log /dev/mmcblk2p5 btrfs 9.1G 1.2G 7.7G 14% /var/lib/containers/storage_readonly /dev/mmcblk2p5 btrfs 9.1G 1.2G 7.7G 14% /var/app/rollback/volumes /dev/mmcblk2p5 btrfs 9.1G 1.2G 7.7G 14% /var/app/volumes /dev/mmcblk2p5 btrfs 9.1G 1.2G 7.7G 14% /var/tmp /dev/mmcblk2gp1 vfat 8.0M 2.0K 8.0M 1% /var/at-log /dev/mmcblk2p4 squashfs 24M 24M 0 100% /opt/firmware /dev/mmcblk2p5 btrfs 9.1G 1.2G 7.7G 14% /var/lib/containers/storage /dev/sda1 vfat 29G 5.0G 24G 18% /mnt
また、お教えいただいた通り、/var/tmpで実施してみましたが、数分間待機後プロセスが強制終了されてしまいました。
何か原因はわかりますでしょうか？
armadillo:/var/tmp# podman_partial_image -o gk_moni_v004.tar gk_moni:v0.04 [ 2874.451176] podman invoked oom-killer: gfp_mask=0x500cc2(GFP_HIGHUSER|__GFP_ACCOUNT), order=0, oom_score_adj=0 [ 2874.461218] CPU: 2 PID: 1985 Comm: podman Not tainted 5.10.109-0-at #1-Alpine [ 2874.468358] Hardware name: Atmark-Techno Armadillo-IoT Gateway G4 Board (DT) [ 2874.475410] Call trace: [ 2874.477867] dump_backtrace+0x0/0x1a0 [ 2874.481537] show_stack+0x18/0x24 [ 2874.484860] dump_stack+0xc8/0x104 [ 2874.488267] dump_header+0x48/0x1f0 [ 2874.491760] oom_kill_process+0x1f0/0x1f4 [ 2874.495774] out_of_memory+0xe4/0x330 [ 2874.499440] __alloc_pages_nodemask+0xb00/0xbf0 [ 2874.503976] pipe_write+0x2c8/0x720 [ 2874.507471] new_sync_write+0x174/0x184 [ 2874.511308] vfs_write+0x244/0x2a4 [ 2874.514712] ksys_write+0xdc/0xf4 [ 2874.518027] __arm64_sys_write+0x1c/0x2c [ 2874.521953] el0_svc_common.constprop.0+0x78/0x1c4 [ 2874.526747] do_el0_svc+0x1c/0x2c [ 2874.530064] el0_svc+0x14/0x20 [ 2874.533120] el0_sync_handler+0xb0/0xb4 [ 2874.536958] el0_sync+0x180/0x1c0 [ 2874.540291] Mem-Info: [ 2874.542570] active_anon:36719 inactive_anon:295922 isolated_anon:0 [ 2874.542570] active_file:42 inactive_file:84 isolated_file:0 [ 2874.542570] unevictable:0 dirty:0 writeback:0 [ 2874.542570] slab_reclaimable:2436 slab_unreclaimable:7838 [ 2874.542570] mapped:76 shmem:315205 pagetables:328 bounce:0 [ 2874.542570] free:7622 free_pcp:400 free_cma:2037 [ 2874.574554] Node 0 active_anon:146876kB inactive_anon:1183688kB active_file:28kB inactive_file:464kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:148kB dirty:0kB writeback:0kB shmem:1260820kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 18432kB writeback_tmp:0kB kernel_stack:2624kB all_unreclaim able? no [ 2874.602900] DMA free:30740kB min:22528kB low:28160kB high:33792kB reserved_highatomic:0KB active_anon:146876kB inactive_anon:1183688kB active_file:704kB in active_file:180kB unevictable:0kB writepending:0kB present:2064384kB managed:1700772kB mlocked:0kB pagetables:1312kB bounce:0kB free_pcp:1576kB local_pcp:0kB free_cma:8148kB [ 2874.631848] lowmem_reserve[]: 0 0 0 0 [ 2874.635530] DMA: 1844*4kB (UMEC) 714*8kB (UMEC) 305*16kB (UEC) 144*32kB (UEC) 66*64kB (UEC) 9*128kB (UEC) 6*256kB (UME) 0*512kB 1*1024kB (U) 0*2048kB 0*409 6kB 0*8192kB 0*16384kB 0*32768kB = 30512kB [ 2874.653139] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ 2874.661850] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ 2874.670423] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 2874.678878] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ 2874.687158] 315453 total pagecache pages [ 2874.691091] 0 pages in swap cache [ 2874.694423] Swap cache stats: add 0, delete 0, find 0/0 [ 2874.699658] Free swap = 0kB [ 2874.702551] Total swap = 0kB [ 2874.705437] 516096 pages RAM [ 2874.708328] 0 pages HighMem/MovableOnly [ 2874.712164] 90903 pages reserved [ 2874.715402] 196608 pages cma reserved [ 2874.719071] 0 pages hwpoisoned [ 2874.722133] Tasks state (memory values in pages): [ 2874.726844] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [ 2874.735496] [ 639] 0 639 904 90 53248 0 0 rngd [ 2874.743620] [ 766] 0 766 1389 116 53248 0 0 udevd [ 2874.751817] [ 1273] 102 1273 415 43 45056 0 0 dbus-daemon [ 2874.760535] [ 1284] 0 1284 417 16 45056 0 0 syslogd [ 2874.768900] [ 1320] 0 1320 264 19 45056 0 0 supervise-daemo [ 2874.777960] [ 1321] 0 1321 5198 537 77824 0 0 NetworkManager [ 2874.786932] [ 1432] 0 1432 204 1 40960 0 0 buttond [ 2874.795318] [ 1481] 101 1481 1848 125 49152 0 0 chronyd [ 2874.803683] [ 1781] 0 1781 412 12 40960 0 0 getty [ 2874.811874] [ 1782] 0 1782 412 13 40960 0 0 getty [ 2874.820082] [ 1783] 0 1783 412 13 45056 0 0 getty [ 2874.828273] [ 1784] 0 1784 412 12 49152 0 0 getty [ 2874.836477] [ 1785] 0 1785 412 13 40960 0 0 getty [ 2874.844668] [ 1786] 0 1786 412 13 45056 0 0 getty [ 2874.852863] [ 1787] 0 1787 384 34 40960 0 0 login [ 2874.861056] [ 1795] 0 1795 433 37 49152 0 0 ash [ 2874.869072] [ 1971] 0 1971 423 21 40960 0 0 podman_partial_ [ 2874.878131] [ 1975] 0 1975 237060 16292 610304 0 0 podman [ 2874.886410] [ 1976] 0 1976 428 28 45056 0 0 tar [ 2874.894428] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=podman,pid=1975,uid=0 [ 2874.906937] Out of memory: Killed process 1975 (podman) total-vm:948240kB, anon-rss:65104kB, file-rss:0kB, shmem-rss:64kB, UID:0 pgtables:596kB oom_score_a dj:0 [ 2874.934900] oom_reaper: reaped process 1975 (podman), now anon-rss:0kB, file-rss:0kB, shmem-rss:64kB Killed tar: short read Could not extract images: gk_moni:v0.04 armadillo:/mnt# df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/root ext4 272M 204M 49M 81% /live/rootfs devtmpfs devtmpfs 10M 0 10M 0% /dev tmpfs tmpfs 333M 844K 332M 1% /run shm tmpfs 831M 84K 831M 1% /dev/shm cgroup_root tmpfs 10M 0 10M 0% /sys/fs/cgroup none tmpfs 831M 831M 0 100% /live none overlay 831M 831M 0 100% / tmpfs tmpfs 831M 325M 506M 40% /tmp /dev/mmcblk2p3 ext4 42M 430K 38M 2% /var/log /dev/mmcblk2p5 btrfs 9.1G 2.5G 6.4G 29% /var/lib/containers/storage_readonly /dev/mmcblk2p5 btrfs 9.1G 2.5G 6.4G 29% /var/app/rollback/volumes /dev/mmcblk2p5 btrfs 9.1G 2.5G 6.4G 29% /var/app/volumes /dev/mmcblk2p5 btrfs 9.1G 2.5G 6.4G 29% /var/tmp /dev/mmcblk2gp1 vfat 8.0M 2.0K 8.0M 1% /var/at-log /dev/mmcblk2p4 squashfs 24M 24M 0 100% /opt/firmware /dev/mmcblk2p5 btrfs 9.1G 2.5G 6.4G 29% /var/lib/containers/storage /dev/sda1 vfat 29G 5.0G 24G 18% /mnt
at_dominique.m…
USBメモリは事前に試みておりましたが、以下の通り同様のエラーが出ておりました。
申し訳ございません、podman_partial_imageのミスです。 "partial_image" (差分） の部分のために一時的に間違って/tmpに保存使用としています。次のアップデートで成果物のところに作るように修正しておきます。
それまでに
* 今回は差分ではなさそうなので、直接にpodman saveを使ってください。 podman save -o gk_moni_v004.tar gk_moni:v0.04 で問題ないはずです
* v002から差分アップデートが可能な場合に、podman_partial_imageにベースになってるイメージを指定する必要があります。
export TMPDIR=/var/tmp で/tmpを使わないようにしていして、 podman_partial_image -b gk_moni:v0.02 -o gk_moni_v004.tar gk_moni:v0.04 で作成できるはずです。
（ベースの -b のイメージは、ReadOnlyになってるイメージのみを使えますので、今回はv0.03は使えません）
[ 2874.451176] podman invoked oom-killer: gfp_mask=0x500cc2(GFP_HIGHUSER|__GFP_ACCOUNT), order=0, oom_score_adj=0
このエラーはただtmpfsに使ってるメモリが多くてpodmanまで実行できなくなっていましただけですが、/tmpを使わなくなったら大丈夫です。 (/のoverlayにも、/tmpにも大量なデータを書いてあるのでメモリを使いすぎました） 一回再起動した方が早いと思いますが、そのファイルをけすことで容量が戻ります。
よろしくお願いします。
yasuda0108
ありがとうございます。
ご教示頂いた方法で、podman save / podman_partial_image 双方.tarの生成ができました。
v0.02とv0.04の違いは、container# /home 直下に保存している動作プログラムファイルの変更のみです。
この場合、差分アップデートが使用できる認識でよろしいでしょうか。
もし差分アップデートが使用できる場合、以下のdescからswuを生成で問題ないでしょうか。
'atmark@atde9:~/mkswu$ cat embed_gk_start.desc version=2 //前回version=1で実施 swdesc_embed_container "gk_moni_v004_df.tar" //差分で作成した.tar
at_dominique.m…
> ご教示頂いた方法で、podman save / podman_partial_image 双方.tarの生成ができました。
よかったです。
> v0.02とv0.04の違いは、container# /home 直下に保存している動作プログラムファイルの変更のみです。
> この場合、差分アップデートが使用できる認識でよろしいでしょうか。
そうですね、基本的に一つのイメージを変更した場合に差分アップデートを使えます：前のイメージのレイヤーをそのまま使いつづけて、新しいデータだけを展開することで新しいイメージを作成できます。
その分、イメージが少しずつ大きくなります：コンテナの中にファイルを上書きされたとしても、レイヤーのデータが消されてないのでご注意ください。
また、例えば v2 -> v3 と v3 -> v4 のアップデートを作成したところで Armadillo に v2 な状態に v3 -> v4 のアップデートだけを実行しようとしたらアップデートが失敗します。
swdesc_embed_containerを順番に書けば更新できると思いますが、効率が悪いのでその場合に対応していたかったら数回前のイメージをベースにするといいかもしれません。（v2 -> v4 のアップデートを用意したら、 すでにv3になってる Armadillo に v2->v3のデータを使わないだけでアップデートは無事にできるはずです）
最後に、イメージを新しく作成する場合（ベースになってるdebianコンテナを更新する時か、podman build --squash-all でレイヤーを最適化した時）に共通のレイヤーがないので、差分でアーカイブを作っても問題ないですが、すべてのレイヤーを入れてますので差分をはいえません。
話だけでは分かり辛いと思いますので、実際に podman_partial_image の -b でいくつかのイメージを作成してみて、成果物の tar の大きさを比べてみてください。
podman image inspect の RootFS の Layers のところを参考にすると、共有できる部分も明確になると思います。
> もし差分アップデートが使用できる場合、以下のdescからswuを生成で問題ないでしょうか。
はい、これでコンテナを更新できます。 tar が差分でも、podman save の結果でも同じ使い方です。
もし /etc/atmark/containers/*.conf にバージョンも指定されていたら、そのコンフィグファイルの更新も必要です。:latest をタグして使うと楽かもしれません。
よろしくお願いします。
yasuda0108
yasuda0108
お世話になっております。
podman_partial_imageにて、更にアップデートをした際に、下記のようなエラーが出現しました。
armadillo:~# podman images Error: error retrieving label for image "0cd8f14e933a7b5c71a767f5725491fd0335bc4d9d659802a579f77923db3777": you may need to remove the im age to resolve the error: layer not known
アップデート自体は実施され、自動コンテナによりアプリケーションは正常動作しています。
armadillo:~# podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 67a92d33b338 localhost/gk_moni:v0.10 ./initIO_v2.sh 6 minutes ago Up 6 minutes ago qt-auto
下記にアップデート前後の詳細情報を記載します。
//前回アップデート desc
version=3
swdesc_embed_container "gk_ioctrl_v002_df.tar"
swdesc_files --extra-os gk_start
//前回アップデート 自動コンテナディレクトリ
atmark@atde9:~/mkswu/update-container$ tree gk_start
gk_start
└── etc
└── atmark
└── containers
├── io-auto.conf
└── qt-auto.conf
//アップデート前image
armadillo:~# podman images
REPOSITORY TAG IMAGE ID CREATED SIZE R/O
localhost/gk_moni v0.10 ccaade076438 Less than a second ago 1.91 GB false
localhost/gk_moni v0.04 07824c3dd9d3 Less than a second ago 1.9 GB false
localhost/gk_moni v0.04 07824c3dd9d3 Less than a second ago 1.9 GB true
localhost/gk_ioctrl v0.02 0cd8f14e933a Less than a second ago 234 MB false
localhost/gk_ioctrl v0.02 0cd8f14e933a Less than a second ago 234 MB true
今回アップデートによって、以下の内容を実施すべくdesc作成しました。
①gk_moni:v0.04→gk_moni:v0.10にアップデート
②io-auto.confを不使用
③gk_ioctrl:0.02を不使用
※②、③については、できれば削除したいが削除方法が判らなかったので、今回はアップデートをかけないよう対応
結果
//今回アップデート desc
version=4
swdesc_embed_container "gk_moni_v010_df.tar"
swdesc_files --extra-os gk_start
//今回アップデート 自動コンテナディレクトリ
atmark@atde9:~/mkswu/update-container$ tree gk_start
gk_start
└── etc
└── atmark
└── containers
└── qt-auto.conf
//アップデート後imageエラー
armadillo:~# podman images
Error: error retrieving label for image "0cd8f14e933a7b5c71a767f5725491fd0335bc4d9d659802a579f77923db3777": you may need to remove the im
age to resolve the error: layer not knownお手数をおかけしますがご対応宜しくお願い致します。
at_dominique.m…
yasuda0108さん、
お世話になっています。
> podman_partial_imageにて、更にアップデートをした際に、下記のようなエラーが出現しました。
podman_switch_storage --disk と swu の更新は上手く連携取れてないようで申し訳ございません。
ログが多くて助かります、説明させていただきます。
> //アップデート前image > armadillo:~# podman images > REPOSITORY TAG IMAGE ID CREATED SIZE R/O > localhost/gk_moni v0.10 ccaade076438 Less than a second ago 1.91 GB false > localhost/gk_moni v0.04 07824c3dd9d3 Less than a second ago 1.9 GB false > localhost/gk_moni v0.04 07824c3dd9d3 Less than a second ago 1.9 GB true > localhost/gk_ioctrl v0.02 0cd8f14e933a Less than a second ago 234 MB false > localhost/gk_ioctrl v0.02 0cd8f14e933a Less than a second ago 234 MB true ＋ > armadillo:~# podman images > Error: error retrieving label for image "0cd8f14e933a7b5c71a767f5725491fd0335bc4d9d659802a579f77923db3777": you may need to remove the image to resolve the error: layer not known
このエラーは、readonly（RO) と readwrite（RW) の両方に入っていた gk_ioctrl:v0.02 から、レイヤーを見つからなくなったとのことです。
RO/RW の両方を使う場合、データを二回コピーしないように podman が RW の方で、RO にあるレイヤーを使ってくれますが、アップデートの際に gk_ioctl:v0.02 が不要になった結果 readonly のストレージから削除されました… が、RW のストレージから消されてないため、このようなエラーが起きます。
今回、gk_ioctl:v0.02 が不要になったので、「podman image remove 0cd8f14e933a7b5c71a767f5725491fd0335bc4d9d659802a579f77923db3777」（か podman image remove gk_ioctl:v0.02 ) を実行すれば、RW のストレージからもイメージを削除して、このエラーがなくなります。
恐らく、このエラーを直した直後に、gk_monit:v0.04 のイメージでも同じエラーがでますので、その時は同じく消せば問題ないです。
（podman rm コマンドを実行しても、 readonly のストレージに影響がないので、SWUで書き込んだイメージを消す事はありません。）
これからの対応ですが、
- やはり podman_switch_storage --tmpfs で運用すればこのような問題がないので、開発機以外は tmpfs で運用していただいた方がいいと思います。
- podman_switch_storage --disk の場合はどうしたらいいでしょうね。できれば、RO のストレージからイメージを消す時に必要なレイヤーを RW の方にコピーしたら一番わかりやすい動作になりますが、podman のコマンドでレイヤーの有無の確認やコピーはできないのでかなり難しい処理になりそうですね。容量が足りないこともありえますし…
確認だけであれば何とかできそうですが、アップデートを失敗させたら分かりにくいと思いますので、もうちょっと考えさせてください。
よろしくお願いします。
yasuda0108
ご回答ありがとうございます。
> このエラーは、readonly（RO) と readwrite（RW) の両方に入っていた gk_ioctrl:v0.02 から、レイヤーを見つからなくなったとのことです。
> RO/RW の両方を使う場合、データを二回コピーしないように podman が RW の方で、RO にあるレイヤーを使ってくれますが、アップデートの際に gk_ioctl:v0.02 が不要になった結果 readonly のストレージから削除されました… が、RW のストレージから消されてないため、このようなエラーが起きます。
なるほど、エラー要因について理解いたしました。
podman_switch_storage --statusを--tmpfsにして、アップデートをする必要があったのですね。
> 今回、gk_ioctl:v0.02 が不要になったので、「podman image remove 0cd8f14e933a7b5c71a767f5725491fd0335bc4d9d659802a579f77923db3777」（か podman image remove gk_ioctl:v0.02 ) を実行すれば、RW のストレージからもイメージを削除して、このエラーがなくなります。
> 恐らく、このエラーを直した直後に、gk_monit:v0.04 のイメージでも同じエラーがでますので、その時は同じく消せば問題ないです。
> （podman rm コマンドを実行しても、 readonly のストレージに影響がないので、SWUで書き込んだイメージを消す事はありません。）
お教えいただいた通り、podman image remove 0cd8f14e933a7b5c71a767f5725491fd0335bc4d9d659802a579f77923db3777」（か podman image remove gk_ioctl:v0.02によって、--diskの場合でも、podman imagesが正常に動作するようになりました。
> これからの対応ですが、
> - やはり podman_switch_storage --tmpfs で運用すればこのような問題がないので、開発機以外は tmpfs で運用していただいた方がいいと思います。
> - podman_switch_storage --disk の場合はどうしたらいいでしょうね。できれば、RO のストレージからイメージを消す時に必要なレイヤーを RW の方にコピーしたら一番わかりやすい動作になりますが、podman のコマンドでレイヤーの有無の確認やコピーはできないのでかなり難しい処理になりそうですね。容量が足りないこともありえますし…
> 確認だけであれば何とかできそうですが、アップデートを失敗させたら分かりにくいと思いますので、もうちょっと考えさせてください。
今後の対応のご提案まで頂きありがとうございます。
開発機に関しても、コンテナイメージのアップデートが必要となった際には、--tmpfsに切り替えて実行するように対応します。
引き続きよろしくお願いいたします。
at_dominique.m…
> podman_switch_storage --statusを--tmpfsにして、アップデートをする必要があったのですね。
具体的に、tmpfsに切り替えたところで何も変わりませんが、切り替える時に「diskにコンテナイメージが残ってますが消しますか？」の質問でクリアしていただいたら問題無いですね。
そうなったら 「podman image rm -a -f」だけでも同じなので、わざわざ切り替える必要がないと思います。
（逆にクリアしなかったら、戻るときに同じ問題が起きます）
> 今後の対応のご提案まで頂きありがとうございます。
何か決まりましたらまた連絡いたします。
よろしくお願いします。
at_dominique.m…
2022年5月12日 14時14分
yasuda0108さん、
お世話になっています、マルティネです。
> podman_switch_storage --tmpfs
> にて、読み取り専用で動作させようと考えております。
そうですね、podman は残念ながら下手なタイミングに電源を落とすと使えない状態になるので、運用の時にぜひデフォルトの tmpfs 状態で使ってください。
まず、その画面を少し説明しましょう。
podmanのストレージを --disk にすると、/var/lib/containers/storage に appfs のサブボリュームをマウントしてそれを使わせますが、
--diskでも--tmpfsでも /var/lib/containers/storage_readonly も読み取り専用で使えます。
--disk の rw のストレージが一つしかないですが、readonly の部分は A/Bアップデートのために mkswu / swupdate でコンテナを送信する時に使われてます。
名前の通り、そこにあるコンテナがリストに R/O = true になってますので、恐らくmkswu で ioctrl v0.00 / moni v0.02を送信して、その後にpodman commit か load で新しいバージョンも rw のボリュームに作ったんでしょう。
そこで、--tmpfs で rw のボリュームをはずしたら、ごらんになった通りに古いバージョンしか残りません：
新しいバージョンはrwのボリュームにあったので、そうなるしかありません。
（R/O = 読み取り専用は true になってますので、イメージは確かに読み取り専用になっています。ちなみに、tmpfsの状態でもpodman commitなどを使えますが、tmpfs (=メモリ）に保存されるだけで再起動すれば readonly の部分だけが残ります）
そこで新しいバージョンも ro にしたいとすると、手順は二つあります：
* --disk な状態に戻って、podman save か podman_partial_image で新しいバージョンを保存します。
* mkswu でまた swdesc_usb_container等で新しく送信して、readonlyのボリュームにかかれます。
か、4月のアップデートに追加された `abos-ctrl podman-rw` のコマンドで直接ロードするこ可能です：
* 同じく、--disk の状態から podman save か何かで tarに保存します
* `abos-ctrl podman-rw load -i container.tar` で readonly のボリュームを一時的に rw にして、直接に書き込みます
直接に rw のストレージからコピーできればと思っていますが、podmanにこういう便利なコマンドがまだないのでこれからの課題です。
運用の時のおすすめとしましては：
* 運用に使ってる armadillo を tmpfs な状態に残して、swuでコンテナのアップデートを行います
* 手元の開発用の armadillo を disk にして、そこに podman buildやcommit で新しいバージョンを用意したら swu用の tar に保存します
か
* atdeや自分のサーバーで emulation でコンテナを作っておいて、手元の開発用の armadillo でも swu で確認してから他の機にも配ります。
例えば、github action を使ってできました： https://github.com/martinetd/G4_container_updater
これでもう少し明確になったと思いますが、何か不明な点があればまたお聞きください。
よろしくお願いします。