User supplied mirror server not verified, no errors reported
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| subiquity |
New
|
Undecided
|
Unassigned | ||
Bug Description
I did a test install using
$ sha256sum focal-live-
28c4e38588dd3ec
(which was published at http://
and edited the mirror server the installer suggested from
http://
to
https:/
$ host de.archive.
de.archive.
ubuntu.
ubuntu.
ubuntu.
ubuntu.
Every one of these servers refuses TCP connections to port 443.
The installation succeeded, no warning or error was displayed during installation. But the system failed to boot. I am yet unsure whether the reason the system failed to boot is due to the installer not having access to a working mirror server.
I think, however, that the server installer should test basic functionality of a user provided archive mirror server (or whichever archive mirror it ended up using?), and at least warn about it being unusable. A user who provides an archive mirror URL certainly has the expectation that this will be used, and failure to do so will be communicated in more than just the log file.
Ideally, a basic early test will be carried out by the time the user provides the archive mirror location and, should it fail, the user should be informed and asked to instead provide a different archive mirror location or select to carry out an offline installation (if such is (not just technically possible but actually) supported by Subiquity).
I'm not providing log files at this time since this should be fully reproducible.
| tags: | added: focal |
| Michael Hudson-Doyle (mwhudson) wrote | #1 |
| affects: | subiquity (Ubuntu) → subiquity |
| Michael Hudson-Doyle (mwhudson) wrote | #2 |
I'm surprised the install doesn't fail in this situation :(
I'm a bit leery of doing too much ahead of time validation of the mirror but I guess we could at least do a HEAD request for the Release file or something, would weed out most typos and silly mistakes.