I’ve been trying to dup to snapshot 20260805, but every time zypper gets to kernel-default the download speed slows to a crawl and after a while exits with a 404 error.
Specifically this happens:
Preloading: kernel-default-7.1.6-1.1.x86_64.rpm [Error: "end of response with 195559189 bytes missing", trying next mirror.]
Preloading: kernel-default-7.1.6-1.1.x86_64.rpm [Error: "The requested URL returned error: 404", trying next mirror.]
Preloading: kernel-default-7.1.6-1.1.x86_64.rpm [Error: "The requested URL returned error: 404", trying next mirror.]
Preloading: kernel-default-7.1.6-1.1.x86_64.rpm [Error: "The requested URL returned error: 404", trying next mirror.]
Preloading: kernel-default-7.1.6-1.1.x86_64.rpm [The requested URL returned error: 404]
Preload finished. [files missing (188.1 KiB/s) ] ............................................................................................................................[done]
Installation has completed with error.
I guess I’m just earlier than I usually am. I was hoping this update would fix NoMachine before I head out of the country, but I’ll just have to try in the morning before I head out.
Yea, and this issue is world-wide, to include the dedicated (i.e., hosted by) openSUSE website servers!
And sorry, my comment is about wanting to download the latest Leap 16.1 (Alpha), but the same issue. The download feedback is, “download will finish in 424 days” (yes, over a year)
Status shown at openSUSE Download site:
Mirrors
List of best mirrors for
IP address xxxxxxx, located at xxxx,xxxx in (US)
Mirrors which handle this country: 0
* None
Mirrors in other countries, but same continent: 0
* None
Mirrors in other parts of the world: 0
* None
I suspect the load on download.o.o with everyone hitting it and trying to sync out to mirrors is the issue. I’ve asked about it on the Factory matrix channel, lets see if they have an idea…
Seems like must be something malconfigured or broken for syncing mirrors with new kernels, or even generally. About 19 hours ago, roughly 5 hours before dimstar’s factory list announcement of 20260805, I was doing a dup expecting to acquire 20260804, but got 20260805. Upon that discovery I fetched 7.1.6 64 & 32 plus LT 6.18.42 with wget from d.o.o, meaning unknown actual mirror. They were very slow coming in, but I got them long before bedtime.
Sometime in recent days I noticed more significant than usual slowness getting KDE3 updated from its limited availability optional repositories. I managed to notice, and don’t remember what I did to do so, that those rpms were actually coming from gwdg in Europe, even though I’m in Florida, where default repos’ packages are typically provided by leaseweb in Miami, which does not mirror “repositories”. This (unrelated?) slowness seems to smell like the whole mirroring management process has a problem in need of fixing.
Last time this happened the snapshot was a full rebuild due to GCC16, so the mirrors had a very large chunk to swallow. My understanding is that if you are really an early bird, download.o.o has the new files, no mirror is syncing yet and you get through.
Then there is a time window when most mirrors are syncing, no one has some new files yet, so you are directed to download.o.o but that master server is busy serving the mirrors, which might have higher priority, and you are left with a residual bandwidth of some 100 bit/s and “download will finish in 424 days”.
[disclaimer] I have no insider info about that, so I might be off mark by a yard or two
I hit this “slow” download on the kernel yesterday in my Leap 16 install . . . it wasn’t too many packages in the “up” but it seemed to hang on “the kernel” and speeds dropped into the kb’s . . . . As it was more or less the last package to be retrieved I didn’t abort, but walked away from the machine and awhile later came back and the packages had been installed . . . . So that appears to be days later than when the OP posted this problem . . . .
