Bugzilla – Bug 154762
http install can't find CD[2-5] if missing trailing / in specified path
Last modified: 2006-03-20 13:51:57 UTC
Doing an http install, the installer can't find CD 2,3,4,5 if the path is missing the trailing slash. I will attach logs when I get home from work. :) I set up a SUSE Linux 10.0 Installation server and used the YaST module to create an http install source for SUSE Linux 10.1 beta6. Then, from the CD boot menu, I choose an HTTP installation. I specify the IP address of the install server, and a path such as "/install/b6" or "install/b6". It works for the first CD, but for each subsequent CD, it cannot find it. If I go to the details and add a trailing slash (ie, from "http://10.0.0.1/install/b6" to "http://10.0.0.1/install/b6/"), it is able to find the next CD and continue until it is ready for the next CD, where it has the same problem.
BTW, I'm not using smaster.novell.com - Bugzilla must have resolved that internally. I really put in http_://_10.1.1._1/install/b6 (remove the underscores).
This happens with FTP as well. I know this behavior did not occur in past versions.
Can you provide the YaST logs from your installation, please? Please provide all y2log* files from /var/log/YaST2 -- see http://en.opensuse.org/Bug_Reporting_FAQ#YaST
Created attachment 71166 [details] bz2 archive of YaST Log files
That's interesting - would you be able to find and post a small portion of the httpd logs - the httpd should log the access to the (non-existant) resource. I'm wondering if this is related to bug 152068.
It is not a problem of a "/" or missed "/" at the end of the Url, but results from Url rewriting that is done in the MediaSet class. It assumes, that each CD is in a .../CD1, .../CD2, ... subdirectories and modifies the last path-part in the Url. In the scenario used here, all CDs are "merged" (copied over each other) into one directory, so it is not needed to rewrite the Url at all. Perhaps we can just replace the verifier in the access handler of CD1, to the one checking for CD2 to see if the Url / access handler of CD1 also provides CD2, before any rewrite of the Url. From y2log-2: 2006-03-01 18:09:41 <0> linux(4136) [source] MediaSet.cc(rewriteUrl):113 Rewriting url http://172.26.10.152/install/b6 2006-03-01 18:09:41 <0> linux(4136) [source] MediaSet.cc(rewriteUrl):125 Url rewrite result: http://172.26.10.152/install/b2 2006-03-01 18:09:41 <1> linux(4136) [media] MediaAccess.cc(open):96 Trying scheme 'http' 2006-03-01 18:09:41 <1> linux(4136) [media] MediaCurl.cc(MediaCurl):78 MediaCurl::MediaCurl(http://172.26.10.152/install/b2, )
*** Bug 154110 has been marked as a duplicate of this bug. ***
Jiri, MediaSet should not try to rewrite non-CD/DVD URLs.
It has to, because of the scenario for having CDs sepratelly (each in its directory). The only thing that can be done to prevent this problem is to extend the regular expression...
Created attachment 71495 [details] archive of /var/log/apache2 I don't remember if I've used the web server for installing each beta. Some I did, some I used NFS, some I used CDs. My naming convention is /srv/www/htdocs/install/[a,b][0-9], ie b4 for beta4, a2 for alpha2, etc. But I think I delete the old install sources when I create an updated source.
I fixed the regular expression in SVN, so that it rewrites the URL only if there is CDx or DVDx at the end (case insensitive). It shuold solve the prohblem.
(In reply to comment #9) > It has to, because of the scenario for having CDs sepratelly (each in its > directory). The only thing that can be done to prevent this problem is to > extend the regular expression... Yes, the Url needs a rewrite, except the media id Url of CD1 providers also the CD2. This seems to be the case if the http installation server is prepared by some yast2 module (Bug #154110#c3 contains a directory listing). Perhaps we can add a check for this condition and reuse the access id and replace the verifier only? See my mail with attached diff, that should show if the condition is true.
*** Bug 141181 has been marked as a duplicate of this bug. ***
*** Bug 157470 has been marked as a duplicate of this bug. ***
*** Bug 153476 has been marked as a duplicate of this bug. ***
*** Bug 157928 has been marked as a duplicate of this bug. ***
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ACCEPTED |CLOSED Impact|------ |Installability ------- Additional Comments From shenlinf@cn.ibm.com 2006-03-19 22:07 EDT ------- This bug doesn\'t occure on beta8. Closing this defect. Thanks all for you help.