GPG error: https://packages.sury.org/php bullseye InRelease: Splitting up /var/lib/apt/lists/packages.sury.org_php_dists_bullseye_InRelease into data and signature failed #2046
Comments
|
I think it might make sense for you to do a local mirror of the packages. There's rsync available at rsync.sury.org |
|
None of this is local, it's all on various CI environments like GitHub Actions etc. |
|
I should note that people all over the world can hit this when using DDEV, which may add a build step including I have a PR going trying to gather more information, ddev/ddev#5473 But can this be something about DNS or b-cdn.net? Is there possibly one bad IP address returned for |
|
I saw this error today. In this case, apt was running inside of GitHub actions. I agree it's intermittent, as other jobs passed as did a rebuild. |
|
I was able to fix this in one particular situation after an extended bit of trouble by changing wireless networks (to phone hotspot). I wish I knew what the error message actually meant. |
|
I had this problem consistently today on a coffee-shop wifi. I looked at DNS server settings, and I was using 1.1.1.1 (Cloudflare). I changed to use the coffee-shop's default DNS and it worked fine. |
Hmm, but you haven't recorded the DNS responses by any chance? |
|
Sorry, that would have been a good test. I switched back to 1.1.1.1 and now I don't seem to be able to recreate the problem. The response below is working. |
|
I'm seeing this error today consistenly. In this case, apt is running inside of GitHub actions. |
|
@penyaskito on GitHub hosted runners, our self hosted ones at Linode, or both? |
|
This issue is about the "Splitting up" message. It's not related to the cert expiration message that @penyaskito was getting due to actually having an expired key. That problem is covered in The answer for @penyaskito was to update DDEV to v1.22.7. There is also a workaround in the issue for DDEV v1.22.6. |
|
I'm having this error right now, happening on both amd64 and arm64, on two networks:
On another internet-based system where All I can figure here is that my ISP is spoofing 1.1.1.1 and 8.8.8.8 If I add a line to /etc/hosts with everything works fine. |
|
I switched to hotspot, completely different network, and I still get the same failure, different IP address |
|
But maybe it's bunnydns? It either isn't serving, or isn't willing to talk to me: |
|
I guess maybe this is something about BunnyCDN caching @oerdnj ? On the affected systems I'm seeing a 304 "no need to re-transmit" with a curl: On unaffected systems I see a 200: |
|
As I think we'd expect here, on a working system we get this from a curl, fully PGP-signed: curl -s https://packages.sury.org/php/dists/bookworm/InReleaseOn a broken system as expected, because of the 304, we get absolutely nothing back: |
|
I’ll open a ticket with BunnyCDN. |
|
Hello, I have the exact same problem today after upgrading from Debian buster to bullseye. Also returning HTTP 304 and nothing for the Any advice ? |
|
Seems to be working again. Strange :/ |
|
It has appeared again in a GitHub Actions build :( Did BunnyCDN ever answer the ticket? |
I am using ddev and am also getting this on two different systems. The system where ddev is working outputs where the one that doesn't work returns nothing. Working system:```curl -s https://packages.sury.org/php/dists/bookworm/InRelease ✔ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512Origin: deb.sury.org iQGzBAEBCgAdFiEEFQWFAKAjXZf10QBjsYjitpW9R0MFAmciup8ACgkQsYjitpW9 and non working system outputs nothing. This has been happening on the non-working system for the last 45 minutes at least and as I was writing this post it has now resolved itself. The non-working system is now outputting:```curl -s https://packages.sury.org/php/dists/bookworm/InRelease ✔ 36s -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512Origin: deb.sury.org iQGzBAEBCgAdFiEEFQWFAKAjXZf10QBjsYjitpW9R0MFAmciup8ACgkQsYjitpW9 |
|
If this is the same as last time I studied it, it's the CDN returning empty from |
|
Is there an alternate mirror we could use, at least for testing? If not, could we or someone create a mirror just for testing? If we keep it to ddev it would presumably have much less traffic. |
Can you get the HTTP headers from the broken connection? |
|
We did in #2046 (comment) I imagine it's the same. (304 "no need to re-transmit") I'll consider adding a |
Unfortunately things started to work while I was writing out the post so I'm not able to get that information now. If it comes up again I will try to get that information as well. |
Frequently asked questions
Describe the bug
I know you've probably heard this too much, but in DDEV's automated tests I often see this, but it's quite intermittent. There can be 6 tests running in parallel on github workflows and two of them might hit it. I've seen it locally as well, and done things like changing networks to try to get around it.
To Reproduce
I do not know how to reproduce it, as it's very intermittent, but it does happen every day.
Your understanding of what is happening
I suspect there must be one cache or one CDN that is invalid somehow.
I would love to know what "Splitting up /var/lib/apt/lists/packages.sury.org_php_dists_bullseye_InRelease into data and signature failed" means.
What steps did you take to resolve issue yourself before reporting it here
I have already done PRs that I hoped would resolve this in DDEV, using less things from deb.sury.org, etc. But since this happens on
apt update, my hoped solutions were a failure.Expected behavior
apt updateshould always work, and not fail to "split"Distribution (please complete the following information):
Package(s) (please complete the following information):
The package is not relevant, as the problem happens on
apt updateAdditional context
deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ bullseye mainThe text was updated successfully, but these errors were encountered: