Updated automirror for urllib.request
- rCALASETTINGS4bf7f727865c: Updated automirror for urllib.request
Verify basic function in US, but then also have non-US users test for functionality, especially paying attention to time.
More specifically, this patch should be able to be applied directly to /usr/lib/(i138-linux-gnu|x86_64-linux-gnu)/calamares/modules/automirror/main.py in a live system, then run the installer and see what happens.
I'm not sure this is sufficient to fix the problem, but some testing will help shed some light on it. Since it sounds like this is a common gotcha with urllib, this may very well be the issue.
My gut tells me timeouts, though, given the fact that it works sometimes and not others. So I encourage you in a further commit to add an arbitrary timeout and a simple enough error handling to perhaps eschew the need for a particular mirror and instead use some default. @tsimonq2 what would be a good default?
Then as bonus points, add error handling to handle other errors.
Good work and congrats on your first commit! 🌟
The problem here isn't that the urllib call is wrong (although that could certainly be possible) but the problem is that there's a race condition that needs to be solved.
if libcalamares.globalstorage.value("hasInternet"): country = getcountry() prefix = getmirror(country) else: prefix = ""
This function is only called if Calamares thinks there's internet. That works in most cases, but not when the internet is disconnected in between Calamares starting and getting to automirror.
You need to catch the urllib exception, and default to setting prefix to an empty string if there are problems. This DTRT everywhere, and isn't much of a hack.
@tsimonq2 the folks in #python made this suggestion as one of the possible issues.
On the other hand, perhaps you are right as the crash ends with a URLError:
File "/usr/lib/python3.6/urllib/request.py", line 1320, in do_open raise URLError(err)
This is distinct from HTTPErrors and is a subclass of OSError so I would take it to mean a protocol issue of some kind, of which lack of networking certainly could be.
On the other hand, I just ran it in a VM with no networking— even after selecting an overseas location in hopes it would trigger some weird behavior from the mirror— and everything worked fine.
Thus, I don't think it's a no-networking issue anymore than I think it's a timeout issue.
Still, we could use some additional error handling to remove doubts.