Red Hat Bugzilla – Bug 469420
loader displays a modified URL string when trying to locate a network installation source
Last modified: 2013-09-02 02:29:05 EDT
Created attachment 322118 [details]
Description of problem:
When supplying an invalid URL to anaconda loader, it re-prompts for a valid URL, but munges the given URL in the response </poor_english>.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot installer
2. select lang=en, keymap=us, ksdevice=link, ip=dhcp
3. Select install method: URL
4. Type ftp://anonymous:firstname.lastname@example.org/pub/fedora/linux/development/i386/oss (NOTICE THE TYPO)
Anaconda *correctly* fails to find that URL, but then returns the user to a screen showing a modified version of the URL.
It should return me to a screen that shows the same URL entered previously.
* See screenshot attached
I'm not sure this is a bug. The install URL is the path to the install.img file. As a convenience, you can just enter the path to the tree and loader will tack on "/images/install.img" and try that. So if there's a typo in what you provide, throwing you back at the entry screen should show you the path it's actually trying.
Chris, what do you think?
(1) Encoding the password in the string you get back is pretty bad. We should either remove it entirely or print what we were given.
(2) Toss up. I can see this going either way. On the one hand, the user is probably going to be surprised by getting back a different string. On the other hand, it's what we actually went looking for.
I guess if we're going to fix (1), we should make (2) display what we were given as well. That shouldn't be hard, but loader has a way of making things tough.
My vote is to leave it the way it is for several reasons:
(1) What Chris said about complicating up loader. The less string manipulation we do in loader, the better. If there's no real need for it, I say leave it out.
(2) Loader tacking on /images/install.img is a convenience thing right now and we should be throwing that back at users if we can't find it because it shows the more correct URL they should be entering. install.img could be anywhere too, not just /images/install.img.
(3) Leaving it the way it is reminds people that loader is not looking for an install tree, just the install image. It doesn't care where packages and repodata are.
Howabout the munging of the supplied password (as noted in comment#0) ... should that be addressed?
(In reply to comment #3)
> (2) Loader tacking on /images/install.img is a convenience thing right now and
> we should be throwing that back at users if we can't find it because it shows
> the more correct URL they should be entering. install.img could be anywhere
> too, not just /images/install.img.
As a user not knowing the underlying mechanisms, this is somewhat confusing to me. The URL I entered has been changed with no indication why. Was my original URL wrong because I didn't append the images/install.img? Was something else wrong (network timeout, bad hostname, etc...).
If images/install.img is what we are looking for, should we change the documentation to request it?
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here: