Open markmandel opened 1 month ago
Also possibly worth noting ltsc2022
, works still. We tested it!
which image is Using the previous SHA of @sha256:6fdf140282a2f809dae9b13fe441635867f0a27c33a438771673b8da8f3348a4 worked.
in reference too?
which image is
Using the previous SHA of @sha256:6fdf140282a2f809dae9b13fe441635867f0a27c33a438771673b8da8f3348a4 worked.
in reference too?
mcr.microsoft.com/windows/servercore:ltsc2019
For reference, we have this PR now in place to unblock CI: https://github.com/googleforgames/agones/pull/3829
Tried it myself on a build node I have been using for years, though I have updated docker buildx since:
docker buildx version
github.com/docker/buildx v0.12.1 30feaa1a915b869ebc2eea6328624b49facd4bfb
I did use this version before KubeCon, and I did use mcr.microsoft.com/windows/servercore:ltsc2019
as a base image for the presentation where I talked about building Windows images. So, I think the image is the issue (Microsoft publishes a new image monthly).
This looks to be an issue with the image patches released Yesterday (May 14th). Work around is use April's patch images as done in https://github.com/microsoft/Windows-Containers/issues/493#issuecomment-2112937642
/cc @akarshm
Adding link to the slack discussion where we narrowed it down to the patch release https://kubernetes.slack.com/archives/C0SJ4AFB7/p1715733067064539
/cc @profnandaa
UPDATE: we've been investigating this issue, a few things worth noting:
COPY
but it is happening at the tail-end of FROM
and so the reporting just estimates to the next line on the Dockerfile.The issue is to do with extraction of the latest delta layer on ltsc2019
:
=> extracting sha256:0dd0445527a5079720e935502b31de927b8e22e5ca358026cf0bc8845c5ba5ce
There's only one "offending" file Windows/INF/basicrender.inf
(and its hardlinks); it so happens that on the TAR header (metadata), it's referenced as lowercase basicrender.inf
, when the actual file in the layer is BasicRender.inf
. Since Windows is not case-sensitive when it comes to files, this issue is only evident when the link
operation is done on Linux (which is case-sensitive). Therefore, it reports as file-not-found. RCA is still going on to fix the issue.
PS. will be nice to re-tittle the issue to FROM/layer-extraction on ltsc2019 fails: "mount callback failed"
Hello, is there any plan / timeline to fix Windows images to be usable on Linux? We as Kubernetes community cannot release our images based on the mcr.microsoft.com/windows/servercore:ltsc2019@latest
tag. It's not super critical, at least now, but you never know when a CVE comes and we will need to release images immediately.
@jsafrane -- a fix is currently going through validation; will update here once it's released.
hi, @profnandaa, can I gently ask you about a rough ETA for a fix?
Describe the bug
COPY
commands have been working normally for years with our lts2019 windows container build on Agones, but started failing today with an error message of:Where
${WINDOWS_VERSION}
isltsc2019
To Reproduce
To reproduce this, just try copying something in:
(Assuming you have a buildx builder already)
Expected behavior
The image should build 😃
Configuration:
Additional context
You can see a full build output from the Agones build pipeline here: https://console.cloud.google.com/cloud-build/builds/70b984e2-132b-4d1a-915a-862cb03f4830;step=16?e=13803378&project=agones-images
Using the previous SHA of
@sha256:6fdf140282a2f809dae9b13fe441635867f0a27c33a438771673b8da8f3348a4
worked.