Download raw body.
sysupgrade/ftp: use a 'needle' to poke through caching layers
sysupgrade/ftp: use a 'needle' to poke through caching layers
Stuart Henderson <stu@spacehopper.org> wrote: > SHA256.sig on the origin cannot be relied upon to be in sync with the > tgz files. Part of this was due to non-atomic syncs which AIUI have > now been improved, but another part AFAIK is an artefact of the way in > which builds are done and that's harder to change. Nope. The first few steps of pushing build pieces has always been correct. I only push directories that are complete and correct. The only weird thing is that base and x components are handled a bit seperately (so you can get older X, with newer base, for a small window of time until the new X build completes). architectures with install*.* files that is solved, because the signing specifically waits for those files, and then of course they are also correct in the hash. > I fetch base snaps and run signify to check the hashes. Despite only > fetching them once a day (so I guess the chances of running into > any individual breakage are probably fairly low) I've had 2 failures > in the last month. (See examples below). I don't know where you fetched from. Even if you fetched from ftp.openbsd.org, it could get de-sync'd, until about 18 hours ago. From cdn.openbsd.org it could get VERY desync'd. From 2nd and 3rd tier mirrors it is probably even worse. I think we have fixed very well on ftp.openbsd.org, and on cdn.openbsd.org to the degree that job describes. Other mirrors can get get fixed incrementally following this. So please check again. Regardless you can *still lose*, unless we put all of OpenBSD into 1 file.
sysupgrade/ftp: use a 'needle' to poke through caching layers
sysupgrade/ftp: use a 'needle' to poke through caching layers