-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
when a directory with symlinks is copied, the symlinks are badly created in the target image #437
Comments
When we execute multistage builds, we store the fs of each intermediate stage at /kaniko/<stage number> if it's used later in the build. This created a bug when extracting hardlinks, because we weren't appending the new directory to the link path. So, if `/tmp/file1` and `/tmp/file2` were hardlinked, kaniko was trying to link `/kaniko/0/tmp/file1` to `/tmp/file2` instead of `/kaniko/0/tmp/file2`. This change will append the correct directory to the link, and fixes GoogleContainerTools#437 GoogleContainerTools#362 GoogleContainerTools#352 GoogleContainerTools#342.
When we execute multistage builds, we store the fs of each intermediate stage at /kaniko/<stage number> if it's used later in the build. This created a bug when extracting hardlinks, because we weren't appending the new directory to the link path. So, if `/tmp/file1` and `/tmp/file2` were hardlinked, kaniko was trying to link `/kaniko/0/tmp/file1` to `/tmp/file2` instead of `/kaniko/0/tmp/file2`. This change will append the correct directory to the link, and fixes GoogleContainerTools#437 GoogleContainerTools#362 GoogleContainerTools#352 GoogleContainerTools#342.
When we execute multistage builds, we store the fs of each intermediate stage at /kaniko/<stage number> if it's used later in the build. This created a bug when extracting hardlinks, because we weren't appending the new directory to the link path. So, if `/tmp/file1` and `/tmp/file2` were hardlinked, kaniko was trying to link `/kaniko/0/tmp/file1` to `/tmp/file2` instead of `/kaniko/0/tmp/file2`. This change will append the correct directory to the link, and fixes GoogleContainerTools#437 GoogleContainerTools#362 GoogleContainerTools#352 GoogleContainerTools#342.
@priyawadhwa retested with latest debug image. problem is still reproducable |
@mtsyganov sorry about that, I reopened the issue |
@priyawadhwa Where is this on the list of priorities? This is a major blocker for my particular use case. If low on your list I'd consider picking this up, but would be really happy if a fix is coming soon. EDIT: Looks like #459 is in the works! Any chance someone take a look at this? |
@mtsyganov and @andrewrynhard, I just merged #459, does that fix your respective bugs? |
Dear @priyawadhwa we had the same error during the use of kaniko in a custom image, I assume, it would be a good idea, to start the build with a "delete FS", what do you think ? |
@miguelitoq76 sorry, I'm a bit confused -- do you want kaniko to delete the filesystem before starting the image build? Wouldn't that essentially be the same as directly using the kaniko image (which is built from scratch)? |
Triage - collapsing 'waiting for response' category into 'blocked' |
I am unable to repro this issue; leading me to think that it has since been fixed. If this issue can still be repro'd please share the appropriate steps to do so. |
Still got this with fresh gcr.io/kaniko-project/executor:debug GitLab CI + Kaniko |
@Kami-no would you mind sharing an example Dockerfile and the options you are passing to kaniko? |
Is this related to #1036 ? |
Actual behavior
In the multistage build process when a directory with symlinks is copied, the symlinks are badly created in the target image. Too many levels of symbolic links are generated.
Expected behavior
Symlinks are copied from source image into the target image as they are created in the source image
To Reproduce
Steps to reproduce the behavior:
/usr/local/psql/bin/postmaster -> postgres
(you can checkregistry.gitlab.com/gitlab-org/build/cng/postgresql:9.6.8
)COPY --from=pg_image /usr/local/psql/bin/ /usr/bin/
/usr/local/psql/bin/postmaster -> postgres
, but in the target image as/usr/bin/postmaster -> /usr/bin/postmaster/postgres
. Correct symlink should be in the target image/usr/bin/postmaster -> postgres
Additional Information
The text was updated successfully, but these errors were encountered: