Armadilloフォーラム

podman imageについて

製品
Armadillo-IoT G4

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にすればよいと思うのですが、どの様に変更すれば良いでしょうか。

コメント

at_dominique.m…

2022年5月12日 14時14分

yasuda0108さん、

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

> podman_switch_storage --tmpfs
> にて、読み取り専用で動作させようと考えております。

そうですね、podman は残念ながら下手なタイミングに電源を落とすと使えない状態になるので、運用の時にぜひデフォルトの tmpfs 状態で使ってください。

> 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

まず、その画面を少し説明しましょう。
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 のボリュームをはずしたら、ごらんになった通りに古いバージョンしか残りません：

> 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

新しいバージョンは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

これでもう少し明確になったと思いますが、何か不明な点があればまたお聞きください。

よろしくお願いします。

yasuda0108

2022年5月12日 16時17分

ご丁寧に解説頂き大変ありがとうございます。
--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…

2022年5月12日 16時35分

> 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

2022年5月12日 17時12分

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…

2022年5月12日 17時41分

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

2022年5月13日 10時11分

ありがとうございます。
ご教示頂いた方法で、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…

2022年5月13日 10時45分

> ご教示頂いた方法で、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

2022年5月13日 13時05分

ありがとうございます。
内容理解いたしました。差分.tar作成により、イメージが少しずつ大きくなる旨も確認できました。

おかげさまで.confも含め、無事アップデートが完了しました。
引き続きよろしくお願いいたします。

yasuda0108

2022年5月18日 11時01分

お世話になっております。

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…

2022年5月18日 11時27分

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

2022年5月18日 14時14分

ご回答ありがとうございます。

> このエラーは、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…

2022年5月18日 14時53分

> podman_switch_storage --statusを--tmpfsにして、アップデートをする必要があったのですね。

具体的に、tmpfsに切り替えたところで何も変わりませんが、切り替える時に「diskにコンテナイメージが残ってますが消しますか？」の質問でクリアしていただいたら問題無いですね。
そうなったら 「podman image rm -a -f」だけでも同じなので、わざわざ切り替える必要がないと思います。
（逆にクリアしなかったら、戻るときに同じ問題が起きます）

> 今後の対応のご提案まで頂きありがとうございます。

何か決まりましたらまた連絡いたします。

よろしくお願いします。