Bug 469420 - loader displays a modified URL string when trying to locate a network installation source
loader displays a modified URL string when trying to locate a network install...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-31 14:55 EDT by James Laska
Modified: 2013-09-02 02:29 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-28 17:02:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot (94.42 KB, image/jpeg)
2008-10-31 14:55 EDT, James Laska
no flags Details

  None (edit)
Description James Laska 2008-10-31 14:55:31 EDT
Created attachment 322118 [details]
Screenshot

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):
anaconda 11.4.1.53

How reproducible:
100%

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:guest@download.fedora.redhat.com/pub/fedora/linux/development/i386/oss  (NOTICE THE TYPO)
  
Actual results:

Anaconda *correctly* fails to find that URL, but then returns the user to a screen showing a modified version of the URL.  

For example:

ftp://anonymous:%67%75%65%73%74@download.fedora.redhat.com/pub/fedora/linux/development/i386/oss/images/install.img

Expected results:

It should return me to a screen that shows the same URL entered previously.

Additional info:

 * See screenshot attached
Comment 1 David Cantrell 2008-10-31 23:03:13 EDT
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?
Comment 2 Chris Lumens 2008-11-04 11:22:13 EST
Two things:

(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.
Comment 3 David Cantrell 2008-11-04 15:12:47 EST
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.
Comment 4 James Laska 2008-11-04 15:48:29 EST
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?
Comment 5 Bug Zapper 2008-11-25 23:34:43 EST
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.