Bug 469420
| Summary: | loader displays a modified URL string when trying to locate a network installation source | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James Laska <jlaska> | ||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 10 | CC: | anaconda-maint-list, dcantrell, jturner | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-07-28 21:02:09 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
James Laska
2008-10-31 18:55:31 UTC
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? 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. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |