Problems updating kernel-lts repo

I think your reply crossed my edit. I got my Tor browser to access the site, so that’s not the problem. I can also access the repo link from lynx, so at least I know the connection is good.

Tor Browser uses a different network and isolated set of libraries and configuration - it’s still possible the rest of the system’s SSL/TLS certificates etc. are broken.

OK, this means the server is fine, and it’s something on your local system that is broken.

If pacman isn’t working then it’s not browser-related. I’d be tempted to reinstall all pacman dependencies to make sure they are present and the files not corrupted. If that gets pacman working then we can move on to the rest of the system:

pacman -Syu $(pactree -l pacman | sort -u)
1 Like

Done, rebooted - same problems. For now, I’ve disabled the repo and removed all of its files. I’m not experienced enough on this so I can’t even begin to guess what happened. If there’s a way to completely remove SSL certs, then maybe that’s something to try.

I’d still really like to know what happens in a no-changes live environment.

If something on the server isn’t working I’d kind of like to know about it, but given Lynx works your IP address isn’t being blocked so it’s “something else”.

I just tried my Arch KDE VM and it’s experiencing the exact same issue. This just keeps getting weirder…

Not really, same host network connection.

Can you curl -v [repo server file], which will use openssl for https connections, and may give more verbose error messages.

1 Like

Is it possible to have something to do with the Chaotic repo? I just added that a couple of days ago.

Yes, and one easy way to check would be to boot a live installer environment.

Its like the https connection request is going through a proxy that is forcing http, or using an incorrect tls version (tls 1.2 vs tls 1.3), causing the handshake to fail.

If the live environment fails it is a broader network issue, if it succeeds it is a local system issue caused by the update.

2 Likes

Well…the live environment failed the exact same way.

1 Like

Can you do

and

uname -a

from within the live environment?

curl -v https://repo.m2x.dev/current/kernel-lts/x86_64/kernel-lts.db
*   Trying 2001:41d0:a:14ce::1:443...
* Connected to repo.m2x.dev (2001:41d0:a:14ce::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=repo.m2x.dev
*  start date: Dec  3 09:42:03 2021 GMT
*  expire date: Mar  3 09:42:02 2022 GMT
*  subjectAltName: host "repo.m2x.dev" matched cert's "repo.m2x.dev"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET /current/kernel-lts/x86_64/kernel-lts.db HTTP/1.1
> Host: repo.m2x.dev
> User-Agent: curl/7.78.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.14.2
< Date: Sat, 29 Jan 2022 02:31:43 GMT
< Content-Type: application/octet-stream
< Content-Length: 34555
< Last-Modified: Thu, 27 Jan 2022 14:57:28 GMT
< Connection: keep-alive
< ETag: "61f2b2d8-86fb"
< Accept-Ranges: bytes
< 
Warning: Binary output can mess up your terminal. Use "--output -" to tell 
Warning: curl to output it to your terminal anyway, or consider "--output 
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
$ uname -a
Linux EndeavourOS 5.13.12-arch1-1 #1 SMP PREEMPT Wed, 18 Aug 2021 20:49:03 +0000 x86_64 GNU/Linux

I didn’t get this far before, so I’m hopeful. In between tests in the live environment, I rebooted my router.

If you’re connecting using IPv6 then I won’t see an IPv4 address in the server log… :sweat_smile:

I’ve fiddled around with crowdsec a little (updated, upgraded some collections, …) so it will be worth trying again.

If it’s still not working and you’re still connecting using IPv6 then DM me that address instead.

This could be a thing too.

OK, we’re back to normal! When I first tried after rebooting the router (on my system, not the live environment), it was throwing the same errors. Now, after the good (live) test and reboot #50, it’s working again.

Can’t thank you enough, @jonathon - this is why I love this distro!

3 Likes

Sorry to reopen this can of worms, but it’s happening again. I can manually download the files using lynx, but not with curl or yay.

can you try to use your mobile phone’s mobile data connection (via tethering or WiFi hotspot) and check if it works that way?

Had some wierd connection issues in the past that were related to my wired ISP’s server side config. DNS resolution worked but still could not connect to some services (my works email server and the firewall in front of it didn’t even see that i want to connect to it), on mobile internet it worked. Had to change the Port to get it working again.

Using my phone via USB tethering works; not sure why my system worked for a little while after rebooting the router, though. At this point I don’t even know where to start troubleshooting my LAN connection; the Cox techs will be clueless. The router is already set at factory defaults; except for the WiFi passwords, I haven’t changed anything.

TOR is a separate network, no issues, smartphone tethering through a separate network, no issues.

ISP connection looks like it is the issue.

This error message indicates …

Which is usually caused by …

It looks like your network requests are being ISP proxied, or possibly cached over time.

Rebooting the router gave you a clean ISP connection and maybe different WAN IP address, possibly masking the real issue.

I can’t see how router config would cause this for a single server, but I’m no networking expert.

VPN exit node usage should help with this sort of issue, but apparently they didn’t.

This is definitely a weird issue.

The WAN IP stayed the same; agree that this is a really weird issue. Unfortunately, I have to disable the repo temporarily until I can either figure this out, or the problem goes away on its own. I really don’t want to have to build the 5.10 LTS from source every time it changes, but at least that works for me.

I can’t see either of your IP addresses in logs more recently than 29/Jan/2022:05:19:53 +0000 . Neither exists in any firewall rule (e.g. from crowdsec community blocklist rules).

Searching for the error on the Web all threads point to a misconfigured proxy, but given the issue only happens for my server it’s unlikely to be that, unless your connection is being transparently proxied by your ISP who is blocking connections to OVH servers, or your connection is actively triggering their DDoS protections.