search

confidential-containers / guest-components

Confidential Containers Guest Tools and Components
Apache License 2.0
83 stars 95 forks source link

image-rs | failed to handle image layers that has long name hard link file inside #689

Closed Xynnn007 closed 2 months ago

Xynnn007 commented 3 months ago

Thanks to @bpradipt , we found that image-rs currently cannot pull image layers that have long name hard link file (more than 100 chars) layer. Errors like the following

running 1 test
test pull::tests::test_async_pull_client has been running for over 60 seconds
test pull::tests::test_async_pull_client ... FAILED

failures:

---- pull::tests::test_async_pull_client stdout ----
Got error on function call attempt 0. Will retry in 1s: failed to handle layer: hasher sha256: failed to unpack `/tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.pyc`

Caused by:
    No such file or directory (os error 2) while canonicalizing /tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.opt-1
Got error on function call attempt 1. Will retry in 1s: failed to handle layer: hasher sha256: failed to unpack `/tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.pyc`

Caused by:
    No such file or directory (os error 2) while canonicalizing /tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.opt-1
Got error on function call attempt 2. Will retry in 1s: failed to handle layer: hasher sha256: failed to unpack `/tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.pyc`

Caused by:
    No such file or directory (os error 2) while canonicalizing /tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.opt-1
Got error on function call attempt 3. Will retry in 1s: failed to handle layer: hasher sha256: failed to unpack `/tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.pyc`

Caused by:
    No such file or directory (os error 2) while canonicalizing /tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.opt-1
Got error on function call attempt 4. Will retry in 1s: failed to handle layer: hasher sha256: failed to unpack `/tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.pyc`

Caused by:
    No such file or directory (os error 2) while canonicalizing /tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.opt-1
thread 'pull::tests::test_async_pull_client' panicked at image-rs/src/pull.rs:279:13:
Function did not return Ok after retries: last_err Some(failed to handle layer: hasher sha256: failed to unpack `/tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.pyc`

Caused by:
    No such file or directory (os error 2) while canonicalizing /tmp/.tmpZkP1l0/sha256_0f3abe6724adb8f4c40655dc274e98dad2dadb3f5ea88efe3c7d76a1983ca3b5/usr/lib/python3.12/site-packages/dnf-plugins/__pycache__/generate_completion_cache.cpython-312.opt-1)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:
    pull::tests::test_async_pull_client

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 49 filtered out; finished in 72.48s

Two typical images triggering this

This is not supported by underlying krata-tokio-tar crate. Related issue in tar (tokio-tar is based on that) is https://github.com/alexcrichton/tar-rs/issues/369

Xynnn007 commented 3 months ago

cc @arronwy

bpradipt commented 2 months ago

The issue doesn't occur if switching back to older implementation of using sync tar, ie before commit 921006fe7e04241057685bba16770320f5388d81

Xynnn007 commented 2 months ago

The issue doesn't occur if switching back to older implementation of using sync tar, ie before commit 921006fe7e04241057685bba16770320f5388d81

Good. It means that the sync tar had implemented this, thus we could have a good teacher to learn from to promote async-tar.

Xynnn007 commented 2 months ago

I put the fix PR on original krata-tokio-tar https://github.com/edera-dev/tokio-tar/pull/2. Let see if any progress.

JakubLedworowski commented 2 months ago

Hi @Xynnn007, looks like for the last weeks the PR you created has not yet been merged. I bumped it mentioning the repository owner. In the meantime, have you possibly found a way to workaround this?

Xynnn007 commented 2 months ago

@JakubLedworowski Thanks for raising that up in the thread. Up to now I have only two ways except waiting for upstream

  1. create a fork code
  2. try to use shorter names for images

Both might be difficult. Do you have any ideas? @bpradipt

bpradipt commented 2 months ago

@Xynnn007 let's wait till this week to see if there is any update to the PR. Otherwise we can plan to fork the code and keep it under coco org. Option-2 is not practical imho

azenla commented 2 months ago

Apologies for jumping in on this issue but wanted to communicate somewhere with folks :)

First, I didn't know our fork was being used for Confidential Containers but that's super cool given that we are have similar goals at Edera (we aren't aiming to be confidential only, our platform provides isolation in general, with confidentiality being a feature add)! I just published release v0.4.1 of krata-tokio-tar with the necessary change, and v0.4.2 which swaps to portable-atomic for atomics, broadening platform support for krata-tokio-tar.

Now that I am aware of it's use, I'd be happy to make our fork a collaborative effort. Please feel free to contact me at alex AT edera.dev if there are any questions!