Armadilloフォーラム

tmpfsを保存先としたときにコンテナの起動が失敗する

ytr373

2023年7月6日 18時39分

お世話になります。

eMMCに保存するモードで開発、動作の確認を行っていたコンテナを、
tmpfsに切り替えてコンテナを起動したところ、以下のようなエラーにより起動に失敗します。

[ 5756.152545] overlayfs: failed to resolve 'l/HHEYNKOTQ2SEEH4BURDI5BO7GJ': -2
ERRO[0000] Unmounting /run/containers/storage_root/overlay/51e30741e9505212fbbbc169810c400f3f1ef49340b1a899faf9a076b26ca2d4/merged: invalid argument
Error: mounting storage for container bd5248b44065e5116cc73e28a842600487b1ad0a1c8a54db274d903f91c3489f: creating overlay mount to 51e30741e9505212fbbbc169810c400f3f1ef49340b1a899faf9a076b26ca2d4/merged, mount_data="lowerdir=l/HHEYNKOTQ2SEEH4BURDI5BO7GJ:l/WTQYU3XFFSFTUTSI7MGKRX2F3B:l/RSN3K64GH4KMCIKDXLK6D5KU56:l/GYCYOAP75OULJ5PNOIVT4ZGTPS:l/7FHTSNY3CDROR3TE3KRRGFWB2F:l/KPOJ32S2SZ5WW64TEN2YYVMIQF:l/GDFFHTPUE5SATZGXIBZG26KHF4:l/BRJWAKJYIFGORDYECYTG4DYJP3:l/FNWGRU33EOFLZFOF7P3FWFY2OS:l/YMAZ33PMVIUC7QGR2XMVFMWHLU:l/5TR52JXDKEDIE2IOOEN2CTFAMW:l/L3KJVUWJNTQPCMJQ5W66234ROA:l/FFRFTAOQ64GH2RL7VMYLEMTKA6:l/QA3G6M5QVK4LEYXPWQ4OVLKFUW:l/5S2XEQ25PLJDSYXL7MWMOSH6IH:l/RJSX22LATJK74CDUSH6HAZDCFB:l/GF6EEV6MKY5M4J46R3RS4FW5XY:l/72FJRHJZ2XRHNLOQVNQFD644UO:l/D7EJB27HHLCZ3A53WWSESEHLOY:l/DG5XV4LRDQBKBRYFBQGCTUGLAY:l/CMI7WRYVV4MXT23GG6PDLPWLRE:l/OMTSMTY32WAN7YTWDENXXPLE7A:l/QP5YNEM72UWOYGDZWYM3QOV2W4:l/LJCJI3ELK6SPWVOHAD2UGLV55O:l/MONLDRWOJT6Z3SNNOUYIAWOXUA:l/ZGOL5JNBM76VZGKHJ6BMFM76U2:l/4VEWGMKUSNPIPBIJYG4LQL3O7U:l/I3IARVDBYY65WJBEZY5SDXDKKR:l/ORW4M3P2I3OLO52ZHY4X7BUBGL:l/3WRNCFAPKLKGS42HN2Y5THARTF:l/L26JJT4LNZLJ5EC5BNAA5N34X2:l/FXERDVFUFR6NRMNZ5BHTZNBXXX:l/P42CUL23RD5BSDEJYWNFLECU65:l/UOEPXP2XX76572BXOG477HQIEE:l/5PDVRO3VWWCLAJG4YSZ5SP4EFE:l/ZYPRURDUECVEC3RIJTPO6QNPGJ:l/XONRYWF7AQIPET5XJIKO7FZ77B:l/BHOSFJTDZI5MNSQKOERSNUNEB6:l/7ZUCA6IJQR5OUTFSOROUHMIK56:l/VBNECUH5AXJEN3X5D4RX7E6VF3:l/AHZK33KIQKQVKP4HZPEXFP2LWA:l/HPYYITUIIEGYFKHLNSULVZ6WOI:l/PEBMRKNG52T47JSKNOH3R3P2GP:l/H3YBYISNIKSBNQZNE7RYZBU5PV:l/5XCWPQSDCJSJFGDN5G7L4IIIOU:l/W4QZBLP6TFWZXFW3QXBVLE5TQS:l/RBAMHBDOJEKVXSBLWVV2PZDJY5:l/SM2BHHX5PWF4FGXBZBZQDBSHKA:l/5VORZWRNK4ALPN4N3DL5B2F55T:l/TZ5MI4LMYJFWX4C47EEZPCLYST:l/G2T4K7KDJHRK263SFOO6APXUDF:l/HFBK33WH2CRCOBWKPG3JJNWBL2:l/637IIKUGSXDTW2CIS66S77WLUU:l/7LWM3WRVKG7ADRK2Z2WXXTFQOF:l/BL4DOFT4POETGJHWRNYWZNP5VD:l/Y6LO7GGB6F64HADCB62MY527EA:l/TJB2IALZ5PCLDUYPVZXC5HYXPT:l/FFF4VS65GAQIHEL5DQRJNU2TOS:l/DVFLQ2TN7LMNT5FOPXFNALFVFY:l/H4H3V2E55ZCGKTAJD62I5N77VO,upperdir=51e30741e9505212fbbbc169810c400f3f1ef49340b1a899faf9a076b26ca2d4/diff,workdir=51e30741e9505212fbbbc169810c400f3f1ef49340b1a899faf9a076b26ca2d4/work,nodev": mountfrom re-exec output: no such file or directory: error: exit status 1
error: Could not start [コンテナ名]

abos-ctrolコマンドでコンテナ情報を削除し、バックアップしたイメージから再ロードしてみましたが、同じ状況となりました。

これは当方の設定に因るものか、何かしら解決する手段があるものなのかいずれでしょうか。
もし後者である場合は、手段をご教示いただけますと幸いです。

よろしくお願いいたします。

コメント

at_dominique.m…

2023年7月7日 10時56分

ytr373さん

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

> eMMCに保存するモードで開発、動作の確認を行っていたコンテナを、
> tmpfsに切り替えてコンテナを起動したところ、以下のようなエラーにより起動に失敗します。
> [エラー省略]

上記では、podman_start での失敗に見えますが、あってますか?
開発用の eMMC モードでは起動できていましたが、abos-ctrl podman-storage --tmpfs で切り替えたところからエラーが発生したということですね?

申し訳ございません、ABOS のバージョンを確認していただけますでしょうか:「 cat /etc/atmark-release; apk list --installed abos-base 2>/dev/null

恐らくですが、古いバージョンで --disk に切り替えた時に以下の様に storage を別けたまま開発していて:

/var/lib/containers/storage_readonly <- 読み取り専用コピー、ベースレイヤー
/var/lib/containers/storage <- 読み書き可能な開発ストレージ、ベースレイヤーを使うコンテナあり

そこで --tmpfs に切り替えた時に storage_readonly の部分が削除されて、ベースのレイヤーがなくなったことでコンテナを使えなくなりました。
新しい BaseOS では最初の切り替えで split 運用しなくなりましたのでこのリスクもなくなりましたし、--tmpfs から戻る時にもちゃんと確認して削除ではなく合流の形でマージするはずですが、同じ ABOS のバージョンで確認したいので教えてください。

> abos-ctrlコマンドでコンテナ情報を削除し、バックアップしたイメージから再ロードしてみましたが、同じ状況となりました。

バックアップというのは、「/var/lib/containers/storage」のディレクトリだけでしょうか?他にも何かありますか?

大変お手数をおかけしますが、対応はバージョンを確認して、現状を確認した後に説明させてください。
場合によってはベースのレイヤーを rollback側にまだある可能性もありますので、その返事まで更新をしないでください。

よろしくお願いします

マルティネ様

お世話になります。早々の回答ありがとうございます。

> 上記では、podman_start での失敗に見えますが、あってますか?

 はい、ご認識の通りです。

> 開発用の eMMC モードでは起動できていましたが、abos-ctrl podman-storage --tmpfs で切り替えたところからエラーが発生したということですね?

 こちらもご認識の通りです。

> バックアップというのは、「/var/lib/containers/storage」のディレクトリだけでしょうか?他にも何かありますか?

 こちらについては私の記載が拙く申し訳ありません。
 podman save で外部デバイスに保存していたコンテナのイメージ(tarで固めたもの)を指しています。

> ABOS のバージョンを確認していただけますでしょうか

 ご指示いただいたコマンドの結果は以下のようになりました。
 

3.17.4-at.8
abos-base-1.20-r3 aarch64 {abos-base} (MIT) [installed]

一点、環境について記載漏れがございました。申し訳ございません。
--tmpfsに切り替える前(--diskの状態で)にUSB経由で v3.17.4-at.8 への更新を実施しています。

以上、ご確認のほどよろしくお願いいたします。
 

> ytr373さん
>
> お世話になっています、
> マルティネです。
>
> > eMMCに保存するモードで開発、動作の確認を行っていたコンテナを、
> > tmpfsに切り替えてコンテナを起動したところ、以下のようなエラーにより起動に失敗します。
> > [エラー省略]
>
> 上記では、podman_start での失敗に見えますが、あってますか?
> 開発用の eMMC モードでは起動できていましたが、abos-ctrl podman-storage --tmpfs で切り替えたところからエラーが発生したということですね?
>
> 申し訳ございません、ABOS のバージョンを確認していただけますでしょうか:「 cat /etc/atmark-release; apk list --installed abos-base 2>/dev/null
>
> 恐らくですが、古いバージョンで --disk に切り替えた時に以下の様に storage を別けたまま開発していて:
>

> /var/lib/containers/storage_readonly <- 読み取り専用コピー、ベースレイヤー
> /var/lib/containers/storage <- 読み書き可能な開発ストレージ、ベースレイヤーを使うコンテナあり
> 

>
> そこで --tmpfs に切り替えた時に storage_readonly の部分が削除されて、ベースのレイヤーがなくなったことでコンテナを使えなくなりました。
> 新しい BaseOS では最初の切り替えで split 運用しなくなりましたのでこのリスクもなくなりましたし、--tmpfs から戻る時にもちゃんと確認して削除ではなく合流の形でマージするはずですが、同じ ABOS のバージョンで確認したいので教えてください。
>
> > abos-ctrlコマンドでコンテナ情報を削除し、バックアップしたイメージから再ロードしてみましたが、同じ状況となりました。
>
> バックアップというのは、「/var/lib/containers/storage」のディレクトリだけでしょうか?他にも何かありますか?
>
> 大変お手数をおかけしますが、対応はバージョンを確認して、現状を確認した後に説明させてください。
> 場合によってはベースのレイヤーを rollback側にまだある可能性もありますので、その返事まで更新をしないでください。
>
> よろしくお願いします

at_dominique.m…

2023年7月7日 11時43分

ytr373さん

ご確認ありがとうございます。

> > バックアップというのは、「/var/lib/containers/storage」のディレクトリだけでしょうか?他にも何かありますか?
>
>  こちらについては私の記載が拙く申し訳ありません。
>  podman save で外部デバイスに保存していたコンテナのイメージ(tarで固めたもの)を指しています。

了解しました。それでしたら podman save が成功した分に全レイヤーが含まれているはずですので、復帰はできると思います。
それでしたらコンテナを完全に削除してから podman load をもう一度試したいと思います。

以下の手順を試していただけますでしょうか?

# tmpfs 状態で全コンテナの削除
armadillo:~# abos-ctrl podman-storage --tmpfs
armadillo:~# podman rm -af
armadillo:~# podman rmi -af
armadillo:~# abos-ctrl podman-rw rmi -af
 
# 何も表示されないことの確認
armadillo:~# podman image list
REPOSITORY  TAG         IMAGE ID    CREATED     SIZE
 
# 読み取り専用ストレージにロードコマンド
armadillo:~# abos-ctrl podman-rw load -i [/path/to/container.tar]
 
# ロードされた後に表示される確認
armadillo:~# podman image list
 
# 実行の確認
armadillo:~# podman_start [container]

恐らく大丈夫だと思いますが、失敗の場合は load の出力から提供していただければ助かります。

>

> 3.17.4-at.8
> abos-base-1.20-r3 aarch64 {abos-base} (MIT) [installed]
> 

> 一点、環境について記載漏れがございました。申し訳ございません。
> --tmpfsに切り替える前(--diskの状態で)にUSB経由で v3.17.4-at.8 への更新を実施しています。

最新ですね、ありがとうございます。
このバージョンでマージできているはずですが、アップデートを含めてこれから再現できないか確認します。

ちなみに --disk に切り替えたバージョンはご存知でしょうか? 「grep base_os /var/at-log/atlog」で「base_os: 3.17.1-at.1 -> 3.17.4-at.8」のような記録を記載していますので、参考にできるかもしれません。

よろしくお願いします。

マルティネ様

 お世話になります。
 いただいた返信をもとに作業を実施しました。

 結論を申し上げますと、最初の投稿と同様のエラーが発生し、コンテナは起動できませんでした。

以下、各コマンドの実行結果になります。

armadillo:~# abos-ctrl podman-storage --tmpfs
Delete subvolume (no-commit): '/mnt/containers_storage'
Switching back to tmpfs container storage.
Successfully reverted podman storage to tmpfs
 
armadillo:~# podman rm -af
ac8c82e0e64794078477338542b2d075726221baaf4c23764c40b296d23e42d7
 
armadillo:~# podman rmi -af
 
armadillo:~# abos-ctrl podman-rw rmi -af
Create a snapshot of '/var/lib/containers/storage_readonly' in '/mnt/containers_storage'
Untagged: localhost/tateno:v1.0.0
Deleted: 9a850fbebdc4980588b0136831ca104a940fe3a966ff5856c58afaf5d08ffcd3
Create a snapshot of '/mnt/containers_storage' in '/mnt/new_storage'
Delete subvolume (no-commit): '/mnt/new_storage'
Replacing development images to readonly storage succeeded
Delete subvolume (no-commit): '/mnt/containers_storage'
 
armadillo:~# podman image list
REPOSITORY  TAG         IMAGE ID    CREATED     SIZE
 
armadillo:~# abos-ctrl podman-rw load -i /mnt/usb/[container].tar
Create a snapshot of '/var/lib/containers/storage_readonly' in '/mnt/containers_storage'
Getting image source signatures
Writing manifest to image destination
Storing signatures
Loaded image: localhost/[container]
Create a snapshot of '/mnt/containers_storage' in '/mnt/new_storage'
Delete subvolume (no-commit): '/mnt/new_storage'
Replacing development images to readonly storage succeeded
Delete subvolume (no-commit): '/mnt/containers_storage'
 
armadillo:~# podman image list
REPOSITORY        TAG         IMAGE ID      CREATED       SIZE        R/O
localhost/[container] v1.0.0      9a850fbebdc4  14 hours ago  1.72 GB     true
 
armadillo:~# podman_start [container]
Starting '[container]'
[ 4514.615235] overlayfs: failed to resolve 'l/Q5QZ2BVQ4D77BFUXIX2Q34TP2D': -2
ERRO[0000] Unmounting (以下略)

> ちなみに --disk に切り替えたバージョンはご存知でしょうか?

こちらは、base_os: 3.17.1-at.1 -> 3.17.4-at.8 となっておりました。

以上、ご確認のほどよろしくお願いいたします。

at_dominique.m…

2023年7月7日 14時22分

ytr373さん

マルティネです。

> 結論を申し上げますと、最初の投稿と同様のエラーが発生し、コンテナは起動できませんでした。

了解しました。

> こちらは、base_os: 3.17.1-at.1 -> 3.17.4-at.8 となっておりました。

先にバージョンの返事します。
ABOS 3.17.1-at.1 ではすでにシングルストレージになっていたので、そのバージョンでストレージを --disk に切り替えたなら最初の返事で上げた仮説ではなかった様です。
念のため、こちらで 3.17.1-at.1 をインストールして、読み取り専用にベースイメージを追加して、--disk に切り替えて、コンテナを作って、3.17.4-at.8 に更新して、再び --tmpfs に切り替えてみたところ問題が発生しませんでした。
最後にこういう動作をしていたのは 3.16.2-at.4 でして、そのバージョンでもベースのレイヤーが最初にコピーされていて、意図的にそれを削除してからコンテナを作っていたら、切り替えの前に更新の時に必要なレイヤーが削除されて podman image list も podman save も使えない状態になっていました。
その点は mkswu の不具合で、disk 切り替えの状態をうまく把握していないところを直しますが、podman save が動くのにロードできないところにこころあたりがないですね… podman の不具合の可能性もあります。

とりあえず対応 / 復帰を優先して、お手数ですがまたいくつかの確認をお願いします。

まず、先ほどの podman-rw load コマンドで以下のような行があったと思いますが、削除していましたか?

Copying blob xxx done
Copying config 9a850fbebdc4 done
 
> armadillo:~# abos-ctrl podman-rw load -i /mnt/usb/[container].tar
> Create a snapshot of '/var/lib/containers/storage_readonly' in '/mnt/containers_storage'
> Getting image source signatures
 
# ここ
 
> Writing manifest to image destination

そこにお客様の情報がないので、提供していただければ助かります。

また、コンテナの .tar ファイルからも以下の情報をください:
- tar tf [tarファイル] の一覧。そこに数な分の「Copying blob」メッセージの .tar があるはずです。
- 展開して、9a850fbebdc4*.json ファイルの中身(.txt にリネームして添付でも、ここの code ブロックでもいいです。そこにも秘密がないはずですがご確認ください。コンテナのレイヤー情報が入ってます)
- manifest.json にもレイヤー情報が同じく入っています。そっちらにコンテナの名前が入ってますが削除していただいても構いません。

manifest.json は tar に入っているレイヤーの情報で、9a850fbebdc4*.jsonはコンテナに必要なレイヤーのリストですので、そこの違いを確認したいです。

そこで:
- 齟齬がなければ次は load の後の storage ディレクトリを確認したいので、また説明します。
- 想定通りに違いがあった場合に、そのレイヤーを復帰しないといけないので、少し手間になります。運がよければ podman pull [ベースになっていた docker.io/debian:bullseyeなど]か podman load [at-debian-image.tar] でそのまま同じレイヤーが復帰されて使える状態になりますが、そうならなかったらコンテナを作り直す必要があります。ベースのイメージでコンテナを起動して、9a850fbebdc4*.json の順番でレイヤーファイルの tar ファイルを展開したら恐らく最終てきにできていたイメージの状態にもどると思います。

どのパターンでも大変な作業になっていて本当に申し訳ございません。
ご迷惑ですが、情報をいただけたら原因に近づけると思いますので、付き合っていただけたら大変助かりますがここからイメージを作り直した方が早いかもしれません。
上記に説明した様にバックアップのレイヤーからファイルを参考にしていただければある程度の時間の節約ができると思います。

よろしくお願いいたします。

マルティネ様

 お世話になります。確認いただきありがとうございます。
 ご質問いただいた件、以下のように回答いたします。

> まず、先ほどの podman-rw load コマンドで以下のような行があったと思いますが、削除していましたか?

 Copying blob xxx done
 Copying config 9a850fbebdc4 done

結果をそのまま貼り付けており、削除はしておりません。

> - tar tf [tarファイル] の一覧

 tar_tf結果.txt として保存したものを添付いたしました。

> - 展開して、9a850fbebdc4*.json ファイルの中身

 9a850fbebdc4*.txt として添付いたしました。

> - manifest.json にもレイヤー情報が同じく入っています。

 manifest.txtとして添付いたしました。

> 付き合っていただけたら大変助かりますが

 できる限りご協力させていただきます。
 ただし、諸事情により事象が発生しているX2が現在手元にないため、
 ご協力の範囲に限度があるかもしれません。
 
 
> ここからイメージを作り直した方が早いかもしれません。

 この点について確認させてください。
 事象が発生しているX2とは別に、もう1台X2が手元にございます。
 そちらのX2において、podman saveでバックアップをとったコンテナをロードしても
 同様の事象が発生するのでしょうか。

ファイル ファイルの説明
tar_tf結果.txt
9a850fbebdc4980588b0136831ca104a940fe3a966ff5856c58afaf5d08ffcd3.txt
manifest.txt

at_dominique.m…

2023年7月7日 19時08分

ytr373さん

先に返事します。

> > まず、先ほどの podman-rw load コマンドで以下のような行があったと思いますが、削除していましたか?
>
> 結果をそのまま貼り付けており、削除はしておりません。

分かりました。必ず出力されるという認識ですので、月曜日はそれを確認します。

>  tar_tf結果.txt として保存したものを添付いたしました。
>  9a850fbebdc4*.txt として添付いたしました。
>  manifest.txtとして添付いたしました。

その三つのファイルのレイヤーを確認したところ、齟齬がありませんでした。
また、podman_start が失敗した時の overlay コマンドのディレクトリの数も一致しています。
なので、私の理解ではそのイメージが正常で、podman save で無事にコンテナを保存したはずです。

>  できる限りご協力させていただきます。
>  ただし、諸事情により事象が発生しているX2が現在手元にないため、
>  ご協力の範囲に限度があるかもしれません。

ありがとうございます!

> > ここからイメージを作り直した方が早いかもしれません。
>
>  この点について確認させてください。
>  事象が発生しているX2とは別に、もう1台X2が手元にございます。
>  そちらのX2において、podman saveでバックアップをとったコンテナをロードしても
>  同様の事象が発生するのでしょうか。

申し訳ございません、みたことのない問題なので発生しないと思いますが、発生する理由がまったく分からない状態なので何ともいえません。
そちらの X2 はまだ storage=disk で、podman_start が成功する状態ですね?
念のためそのままの disk に残しましょう。確認のためは podman save を行って問題のある X2 か ATDE でロードできると思いますが、すぐ切り替える必要がなければ先に確認していただきたい点がまたいくつかあります。

もう少し現状の storage について確認したいと思いますので、以下のコマンドの出力をまたお願いします:

# マウント情報、USB デバイスなどを削除していいです
armadillo:~# findmnt
# 「overlayfs: failed to resolve 'l/HHEYNKOTQ2SEEH4BURDI5BO7GJ': -2」のエラーに代わりがなければ、そのディレクトリを確認したいです:
armadillo:~# ls -l /run/containers/storage*/overlay/l/HHEYNKOTQ2SEEH4BURDI5BO7GJ /var/lib/containers/storage*/overlay/l/HHEYNKOTQ2SEEH4BURDI5BO7GJ 2>/dev/null
# tar アーカイブと同じレイヤーのリンクがそちらにあるはずですので、そちらも添付でもでお願いします:
armadillo:~# ls -l /var/lib/containers/storage_readonly/overlay/l/

それで、今更ですが、問題になった X2 を再起動すれば成功するのではないかと思うようになりましたが、storage=tmpfs にしてからまだ再起動していないことであっていますか?(状況を確認したいので、まだ再起動しないでくれれば嬉しいです)

まだ再起動してない場合は以下のコマンドで動く可能性がありますので、まずはそこから確認してみたいと思います:

# /run にある podman storage ディレクトリを移動します
armadillo:~# mkdir /run/containers_backup
armadillo:~# mv /run/containers/storage_root /run/containers_backup/
armadillo:~# podman_start [container]
 
# 失敗した場合、podman の runtime ディレクトリも移動します
armadillo:~# rm -rf /run/containers/storage_root
armadillo:~# mv /run/containers/storage /run/containers_backup/
armadillo:~# podman_start [container]
 
# 修正された場合、コピーで再び再現できるかの確認します。
armadillo:~# podman rm -af
armadillo:~# rm -rf /run/containers/storage_root /run/containers/storage
armadillo:~# cp -a /run/containers_backup/storage* /run/containers/ 
armadillo:~# podman_start [container]

大変お手数ですが、よろしくお願いします。

マルティネ様

 お世話になります。
 前後しますが、結果等について以下のように回答いたします。

> storage=tmpfs にしてからまだ再起動していないことであっていますか?

 こちらについては、storage=disk 状態で先週末に電源断、そして本日起動いたしました。
 状態は Currently in disk mode となっております。

>armadillo:~# findmnt

こちらの結果につきましては、findmnt_result.txt として添付いたしました。

> armadillo:~# mv /run/containers/storage_root /run/containers_backup/

こちらについては storage_rootなるディレクトリが存在しておりませんでした。
再起動による影響でしたでしょうか。
ですので、これ以降のコマンドは実行しておりません。

以上、ご確認のほどよろしくお願いいたします。

ファイル ファイルの説明
findmnt_result.txt

at_dominique.m…

2023年7月10日 13時12分

ytr373さん、

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

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

> こちらについては storage_rootなるディレクトリが存在しておりませんでした。
> 再起動による影響でしたでしょうか。
> ですので、これ以降のコマンドは実行しておりません。

/run は tmpfs なので、再起動した際に削除されました。

今の回答では、podman_start は再起動した今でも失敗するという認識ですが、あってますか?podman ps などで起動されているかの確認でいいと思います。
それでしたら似たよな確認になりますので、大丈夫です。
起動できていたら、前のファイルをみたいところですが、それでも手がかりになりますのでこちらで再現を頑張ってみます。

> こちらの結果につきましては、findmnt_result.txt として添付いたしました。

ありがとうございます。

起動できてなかった場合は:
-「podman_start -a」の出力でまだ HHEYNKOTQ2SEEH4BURDI5BO7GJ ディレクトリからエラーしているかの確認
-「ls -l /run/containers/storage*/overlay/l/HHEYNKOTQ2SEEH4BURDI5BO7GJ; ls -l /var/lib/containers/storage_readonly/overlay/l/」コマンドの出力もお願いします。

お手数ですが、よろしくお願いいたします。

マルティネ様

 お世話になります。返信ありがとうございます。

> 今の回答では、podman_start は再起動した今でも失敗するという認識ですが

 はい、失敗します。
 先ほどstorage=tmpfs に移行後 podman_start を実行しましたが、
 これまでと同様のエラーが出力されました。

> -「podman_start -a」の出力でまだ HHEYNKOTQ2SEEH4BURDI5BO7GJ ディレクトリからエラーしているかの確認

 こちらは、ディレクトリが  NIXJAI2YBZFOH5CTPK2P34ZNTX に変わっておりました。

> -「ls -l /run/containers/storage*/overlay/l/HHEYNKOTQ2SEEH4BURDI5BO7GJ; ls -l /var/lib/containers/storage_readonly/overlay/l/」コマンドの出力もお願いします。

 HHEYNKOTQ2SEEH4BURDI5BO7GJ -> NIXJAI2YBZFOH5CTPK2P34ZNTX と読み替えた上で確認をしておりますが、
 /run/containers/storage および /run/containers/storage_root のどちらにも当該ディレクトリが存在しておりません。

取り急ぎ現状の回答となります。ご確認のほどよろしくお願いいたします。

at_dominique.m…

2023年7月10日 15時24分

ytr373さん、

マルティネです。

>  はい、失敗します。
>  先ほどstorage=tmpfs に移行後 podman_start を実行しましたが、
>  これまでと同様のエラーが出力されました。

今更ですみませんが、勘違いしていたかもしれません。
storage=disk で起動できているということでしょうか?

> > -「ls -l /run/containers/storage*/overlay/l/HHEYNKOTQ2SEEH4BURDI5BO7GJ; ls -l /var/lib/containers/storage_readonly/overlay/l/」コマンドの出力もお願いします。
>
>  HHEYNKOTQ2SEEH4BURDI5BO7GJ -> NIXJAI2YBZFOH5CTPK2P34ZNTX と読み替えた上で確認をしておりますが、
>  /run/containers/storage および /run/containers/storage_root のどちらにも当該ディレクトリが存在しておりません。

すみません、説明が足りませんでした。
そのコマンドのエラーは大丈夫です、可能なディレクトリが多いためリストしていますが、どこかにあるかを確認したかったです(/run のディレクトリに関しては確かに再起動の後に不要でしたね…)
二つ目の出力で /var/lib/containers/storage_readonly の方に NIXJAI2YBZFOH5CTPK2P34ZNTX があることを確認できました。

>  こちらの後半のコマンド実行結果を添付し忘れておりました。申し訳ございません。

ありがとうございます。

一方ずつでもうしわけないですが、 NIXJAI2YBZFOH5CTPK2P34ZNTX のリンク先を確認していただけますか:
ls -l /var/lib/containers/storage_readonly/overlay/a1b9f7ac3de6ce8e2c24ad8f3779be673735612db9ae6e87487d31aa5dffd70e
無事に存在していると思いますが、確かめていただければと思います。

storage=disk で無事に起動できていたらまたいくつかの確認させていただきたいので、返事をいただいた次第にまた連絡します。

よろしくおねがいします。

マルティネ様
 
 お世話になります。
 2つのご質問について、以下のように回答いたします。
 ご確認のほどよろしくお願いいたします。

> storage=disk で起動できているということでしょうか?

はい、diskでは起動できます。

> 「ls -l /var/lib/containers/storage_readonly/overlay/a1b9f7ac3de6ce8e2c24ad8f3779be673735612db9ae6e87487d31aa5dffd70e
> 無事に存在していると思いますが、確かめていただければと思います。

以下の結果が出力されます。

dr-xr-xr-x 1 root root   28 Jul  7 12:34 diff
-rw-r--r-- 1 root root   26 Jul  7 12:34 link
-rw-r--r-- 1 root root 1739 Jul  7 12:34 lower
drwx------ 1 root root    0 Jul  7 12:34 merged
drwx------ 1 root root    0 Jul  7 12:34 work

at_dominique.m…

2023年7月10日 16時04分

ytr373さん
> > storage=disk で起動できているということでしょうか?
>
> はい、diskでは起動できます。

了解しました。

そういうことでしたら、手動に podman でコンテナを実行していただけたら原因が分かると思いますので、以下のコマンドを試していただけたらと思います。

# 以下のコマンドをコピーペースト出きるようにコンテナ名を変数に保存します
# 行が長いのでご注意ください。
CONT=[container]
# ストレージの一時的なデータを削除します。すでに storage=disk でも実行してください。
podman kill -a && abos-ctrl podman-storage --disk
# 通常の runroot=tmpfs, 直接 root の確認(100%動くはずです)
podman --runroot=/run/containers/storage_test --root=/var/lib/containers/storage run --rm $CONT echo ok
# tmpfs と同じく root とイメージのストレージを別けます。root は btrfs のままです。
rm -rf /run/containers/storage_test
podman --runroot=/run/containers/storage_test --root=/var/tmp/storage_test --storage-opt additionalimagestore=/var/lib/containers/storage run --rm $CONT echo ok
# 同じく、root を tmpfs に移動します。これは tmpfs とほぼ同じなはずです。
rm -rf /run/containers/storage_test
podman --runroot=/run/containers/storage_test --root=/run/containers/storage_root_test --storage-opt additionalimagestore=/var/lib/containers/storage run --rm $CONT echo ok
# 逆に tmpfs にして、逆の順番を試します。切り替えのコマンドです。
abos-ctrl podman-storage --tmpfs; rm -rf /run/containers/storage_test /run/containers/stoarge_root_test  /var/tmp/storage_test
# tmpfs と近い状態
podman --runroot=/run/containers/storage_test --root=/run/containers/storage_root_test --storage-opt additionalimagestore=/var/lib/containers/storage_readonly run --rm $CONT echo ok
# root を btrfs にします
rm -rf /run/containers/storage_test
podman --runroot=/run/containers/storage_test --root=/var/tmp/storage_test --storage-opt additionalimagestore=/var/lib/containers/storage_readonly run --rm $CONT echo ok
# (読み取り専用になったため直接実行は実行できません)

よろしくお願いします。

マルティネ様

 

> CONT=[container]

echo $echo で [container] の表示を確認しました。

> podman kill -a && abos-ctrl podman-storage --disk

こちらの結果は以下のようになりました。

2c087ce66c1784be391f52d8296398f3dd9ffa6a9f5b894ad7b626188d7924fe
Delete subvolume (no-commit): '/mnt/containers_storage'
Creating configuration for persistent container storage
Create a snapshot of '/var/lib/containers/storage_readonly' in '/mnt/containers_storage'
Successfully switched podman-storage to disk
> podman --runroot=/run/containers/storage_test --root=/var/lib/containers/storage run --rm $CONT echo ok

こちらの結果は以下のようになりました。

Error: short-name "[container]" did not resolve to an alias and
no unqualified-search registries are defined in "/etc/containers/registries.conf"

上記のようにエラーとなったため、一旦報告させていただきました。
ここから先は実行しておりません。

ご確認のほどよろしくお願いいたします。

at_dominique.m…

2023年7月10日 16時48分

ytr373さん

> > CONT=[container]

すみません、以前のやりとりでコンテナの名前を [container] として出力から取り外されていましたので(armadillo:~# podman_start [container]等)、ここも [container] で代用させていただきました。

厳密では podman_start のコンフィグ名ではなく、イメージ名でお願いします。disk状態で podman run --rm $CONT echo ok で ok が出力されるはずです。

お手数ですが、名前を入れ替えてまたよろしくお願いします。

マルティネ様

 お世話になります。

> イメージ名でお願いします。disk状態で podman run --rm $CONT echo ok で ok が出力されるはずです。

 確かに ok が出力されました。ありがとうございます。

その後のコマンドは、1つを除き、これまでと同様 overlayfs: failed to resolve 'l/NIXJAI2YBZFOH5CTPK2P34ZNTX': -2
が出力されました。

>podman --runroot=/run/containers/storage_test --root=/var/tmp/storage_test --storage-opt additionalimagestore=/var/lib/containers/storage run --rm $CONT echo ok
 
>podman --runroot=/run/containers/storage_test --root=/run/containers/storage_root_test --storage-opt additionalimagestore=/var/lib/containers/storage run --rm $CONT echo ok
 
>podman --runroot=/run/containers/storage_test --root=/run/containers/storage_root_test --storage-opt additionalimagestore=/var/lib/containers/storage_readonly run --rm $CONT echo ok
 
>podman --runroot=/run/containers/storage_test --root=/var/tmp/storage_test --storage-opt additionalimagestore=/var/lib/containers/storage_readonly run --rm $CONT echo ok
>abos-ctrl podman-storage --tmpfs; rm -rf /run/containers/storage_test /run/containers/stoarge_root_test  /var/tmp/storage_test

こちらの結果は以下になりました。

Delete subvolume (no-commit): '/mnt/containers_storage'
Switching back to tmpfs container storage.
Successfully reverted podman storage to tmpfs
rm: cannot remove '/var/tmp/storage_test/overlay': Resource busy

以上、ご確認のほどよろしくお願いいたします。

at_dominique.m…

2023年7月11日 10時57分

ytr373さん

マルティネです。
いつもありがとうございます。
逆の順番で返事します。

> rm: cannot remove '/var/tmp/storage_test/overlay': Resource busy

これはあまり考えなくてもいいと思います。エラーの後に podman が overlay を umount しなかったみたいです。
残しても影響がないと思いますが、テストの続きの前に umount して削除しなおしてみていただけたらと思います:

umount /var/tmp/storage_test/overlay
rm -rf /var/tmp/storage_test

> その後のコマンドは、1つを除き、これまでと同様 overlayfs: failed to resolve 'l/NIXJAI2YBZFOH5CTPK2P34ZNTX': -2
> が出力されました。

ありがとうございます、原因に近づいてきました。

日本語が母国語じゃないので念のため確認しますが、abos-ctrl podman-storage --disk の後、一つ目の「podman --runroot=/run/containers/storage_test --root=/var/lib/containers/storage run --rm $CONT echo ok」だけが成功したであっていますね?

エラーの時の状況を確認したいので、お手数ですがまた以前と似たような情報を確認しますが前回は別の overlay マウントが残っていた可能性がありますので、別のディレクトリ / プロセスを確認しながら確認してみましょう。

# 念のための他のコンテナの停止
podman kill -a && podman rm -a
abos-ctrl podman-storage --disk
# overlay マウントが残っているかの確認(空のはず)
findmnt -r -o TARGET | grep overlay
# 空じゃなかった場合は、最後から umount させます。
findmnt -r -o TARGET | grep overlay | tac | xargs -r umount -v
# dmesg の出力を後でお願いしますので、実行前のクリアします
dmesg -C
# 必要な場合に設定しなおしてください
CONT=...
# 最初に失敗したいたコマンドに「--log-level=debug」を追加した物です。
# デバグメッセージにコンテナイメージの名前が表示されますので、
# 気になる場合は一時的なファイルに保存して search & replace などでイメージ名を消してください
# イメージ名以外の個人情報が表示されないはずです。
podman --log-level=debug --runroot=/run/containers/storage_test --root=/var/tmp/storage_test --storage-opt additionalimagestore=/var/lib/containers/storage run --rm $CONT echo ok
 
# 失敗の後の以下のコマンドの出力もいただけたらと思います
findmnt
dmesg 

よろしくお願いします。

マルティネ様

 お世話になります。

> 日本語が母国語じゃないので念のため確認しますが、abos-ctrl podman-storage --disk の後、
> 一つ目の「podman --runroot=/run/containers/storage_test --root=/var/lib/containers/storage run --rm $CONT echo ok」だけが
> 成功したであっていますね?

伝わりにくい記載で申し訳ありません。
ご認識のとおり、こちらのコマンドのみ成功しています。

>umount /var/tmp/storage_test/overlay
>rm -rf /var/tmp/storage_test

こちらを実行のうえ、いただいたコマンドを実行しました。
その結果を記します。

>podman kill -a && podman rm -a
 
bb264667efb47baa517779a9da6a394fbe792727a4f8e3b4990791576be62e66
(コンテナを動かす必要があったので、動作ささせていました)
 
>abos-ctrl podman-storage --disk
 
Delete subvolume (no-commit): '/mnt/containers_storage'
Creating configuration for persistent container storage
Create a snapshot of '/var/lib/containers/storage_readonly' in '/mnt/containers_storage'
Successfully switched podman-storage to disk
 
>findmnt -r -o TARGET | grep overlay
 
/run/containers/storage_root_test/overlay
 
>findmnt -r -o TARGET | grep overlay | tac | xargs -r umount -v
 
umount: /run/containers/storage_root_test/overlay unmounted
 
>dmesg -C
>CONT=[image name]
 
こちらは実行のみです。
 
>podman --log-level=debug --runroot=/run/containers/storage_test --root=/var/tmp/storage_test --storage-opt additionalimagestore=/var/lib/containers/storage run --rm $CONT echo ok
 
出力結果を podman_debug_result.txt として添付いたしました。
 
>findmnt
 
出力結果を findmnt_result2.txt として添付いたしました。
 
>dmesg
 
出力結果を dmesg.txt として添付いたしました。

以上ご確認のほどよろしくお願いいたします。

ファイル ファイルの説明
podman_debug_result.txt
findmnt_result2.txt
dmesg_result.txt

at_dominique.m…

2023年7月11日 13時10分

ytr373さん

ありがとうございます。

大変お手数をおかけしました、おかげさまでやっと再現できるようになって、原因が分かりました:
今の podman バージョンでレイヤーの数が多い場合に overlay のマウントコマンドが絶対パスではなく、相対パスを使うようになります。
(overlay: mount_data の行が overlay: mount_data=lowerdir=l/NIXJAI2YBZFOH5CTPK2P34ZN...ではなく、 mount_data=lowerdir=/var/lib/containers/storage/overlay/l/UHVBSRHG7RRWUQCUGC4R... であるべきでした)

storage=tmpfs のように additionalimagestore を使う場合にその相対パスの値が間違っていて、何もないところをマウントしようとしています、podman の不具合でした。

原因が分かったことでこちらで再現できました。そこは本当にすみません…このスレッドの早い段階に多い数のレイヤーを試してみたいましたが、当時は再現できていませんでした…
ちょうど 61 のレイヤーが必要なところに 60 で止まっていたかもしれませんが、恐らく間違って今月末リリース予定の新しいバージョンで実行していたと思います。そのバージョンでは podman 4.5.1 がアップグレードされて、podman 4.5.1 でこの不具合が修正されました:
https://github.com/containers/storage/commit/7c5964df95c892cfbdbce594cf… (v4.4.0 から入ったコミットです)
不具合のあったコンテナを podman save, podman load でアップグレードされた OS にコピーしたところ、確かに正常に動いています。

なので、何もしなくても今月末のアップデートを適用すれば tmpfs で動くようになりますが、そのコミットメッセージに書いている様にレイヤーがそんなに多いと遅くなりますので、レイヤーのマージしてみた方がいいと思います。以下の手順で試していたできますでしょうか。

# いつものリセット
podman kill -a; abos-ctrl podman-rw --disk
 
# $CONT のコンテナをそのまま new_container_name:version に保存して、 --squash-all でレイヤーをなくします
CONT=[container]
echo "FROM $CONT" | podman build -t new_container_name:version --squash-all
 
# 動作確認: tmpfs に入って新しいコンテナを実行することができるはずです
abos-ctrl podman-rw --tmpfs
podman run --rm new_container_name:version echo ok

よろしくお願いします。

at_dominique.m…

2023年7月11日 13時14分

ytr373さん

連続ですみません、先のコマンドに文字を一つ忘れていました

ビルドコマンドの最後に - があります:

echo "FROM $CONT" | podman build -t new_container_name:version --squash-all -

よろしくおねがいします

マルティネ様

 お世話になります。原因が明らかになり安心いたしました。 
 

> # いつものリセット
> podman kill -a; abos-ctrl podman-rw --disk

ここで以下のエラーが出力されます。

WARNING: /usr/sbin/abos-ctrl podman-rw does not make sense with podman-storage as disk, running podman
Error: unknown flag: --disk
See 'podman --help'

対応方法をご教示いただけますでしょうか。

at_dominique.m…

2023年7月11日 14時14分

ytr373さん

> WARNING: /usr/sbin/abos-ctrl podman-rw does not make sense with podman-storage as disk, running podman
> Error: unknown flag: --disk
> See 'podman --help'

すみません、私も安心して気を抜けました。そこは以前の様に「abos-ctrl podman-storage --disk」のつもりで間違ったコマンドを書きました。その次の tmpfs の切り替えも同じですね。

改めて書くと(今度は確認しました):

podman kill -a; abos-ctrl podman-storage --disk
CONT=[container]
echo "FROM $CONT" | podman build -t new_container_name:version --squash-all -
 
abos-ctrl podman-storage --tmpfs
# ^ でデフォルトの copy 選択
podman run --rm new_container_name:version echo ok

よろしくお願いします

マルティネ様

 早々の返信ありがとうございます。
 コマンド実行結果を以下に示します。

> podman kill -a; abos-ctrl podman-storage --disk
 
Delete subvolume (no-commit): '/mnt/containers_storage'
Creating configuration for persistent container storage
Create a snapshot of '/var/lib/containers/storage_readonly' in '/mnt/containers_storage'
Successfully switched podman-storage to disk
 
> CONT=[container]
 
イメージ名で実行
 
> echo "FROM $CONT" | podman build -t new_container_name:version --squash-all -
 
STEP 1/1: FROM [old_name]:v1.0.0
COMMIT [new_name]:v1.0.0
Getting image source signatures
Writing manifest to image destination
Storing signatures
--> 27d43b1130c
Successfully tagged localhost/[new_name]:v1.0.0
27d43b1130c4770f6d8fba1e2728d3f55918fbea020a04acda56e4c8d39322ab
 
> abos-ctrl podman-storage --tmpfs
> # ^ でデフォルトの copy 選択
 
What should we do? ([C]opy (default), [N]othing, [D]elete)
C
Delete subvolume (no-commit): '/mnt/containers_storage'
Replacing development images to readonly storage succeeded
Switching back to tmpfs container storage.
Successfully reverted podman storage to tmpfs
 
> podman run --rm new_container_name:version echo ok
 
ok

at_dominique.m…

2023年7月11日 16時52分

ytr373さん

>> podman run --rm new_container_name:version echo ok
> 
> ok

これで正常に動いていますので、元のイメージ名として保存して使うか、podman_start のコンフィグに新しいコンテナを使うのでも tmpfs モードで実行できると思います。

また何か問題ございましたらまた聞いてください。

マルティネ様

 お世話になります。
 tmpfsモードで動作することを確認いたしました。ありがとうございました。

 今回の原因が「レイヤーが多く存在している状態でのpodmanの不具合」と理解しましたが、
 そもそもレイヤーが多く存在しないようする手立て(コマンドの実行等)はあるのでしょうか。

at_dominique.m…

2023年7月12日 8時10分

ytr373さん

>  今回の原因が「レイヤーが多く存在している状態でのpodmanの不具合」と理解しましたが、

はい、podman 4.3.1 (現在のバージョン)では disk モードで 128 レイヤーで動かなくなりますが、podman の不具合によって tmpfs モードで 60-61ぐらいのレイヤー数で失敗するようになります。
今月末にリリースされる ABOS 3.18.x-at1 には podman 4.5.1 もアップグレードされていて、レイヤーの数は 500 まで実行できるようになります(disk/tmpfsモード両方)
新しいバージョンで「できる」としても、レイヤーが多いと効率があまりよくないので、レイヤーの数を50ぐらいまでにした方がいいと思います。(ベースのレイヤーにあるファイルを読むと、すべてのレイヤーを確認しないといけないので実行が少し遅くなりますし;ファイルを何回か上書きするとそのファイルを何回か保存することになりますので全体的な使われている容量も必要以上に増やします)

>  そもそもレイヤーが多く存在しないようする手立て(コマンドの実行等)はあるのでしょうか。

レイヤーは podman commit や build を実行する度に増やしますので、原理としては「コンテナを少ないステップで生成する」が理想です。
そうするには Dockerfile に必要なパッケージやファイルだけを書いて、podman build で一気にコンテナを作ることが一番便利ですね:
- Dockerfile にベースコンテナから編集したものすべてが記載されているので、自分のアプリケーションに必要な内容を簡単に把握できます
- ベースの OS を更新する時に簡単に作り直せます

英語の README しか書いてない公人のリポで申し訳ないですが、興味があれば https://github.com/martinetd/G4_container_updater はコンテナのビルドから swu のイメージ作成とその自動インストールまでを github action で実行するリポジトリです。(見返してみれば説明がちょっと少なかったので、ちょっと更新した方がいいかもしれません…)

その理想をさっておき、昨日の podman build コマンドの --squash-all オプションと podman commit の --squash オプションで新しいコンテナを保存するときにレイヤーの情報をすべて捨てて新しいレイヤー一つでコンテナを作るコマンドもありますので、作業をこのままにしても定期的に podman commit --squash で保存することてレイヤーの数を減らせます。

よろしくお願いします。

マルティネ様

お世話になります。

詳細な情報ならびにコマンド・オプションの件、ありがとうございました。
今後の開発時に活用させていただきます。

今回はどうもありがとうございました。

マルティネ様

 お世話になります。

> -「ls -l /run/containers/storage*/overlay/l/HHEYNKOTQ2SEEH4BURDI5BO7GJ; ls -l /var/lib/containers/storage_readonly/overlay/l/」コマンドの出力もお願いします。

 こちらの後半のコマンド実行結果を添付し忘れておりました。申し訳ございません。

ファイル ファイルの説明
storage_readonly_result.txt