| systemdlete | so... should I be telling my sources.list files to use http: instead? Sorry, not too familiar with the guts of this. | 00:14 |
|---|---|---|
| systemdlete | I switched back to http: and did the apt update again. Now I am seeing errors with a variety of different repo servers. | 00:17 |
| systemdlete | on second thought, no. | 00:17 |
| systemdlete | all the errors are to 147.78.194.22 | 00:18 |
| systemdlete | (the addresses flash by so fast, I thought I was seeing different addresses. But scrolling back, I see they were all hitting one.) | 00:18 |
| systemdlete | I just checked the current ntp time here and it matches time.gov (off by .031 sec) | 00:20 |
| systemdlete | oddly, it starts out and seems to succeed on the first 5 or so "Gets" | 00:20 |
| systemdlete | then it is a stream of Ign's | 00:20 |
| systemdlete | rrq, are you able to "apt update" without a problem there? | 00:21 |
| systemdlete | very odd. Worked fine just now. | 00:23 |
| systemdlete | ??? | 00:23 |
| systemdlete | now, on one daedalus system, it is now running fine (it wasn't earlier). | 00:30 |
| systemdlete | but on another daedalus and a chimaera, it is failing. | 00:31 |
| systemdlete | and there is no cacher in the way now | 00:31 |
| onefang | 147.78.194.22 is mirror.ungleich.ch, and they have an odd CNAME thing going on with their DNS. All three apt-panopticons are not having any trouble with it. Sounds like the problem might be closer to your end. | 00:42 |
| systemdlete | like what? I can update cleanly from certain systems and not from others. | 00:43 |
| onefang | So the problem sounds like it's with those others. | 00:43 |
| golinux | Please see: https://www.devuan.org/os/packages | 00:44 |
| systemdlete | well, I was having a problem with a daedalus a while ago, but not anymore. It just magically started working again without problems | 00:44 |
| golinux | "Devuan has a network of package repository mirrors in place. The recommended default mirror is deb.devuan.org, via http not https. Or, a specific mirror from the list can be accessed using the corresponding BaseURL. Country Codes can also be used e.g." | 00:44 |
| golinux | It has always been thus in Devuan. | 00:44 |
| systemdlete | Yes, that's how they are configured currently. | 00:44 |
| systemdlete | all http: now. | 00:44 |
| systemdlete | and no cacher to muddy the waters. | 00:45 |
| systemdlete | I have an MX system here, and it did not seem to have any issues throughout this. Of course, it uses the debian repos and its own, so that's a variable. | 00:46 |
| onefang | Think I need to add more history to apt-panopticon, to catch these "it's working fine now, but not an hour ago when I was asleep and couldn't look". | 00:46 |
| systemdlete | But I'll keep an eye on that system to see if problems erupt there in the future. | 00:46 |
| onefang | But I'm still in weekend mode today, no more poking at mirrors for me today unless it's urgent, back to the music making. | 00:48 |
| onefang | Though this weekend the music making resulted in a programming rabbit hole I'm almost done with. lol | 00:49 |
| rrq | systemdlete: on Sunday/Monday there is the major weekly repository update which always causes a bit of turmoil in the mirroring system. All mirrors engage in largish updates and each have a period of inconcistency with respect to each others if not within themselves. | 01:04 |
| rrq | eg. you might get a Packages file from an updated server and then try to donwload the package from another, not yet updated server | 01:05 |
| rrq | thus, a good ruel of thumb is to don't update on Sunday/Monday | 01:05 |
| systemdlete | yeah, that's the sort of thing I was wondering about... batch sort of updates. When I worked in I.T., it was common that late weekend nights (or early morning like 3am) were times when batch and other CPU hogs would be run. | 01:06 |
| systemdlete | it's just rather odd that one system here is performing ok (now, that is) and others are all coughing up phlem | 01:07 |
| systemdlete | I'm looking at debug options to try to trace through all of this. | 01:07 |
| systemdlete | one thing I am noticing is that on the systems that fail, they seem to be failing to download the InRelease file. (why don't all clients have this problem?) I can consistently continue to run apt update on the systems where it works and consistently see it fail on the ones where it doesnt | 03:30 |
| systemdlete | A little more inspection reveals that apt update is getting a timeout. I confirmed this by running wget on the same url. | 03:30 |
| systemdlete | (I mean the same url as one which failed...) | 03:31 |
| systemdlete | I even went so far as to compare the /etc/apt/* areas on each system; they are now identical (except for 20listchanges and 90rkhunter) | 03:32 |
| * onefang adds a TODO item for apt-panopticon - check the source code of the various apt implementations, see if they all have the same timeout, switch my timeout tests to using that. There's already a TODO to actually track weekly timeout stats. | 04:03 | |
| systemdlete | bbl | 04:55 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!