Comments (12)
nlewo
commented on August 28, 2024
@nktpro Hm, i'm not able to reproduce:
nix run -L -v '.#packages.x86_64-linux.reproducer.copyToPodman'
Copy to podman image reproducer:jg504al70c43kw4888wv2frpx5jsbc9h
Getting image source signatures
Copying blob ba1cde528580 done
Copying config eed45dc400 done
Writing manifest to image destination
Storing signatures
{
"Name": "docker.io/library/reproducer",
"Digest": "sha256:2ee0148edebc4d46ce2c5f65744319fc2bd82ddf609a36f4382b58884bcf67f9",
"RepoTags": [],
"Created": null,
"DockerVersion": "",
"Labels": null,
"Architecture": "amd64",
"Os": "linux",
"Layers": [
"sha256:ba1cde52858099b4cfdde3e4503eab88300593d4bab604a85a2d04f418b6f39b"
],
"Env": null
}
Are you on x86-linux machine?
from nix2container.
nktpro
commented on August 28, 2024
@nlewo I was testing this in an aarch64-darwin environment (Apple Silicon Macs). It indeed works correctly under both aarch64-linux and x86_64-linux, so I'm suspecting it's something along the line of this #23
The use case, which I believe is quite common among devs, is developing using Macs (darwin) with remote building Nix Linux servers. Essentially one would nix2container.buildImage remotely (yet seamlessly thanks to nix), then push the images locally for testing (to either a local Docker daemon with Docker Desktop or a local Docker Registry in a local Kubernetes cluster).
nix2container is such a perfect solution for this usage pattern across platforms because there's zero overhead of actually building all the layers and physically storing them on disk back to the nix store prior to pushing.
For some reasons the calculated digests based on the local /nix store on Darwin differ from Linux, very much like that other issue that had a workaround. Most packages I tested so far worked fine though, so there's something odd about that ncurses package. If you're interested, may I donate a remotely accessible Mac (like one hosted on https://www.macstadium.com/) which would help investigating further?
from nix2container.
nlewo
commented on August 28, 2024
If you're interested, may I donate a remotely accessible Mac
@nktpro if it's not too late, i would be interested in. You can ping me on matrix (lewo on the nixos chan) or by email with details.
Another approach would be to generate archive with image.copyTo docker-archive://tmp/archive.tgz on both architectures in order to compare the content of these archives. Diffoscope is really nice for this kind of need since it can take archives as input.
from nix2container.
nlewo
commented on August 28, 2024
@nktpro first of all, thanks for the remote mac access ;)
When we build the image (nix build ...), there is this file in the store: /nix/store/2y4hnw5zc2mjz9kc61n3pdgr35rc7r2s-ncurses-6.3-p20220507/share/terminfo/2/2621a -> ../h/hp2621
When we copy the image with Skopeo as user, Skopeo see this file instead: /nix/store/2y4hnw5zc2mjz9kc61n3pdgr35rc7r2s-ncurses-6.3-p20220507/share/terminfo/2/2621a~nix~case~hack~1 -> ../h/hp2621
Since filename are differents, the tar checksum differ (maybe there are some other differences).
Because I know nothing about macos, macos filesystem, nix hacks for macos, i don't know how we could fix this issue yet...
from nix2container.
nlewo
commented on August 28, 2024
The digest mismatch is due to the fact the MacOS filesystem (apfs) is case-insensitive. The Nix deamon use-case-hack settings is set to true, meaning filename are modified to support case-sensitive files on a case-insensitive FS. I think 2621a~nix~case~hack~1 is used to encode 2621a.
When the image.json file is built on your aarch64 machine with a case-sensitive FS, the filename 2621A is used: the layer hash is computed on an archive containing the filename 2621A and 2621a.
However, when Nix copies the built closure on the MacOS FS, which is case-insensitive, it needs to encode filenames to avoid collisions (2621a is rewritten to 2621a~nix~case~hack~1). To copy the image, Skopeo reads this filename to stream the archive: the archive then contains a filename 2621a~nix~case~hack~1 and hashes mismatch.
So, that's a weird issue... and i see two solutions.
-
you could isolate the ncurses storepath into a dedicated layer with the flag
reproducible=False. The layer is then no longer computed by Skopeo but stored as an archive. -
we could patch the Skopeo Darwin build: when the nix2container Go library (used by Skopeo) generate the tar stream, it could rewrite filenames containing the pattern
~nix~case~hack~1. I think this would make your use case working. However, if someone generates theimage.jsonfile on MacOS (with apfs) and useskopeo copyon the same machine, hashes would then differ :/ Note i don't know if this use case makes sense.
from nix2container.
nktpro
commented on August 28, 2024
Thanks @nlewo for looking into this! That's indeed one heck of an issue...
you could isolate the ncurses storepath into a dedicated layer with the flag reproducible=False. The layer is then no longer computed by Skopeo but stored as an archive.
I quickly tested this approach on a few existing real-world image builds, and the rabbit hole is quite deep. So far I found 3 very common transitive dependencies that share this same problem, which are ncurses, perl are iptables. Explicitly throwing them into reproducible=false layer indeed did seem to work around this. However, it requires surfacing those problematic transitive dependencies as explicit dependencies. Over time, after many changes from different people, it's also hard to keep track of whether some of those transitive-turned-explicit dependencies are still part of the graph or not :(. Applying this across many dozens of image definitions is quite a chore...
we could patch the Skopeo Darwin build: when the nix2container Go library (used by Skopeo) generate the tar stream, it could rewrite filenames containing the pattern
nixcasehack1. I think this would make your use case working.
This definitely sounds viable. It's a bit of extra "magic" to reverse the prior "magic" from Nix daemon, but does not share any shortcomings of the 1st route.
However, if someone generates the image.json file on MacOS (with apfs) and use skopeo copy on the same machine, hashes would then differ :/ Note i don't know if this use case makes sense.
As far as I have seen, generating the image.json file natively on macOS has never been practically viable vs. remote building the derivation on a Linux machine with the right arch. It wouldn't work anyway because there's almost always intermediate derivations that require being on the right arch to build, especially when building multi-arch images (targeting both amd64 and arm64)
The only practical use case is being able to efficiently stream-push the downloaded nix store (whether from the remote builders or straight from a nix binary cache) to a local Docker daemon or local container registry for rapid testing. It's so efficient with nix2container because most of the time all the different store paths are already cached locally on the Macs once, which makes the pushes near instant.
from nix2container.
nlewo
commented on August 28, 2024
So, #55 should improve the situation. This would allow us to avoid the FS file order issue ;)
from nix2container.
nlewo
commented on August 28, 2024
Fixed by #48.
from nix2container.
purefn
commented on August 28, 2024
Sorry to comment on an old issue, but I'm encountering a "digest mismatch" when pushing images to gitlab and to ECR on a x86_64-linux docker container running on an AWS EC2 instance. I'm not sure of the best way to diagnose the problem. Could one of you point me in the right direction? I would really appreciate it!
from nix2container.
nlewo
commented on August 28, 2024
@purefn It could be because of some differences between storepaths read at buildtime from storepaths read at runtime. At buildtime, nix2container generates the hash of the layer which is then also computed by the registry when the image is pushed (at runtime).
So, the first thing to do is to compare buildtime and runtime layers.
To do that, you could first start by generating the layer at runtime: you can run image.copyTo "docker-archive://tmp/image.tgz". Then, to generate the layer at buildtime, you can set the attribute reproducible = false;` in your image/layer definition. Nix will build the JSON manifest and a storepath containing the layers in tarballs.
Your could then compare these tarballs to find the differences.
Let me know if i need to provide more detail. (Ideally, i should write a guide to do that...)
from nix2container.
purefn
commented on August 28, 2024
Unfortunately I ended up needing to restructure somethings because I was using buildImage and it doesn't support the reproducible attribute. So I had to move things into layers and that made the problem go away for now. I'll have to wait for the problem to recur.
from nix2container.
purefn
commented on August 28, 2024
This is very strange. I'm not sure what is going on. Here's what I just discovered.
I had a build which was able to successfully push the docker image. In the build, this command was run by the nix2container copy-to script.
skopeo --insecure-policy copy nix:/nix/store/a4bqbj7krc6x40rfq45r59y79xyba09m-image-arbiter-core.json docker://registry/core:ed71c174
Getting image source signatures
Copying blob sha256:639fd8a4a6db43c96e68915b59a9e07fd87c41b32bdd747ec16f901ab918f871
Copying blob sha256:df9b9388f04ad6279a7410b85cedfdcb2208c0a003da7ab5613af71079148139
Copying blob sha256:82a7668656be571e4946e03c7ce13e70c563534f99bfb7b11451d2015789494e
Copying blob sha256:93a7bb3510ad4da878b5f7c7df1168a9a688821469c57a61318eab3d7353d5cb
Copying blob sha256:b5515e63b39777771c7e229485666ece0560afc5928f79f63d27a46fe8749b8c
Copying blob sha256:bbd58c630c9658bfb87bca16cb9d1026eba45f9e394219573a1c7577751f7be4
Copying blob sha256:8afca76230176d09bc180c0133c247fe2af1cb1b8a49ea2084c76e4158af39fb
Copying blob sha256:c29256576a3908e48137040a1ba2be8baf05a78adddd74c142f305a9a71a39f3
Copying blob sha256:a38eb251c6c16e4d28cd6d4d4f50153fcaac03199a0e8fb749b4d0522b98d46a
Copying blob sha256:e24256f2d5fe9ad9f6f171ef9ad80bcb554cf397048e07f9bef144854f5df2f3
Copying blob sha256:981d26dcfe13049410ca38fe4975681043a43baf74d2abb1e2a83d557a42b540
Copying blob sha256:566827c8277b7d98785aecb5a42f580271176d9761f821c4635c86cd59754d26
Copying blob sha256:7f649fd2858dbfd739cb7c1ba5ff775c28d5481d2fbd4d6acd4df3b533f9215d
Copying blob sha256:813915ea84157954369af64380b8563611b88f84d4d5a2d38cc96df74602f53f
Copying blob sha256:3c5f6a41d8855658ceffbd80ccf8a50af8cb2180a875dc350c0ab8f4436a8b66
Copying blob sha256:56cb46dfe4bf3aaedf5f8a84167d892be45078b9702d547a9f75c0fa860d3cb2
Copying blob sha256:bcaf034240bb0b7c8b30d549ea1b4861bb25e448ca267a07a3eb98237067aeb7
Copying blob sha256:1c8426bea4c0e362ff2078f43a7178150a3456c8ea952a27a4809ab317107b05
Copying blob sha256:35656bd34ca46ffb905d34dcf748df53369c17bd6c42fd686349459d91fe1a78
Copying blob sha256:47a41c1b947f98aedf68d8826fcbab15dae72f9d6fe535d993d5e14ca9f879cc
Copying blob sha256:c9d39247cbd60213cabe901a704bf3b71ac7a1dadee755e6154dcdc91d7d2907
Copying blob sha256:08993adc665dd0553074c28faf096ae6254e989e9df473aa7d308aaf94573cf6
Copying blob sha256:bc4c7780a68911fe66713e7fb0f88546cf2e4a5448b73eea5142e8e743ebbdb2
Copying blob sha256:3da0aeff836abcf75c05ef33c094669c22527c0fa897b06d382678a467cb5f34
Copying blob sha256:e402beee672d473779f35d08cf55b5776cf00fb73406dd93c051606a58825a34
Copying blob sha256:65cc5570a241af8c2c5a13a6450540a85bcb01efe93b8910d863d1c2b1261461
Copying blob sha256:dedd3d6f86825067eaa1e506cfa771db092fb194a2663d9a12df82ffbdb58427
Copying blob sha256:219d2b10e1d12898905e4ecf39e47001f67bb79b89240bd33adcc700c7eb085d
Copying blob sha256:5852a018582729818ae4a61884ca5260ec67763eee86551ec816b93cd38ac52a
Copying blob sha256:a33c2f561dcc0931888056da8307d6fa61855ed68fbfbab5e6e82d4d292fe4e6
Copying blob sha256:67868eb5684da4c550ccb5d32d649b3ae8b41e2bf4adae8e872c3501e674806a
Copying blob sha256:1bee95ccc233abefa5ab6b69817d133d993754bac00c6a79c64ebdc3ba633c85
Copying blob sha256:fbf290c6f7a9db913151342d3ee094b4887dffdc6b5fa71327eb597a18f8a1d7
Copying blob sha256:28d61e4ede357b478abf1312b40f7814f4629fd5d35100704b90cefe7428821e
Copying blob sha256:040abbb15aee45cc7b903a083e310025ef05f42436292bf9895ab275a32b4796
Copying blob sha256:4267860e53e9c543b5b49f1fee0e1dba66f212e6b50e93269f2b19d6875a7fa3
Copying blob sha256:62b890afbd6afc4709db6c0b4c9289846b348f51b8589c8b8772fd6e8f209f04
Copying blob sha256:a6e22137551023518b5d9c76e5479bd1309fa235a0aab165d5578b28a8c72460
Copying blob sha256:3f7f997a22fb0af2569bb73fb927b25b98188db6467dab0db7b17d142ee279f7
Copying blob sha256:0ed217356b0362952ab0e4acde679ead84a4c1a848c177f3b8873418f59ed1e4
Copying blob sha256:50963d3c40e4e658a373e9557a7df250f440d56688dcb9aecf8c2a4c667956cb
Copying blob sha256:639934261bce11ca7649beb2802d86c91befd90a13f9362f948e7101353f864d
Copying blob sha256:f00e96af5b78d20de9e8ae19bca46d6027a866dc83f9c286230d98cd8026bca1
Copying blob sha256:a5890285d709f32d843449ed38e37fafdfd8eec2e059ced00f8ce18a34bbf83f
Copying blob sha256:495a599fbeb5390e0b0f234eaaab62a50c30512dd5c1cd6e6ec61b79ae55398f
Copying blob sha256:88303e747e48480922d2e5bdf0c738df960c463763f9e72f1a61fc4269934e3e
Copying blob sha256:30e76fb9fa8c2b3563826cd1721b86a6f82509fd72a8b7a00e0022d935a813b7
Copying blob sha256:08844a71d64e5b70fdd1d819167a598179f6b4ee17363ff4328fba211d258905
Copying blob sha256:d954ef953d842816165b69f417f08c0aec6dd02c3b3f3189c467aa6421b3e6ed
Copying blob sha256:c1ce536cdd3f25191c75ed07db475f40a209be6356da6931a0125d74583d8323
Copying blob sha256:1d2d0056b1f473565949f70174d9a7846d20be06b4017f48e3ccd03a68e645ec
Copying blob sha256:9936dfa5a746527cdf32366da42122ea688cfe68e94d75faaea2b255fcdf9c09
Copying blob sha256:c3790f36a22f558cc542740042bea4213e596bd683efcdd477864d5ffd82b69a
Copying blob sha256:1aa22d2b92134ec930e75c78feb042ba39f39fd5f679d552b2126b0335b77538
Copying blob sha256:46c2008ad6e0a3ef04ddfead1965802e541d717cb5a1a34666cecb9009d96b2b
Copying blob sha256:45db7dfbb822478575dacd41906a01c1dbdf66bb8cf4381d9c1d558cf4773753
Copying blob sha256:d04ffa064be4df90e6636f4b15912ba391548085971dec6654c94173fb5e8b39
Copying blob sha256:45d11897bc1f84e1614575c1cfd736fc495e6bdc81ebe963a90175feb1d5c5b9
Copying blob sha256:3e22484ea6e1678ddda5991a33203e35cb65a39b4ee3a804d1a31b422e62c7ae
Copying blob sha256:5ae7ac09b7d0c68fd2c07b376f1a008e9202524ee80303539763b7c4f4ab2a1b
Copying blob sha256:a56214ef0f81284ae540f67967486ab0bca6a13f30774569c3c530e60eaec7d4
Copying blob sha256:3474f9a80142f6724d29667df568fcfee235df17b098ab0b4410761e39637b79
Copying blob sha256:63b30112f6eec0618b034c2ad88516fe08f4c2e2113269a92316ae84f76bd825
Copying config sha256:fa790c6cad643be3c5c255a7a42845c1cefd69ec0487d0b7411b2816bbd283d2
Writing manifest to image destination
There were some comments on review, so I made some changes to a few scripts. These changes did not affect the docker image built. I see almost the same command as above being run - only the tag is different, but it fails
skopeo --insecure-policy copy nix:/nix/store/a4bqbj7krc6x40rfq45r59y79xyba09m-image-arbiter-core.json docker://registry/core:7ab74aab
Getting image source signatures
Copying blob sha256:639fd8a4a6db43c96e68915b59a9e07fd87c41b32bdd747ec16f901ab918f871
Copying blob sha256:bbd58c630c9658bfb87bca16cb9d1026eba45f9e394219573a1c7577751f7be4
Copying blob sha256:93a7bb3510ad4da878b5f7c7df1168a9a688821469c57a61318eab3d7353d5cb
Copying blob sha256:82a7668656be571e4946e03c7ce13e70c563534f99bfb7b11451d2015789494e
Copying blob sha256:df9b9388f04ad6279a7410b85cedfdcb2208c0a003da7ab5613af71079148139
Copying blob sha256:b5515e63b39777771c7e229485666ece0560afc5928f79f63d27a46fe8749b8c
Copying blob sha256:8afca76230176d09bc180c0133c247fe2af1cb1b8a49ea2084c76e4158af39fb
Copying blob sha256:c29256576a3908e48137040a1ba2be8baf05a78adddd74c142f305a9a71a39f3
Copying blob sha256:a38eb251c6c16e4d28cd6d4d4f50153fcaac03199a0e8fb749b4d0522b98d46a
Copying blob sha256:e24256f2d5fe9ad9f6f171ef9ad80bcb554cf397048e07f9bef144854f5df2f3
Copying blob sha256:981d26dcfe13049410ca38fe4975681043a43baf74d2abb1e2a83d557a42b540
Copying blob sha256:566827c8277b7d98785aecb5a42f580271176d9761f821c4635c86cd59754d26
Copying blob sha256:7f649fd2858dbfd739cb7c1ba5ff775c28d5481d2fbd4d6acd4df3b533f9215d
Copying blob sha256:813915ea84157954369af64380b8563611b88f84d4d5a2d38cc96df74602f53f
Copying blob sha256:3c5f6a41d8855658ceffbd80ccf8a50af8cb2180a875dc350c0ab8f4436a8b66
Copying blob sha256:56cb46dfe4bf3aaedf5f8a84167d892be45078b9702d547a9f75c0fa860d3cb2
Copying blob sha256:bcaf034240bb0b7c8b30d549ea1b4861bb25e448ca267a07a3eb98237067aeb7
Copying blob sha256:1c8426bea4c0e362ff2078f43a7178150a3456c8ea952a27a4809ab317107b05
Copying blob sha256:35656bd34ca46ffb905d34dcf748df53369c17bd6c42fd686349459d91fe1a78
Copying blob sha256:47a41c1b947f98aedf68d8826fcbab15dae72f9d6fe535d993d5e14ca9f879cc
Copying blob sha256:c9d39247cbd60213cabe901a704bf3b71ac7a1dadee755e6154dcdc91d7d2907
Copying blob sha256:08993adc665dd0553074c28faf096ae6254e989e9df473aa7d308aaf94573cf6
Copying blob sha256:bc4c7780a68911fe66713e7fb0f88546cf2e4a5448b73eea5142e8e743ebbdb2
Copying blob sha256:3da0aeff836abcf75c05ef33c094669c22527c0fa897b06d382678a467cb5f34
Copying blob sha256:e402beee672d473779f35d08cf55b5776cf00fb73406dd93c051606a58825a34
Copying blob sha256:65cc5570a241af8c2c5a13a6450540a85bcb01efe93b8910d863d1c2b1261461
Copying blob sha256:dedd3d6f86825067eaa1e506cfa771db092fb194a2663d9a12df82ffbdb58427
Copying blob sha256:219d2b10e1d12898905e4ecf39e47001f67bb79b89240bd33adcc700c7eb085d
Copying blob sha256:5852a018582729818ae4a61884ca5260ec67763eee86551ec816b93cd38ac52a
Copying blob sha256:a33c2f561dcc0931888056da8307d6fa61855ed68fbfbab5e6e82d4d292fe4e6
Copying blob sha256:67868eb5684da4c550ccb5d32d649b3ae8b41e2bf4adae8e872c3501e674806a
Copying blob sha256:1bee95ccc233abefa5ab6b69817d133d993754bac00c6a79c64ebdc3ba633c85
Copying blob sha256:fbf290c6f7a9db913151342d3ee094b4887dffdc6b5fa71327eb597a18f8a1d7
Copying blob sha256:28d61e4ede357b478abf1312b40f7814f4629fd5d35100704b90cefe7428821e
Copying blob sha256:040abbb15aee45cc7b903a083e310025ef05f42436292bf9895ab275a32b4796
Copying blob sha256:4267860e53e9c543b5b49f1fee0e1dba66f212e6b50e93269f2b19d6875a7fa3
Copying blob sha256:62b890afbd6afc4709db6c0b4c9289846b348f51b8589c8b8772fd6e8f209f04
Copying blob sha256:a6e22137551023518b5d9c76e5479bd1309fa235a0aab165d5578b28a8c72460
Copying blob sha256:3f7f997a22fb0af2569bb73fb927b25b98188db6467dab0db7b17d142ee279f7
Copying blob sha256:0ed217356b0362952ab0e4acde679ead84a4c1a848c177f3b8873418f59ed1e4
Copying blob sha256:50963d3c40e4e658a373e9557a7df250f440d56688dcb9aecf8c2a4c667956cb
Copying blob sha256:639934261bce11ca7649beb2802d86c91befd90a13f9362f948e7101353f864d
Copying blob sha256:f00e96af5b78d20de9e8ae19bca46d6027a866dc83f9c286230d98cd8026bca1
Copying blob sha256:a5890285d709f32d843449ed38e37fafdfd8eec2e059ced00f8ce18a34bbf83f
Copying blob sha256:495a599fbeb5390e0b0f234eaaab62a50c30512dd5c1cd6e6ec61b79ae55398f
Copying blob sha256:88303e747e48480922d2e5bdf0c738df960c463763f9e72f1a61fc4269934e3e
Copying blob sha256:30e76fb9fa8c2b3563826cd1721b86a6f82509fd72a8b7a00e0022d935a813b7
Copying blob sha256:08844a71d64e5b70fdd1d819167a598179f6b4ee17363ff4328fba211d258905
Copying blob sha256:d954ef953d842816165b69f417f08c0aec6dd02c3b3f3189c467aa6421b3e6ed
Copying blob sha256:c1ce536cdd3f25191c75ed07db475f40a209be6356da6931a0125d74583d8323
Copying blob sha256:1d2d0056b1f473565949f70174d9a7846d20be06b4017f48e3ccd03a68e645ec
Copying blob sha256:9936dfa5a746527cdf32366da42122ea688cfe68e94d75faaea2b255fcdf9c09
Copying blob sha256:c3790f36a22f558cc542740042bea4213e596bd683efcdd477864d5ffd82b69a
Copying blob sha256:1aa22d2b92134ec930e75c78feb042ba39f39fd5f679d552b2126b0335b77538
Copying blob sha256:46c2008ad6e0a3ef04ddfead1965802e541d717cb5a1a34666cecb9009d96b2b
Copying blob sha256:45db7dfbb822478575dacd41906a01c1dbdf66bb8cf4381d9c1d558cf4773753
Copying blob sha256:d04ffa064be4df90e6636f4b15912ba391548085971dec6654c94173fb5e8b39
Copying blob sha256:45d11897bc1f84e1614575c1cfd736fc495e6bdc81ebe963a90175feb1d5c5b9
Copying blob sha256:3e22484ea6e1678ddda5991a33203e35cb65a39b4ee3a804d1a31b422e62c7ae
Copying blob sha256:5ae7ac09b7d0c68fd2c07b376f1a008e9202524ee80303539763b7c4f4ab2a1b
Copying blob sha256:a56214ef0f81284ae540f67967486ab0bca6a13f30774569c3c530e60eaec7d4
Copying blob sha256:3474f9a80142f6724d29667df568fcfee235df17b098ab0b4410761e39637b79
Copying blob sha256:63b30112f6eec0618b034c2ad88516fe08f4c2e2113269a92316ae84f76bd825
time="2023-08-31T17:24:06Z" level=fatal msg="writing blob: Patch \"https://registry.gitlab.com/v2/welllabs/health-engine/well-he-arbiter/arbiter-core/blobs/uploads/6187de27-6cdf-418f-b6c7-26424a788137?_state=DM4x_noAIl8kbwDW3pv3cQ90cUKs3eP_NPS0Deg5XpF7Ik5hbWUiOiJ3ZWxsbGFicy9oZWFsdGgtZW5naW5lL3dlbGwtaGUtYXJiaXRlci9hcmJpdGVyLWNvcmUiLCJVVUlEIjoiNjE4N2RlMjctNmNkZi00MThmLWI2YzctMjY0MjRhNzg4MTM3IiwiT2Zmc2V0IjowLCJTdGFydGVkQXQiOiIyMDIzLTA4LTMxVDE3OjI0OjA2LjAyNDg2MTkyOVoifQ%3D%3D\": happened during read: Digest did not match, expected sha256:a56214ef0f81284ae540f67967486ab0bca6a13f30774569c3c530e60eaec7d4, got sha256:6bada2e7ab242d3d2904c08ef0f245a0c46281fbdf33dea7b34a8e885d44f42e"
Comparing the digests of the blobs that are being copied, they are the exact same between the two runs, as you would expect, just in different orders.
To try and figure out what was going on, I tried adding reproducible = false; on my layers, as you suggested. When I tried that, it was able to push to layers successfully. I then tried again, this time without the reproducible attribute, and it worked.
Any suggestions on what to try next?
from nix2container.
Related Issues (20)
- Skopeo fails to patch on nixos-unstable with skopeo 1.14.0 HOT 1
- make it a little more error prone
- How to run image i build? HOT 1
- `pullImageFromManifest` does not work without token URL HOT 1
- clean up old mess HOT 3
- Could `foldImageLayers` be added as lib function? HOT 2
- feat: oci image linking to store host nix/store path HOT 4
- pip networking error HOT 1
- Request: easy way to get resulting image name HOT 2
- devenv: no image using skopeo copy from Nix source to docker-daemon target HOT 4
- External hinting system for automatic layering HOT 1
- Assertion `info.references.size() == 0' failure pulling layers containing store paths
- Image Manifest Metadata Lost HOT 2
- idea: Group image actions under `do` HOT 4
- idea: Flake Module HOT 2
- Fails to evaluate on macOS
- skopeo copy always copies a layer, even if the hash is the same HOT 6
- How to create a docker image with nix2container that can be used to build nix2container images?
- Build within nix2container image: "Digest did not match" from Skopeo HOT 12
- Rootfs Issue with image deployed to AWS Fargate HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nix2container.