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コマンドでコンテナ情報を削除し、バックアップしたイメージから再ロードしてみましたが、同じ状況となりました。
これは当方の設定に因るものか、何かしら解決する手段があるものなのかいずれでしょうか。
もし後者である場合は、手段をご教示いただけますと幸いです。
よろしくお願いいたします。
コメント
ytr373
マルティネ様
お世話になります。早々の回答ありがとうございます。
> 上記では、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…
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」のような記録を記載していますので、参考にできるかもしれません。
よろしくお願いします。
ytr373
マルティネ様
お世話になります。
いただいた返信をもとに作業を実施しました。
結論を申し上げますと、最初の投稿と同様のエラーが発生し、コンテナは起動できませんでした。
以下、各コマンドの実行結果になります。
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…
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 ファイルを展開したら恐らく最終てきにできていたイメージの状態にもどると思います。
どのパターンでも大変な作業になっていて本当に申し訳ございません。
ご迷惑ですが、情報をいただけたら原因に近づけると思いますので、付き合っていただけたら大変助かりますがここからイメージを作り直した方が早いかもしれません。
上記に説明した様にバックアップのレイヤーからファイルを参考にしていただければある程度の時間の節約ができると思います。
よろしくお願いいたします。
ytr373
マルティネ様
お世話になります。確認いただきありがとうございます。
ご質問いただいた件、以下のように回答いたします。
> まず、先ほどの 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…
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]
大変お手数ですが、よろしくお願いします。
ytr373
マルティネ様
お世話になります。
前後しますが、結果等について以下のように回答いたします。
> 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…
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/
」コマンドの出力もお願いします。
お手数ですが、よろしくお願いいたします。
ytr373
マルティネ様
お世話になります。返信ありがとうございます。
> 今の回答では、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…
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 で無事に起動できていたらまたいくつかの確認させていただきたいので、返事をいただいた次第にまた連絡します。
よろしくおねがいします。
ytr373
マルティネ様
お世話になります。
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…
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 # (読み取り専用になったため直接実行は実行できません)
よろしくお願いします。
ytr373
マルティネ様
> 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…
ytr373さん
> > CONT=[container]
すみません、以前のやりとりでコンテナの名前を [container] として出力から取り外されていましたので(armadillo:~# podman_start [container]
等)、ここも [container] で代用させていただきました。
厳密では podman_start のコンフィグ名ではなく、イメージ名でお願いします。disk状態で podman run --rm $CONT echo ok
で ok が出力されるはずです。
お手数ですが、名前を入れ替えてまたよろしくお願いします。
ytr373
マルティネ様
お世話になります。
> イメージ名でお願いします。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…
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
よろしくお願いします。
ytr373
マルティネ様
お世話になります。
> 日本語が母国語じゃないので念のため確認しますが、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…
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…
ytr373
マルティネ様
お世話になります。原因が明らかになり安心いたしました。
> # いつものリセット > 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…
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
よろしくお願いします
ytr373
マルティネ様
早々の返信ありがとうございます。
コマンド実行結果を以下に示します。
> 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…
ytr373
at_dominique.m…
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 で保存することてレイヤーの数を減らせます。
よろしくお願いします。
ytr373
ytr373
マルティネ様
お世話になります。
> -「ls -l /run/containers/storage*/overlay/l/HHEYNKOTQ2SEEH4BURDI5BO7GJ; ls -l /var/lib/containers/storage_readonly/overlay/l/
」コマンドの出力もお願いします。
こちらの後半のコマンド実行結果を添付し忘れておりました。申し訳ございません。
ファイル | ファイルの説明 |
---|---|
storage_readonly_result.txt |
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 を別けたまま開発していて:
そこで --tmpfs に切り替えた時に storage_readonly の部分が削除されて、ベースのレイヤーがなくなったことでコンテナを使えなくなりました。
新しい BaseOS では最初の切り替えで split 運用しなくなりましたのでこのリスクもなくなりましたし、--tmpfs から戻る時にもちゃんと確認して削除ではなく合流の形でマージするはずですが、同じ ABOS のバージョンで確認したいので教えてください。
> abos-ctrlコマンドでコンテナ情報を削除し、バックアップしたイメージから再ロードしてみましたが、同じ状況となりました。
バックアップというのは、「/var/lib/containers/storage」のディレクトリだけでしょうか?他にも何かありますか?
大変お手数をおかけしますが、対応はバージョンを確認して、現状を確認した後に説明させてください。
場合によってはベースのレイヤーを rollback側にまだある可能性もありますので、その返事まで更新をしないでください。
よろしくお願いします