Bug 152378 - HTTP and FTP URLs are not flexible for netinstall
Summary: HTTP and FTP URLs are not flexible for netinstall
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Joel Andres Granados
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-29 00:54 UTC by Eric Greveson
Modified: 2008-04-18 11:33 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-18 11:33:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screenshot of vmware session during install (17.25 KB, image/png)
2008-02-12 12:56 UTC, David Timms
no flags Details
wireshark-follow tcp stream for ftp control connection. (1.22 KB, text/plain)
2008-02-12 13:20 UTC, David Timms
no flags Details

Description Eric Greveson 2005-03-29 00:54:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.6) Gecko/20050321 Firefox/1.0.2

Description of problem:
When attempting netinstall with FC3 install cd, the installer is not at all helpful about mirror sites. If certain leading/trailing slashes are omitted or included, the installer will not find the mirror and report an error. There is no guidance on the correct format of a URL. The HTTP install has a bug that has been reported (#101265) which adds a leading /, making netinstall very difficult from HTTP mirrors. The FTP install seems to expect a leading / and no trailing / in the directory name. A good resolution to this would be to have a "URL" box rather than two "hostname" / "directory" boxes, and ideally not split up netinstall into FTP and HTTP. For example:
Have Netinstall as install option.
This option sets up your network as before then brings up a "Enter mirror URL" box with an example underneath (the standard fedora.redhat.com HTTP site for example)
Ideally, a list of mirrors obtained from the main site would be displayed to choose from.
Even more ideally, the sites would be sortable by geographic location / response time in milliseconds.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot from CD created from boot iso.
2. Run linux askmethod
3. Choose FTP install
4. Enter ftp.mirror.ac.uk in first box
5. Enter mirror/fedora.redhat.com/3/i386/os in second box
6. Continue

Actual Results:  FTP mirror could not be found

Expected Results:  FTP mirror should be found

Additional info:

Can fix by adding leading / to mirror/fedora.redhat.com/...
Other permutations of /'s give same problem. Worse with HTTP in FC3 due to bug #101265.

Comment 1 Shannon -jj Behrens 2005-10-26 22:45:05 UTC
The fact that it puts a double "//" at the start of the path was really
troublesome.  It did it no matter whether or not I started the path with a "/".
 Unlike Apache, the Web server I was using made any URL with "//" lead to a 404
instead of ignoring the second "/".

Accepting a whole URL instead of a HOST and a PATH would also be beneficial
because you could choose a different port.  Initially, my Web server was running
on port 8000, not port 80.  (Unfortunately, when I switched the server to listen
to port 80, I forgot to open up a hole in the firewall, but that was my own

Comment 2 Matthew Miller 2006-07-10 23:32:12 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 3 James Findley 2006-12-09 00:25:20 UTC
Same issues as comment #1. No matter how the url wes formatted, it added "//"
between the host and the path.  Bug now present in FC6 final, 

Comment 4 Andy Hudson 2006-12-16 20:56:08 UTC
(In reply to comment #3)
> Same issues as comment #1. No matter how the url wes formatted, it added "//"
> between the host and the path.  Bug now present in FC6 final, 

I am getting a similar thing in Fedora Core 6. Basically I am trying to install
onto a CD/DVD-less laptop by booting off a USB key. I get to the point where it
is asking the install method so I select FTP or HTTP (happens in both cases).

I enter the following:
FTP site name:
FC Directory: /fedora/6/core/rescue/

each time I get an error:

Unable to retrieve

This happens exactly the same for HTTP installs. I don't want to install over
the internet, and I don't have a DNS server in place that will translate IP
addresses to FQDNs.

This does not happen when I am using FQDNs, e.g. ftp.heanet.ie,

Can someone check this out as it is extremely annoying!



Comment 5 Red Hat Bugzilla 2007-06-12 02:49:49 UTC
requested by Jams Antill

Comment 6 Paul Zimmermann 2007-12-18 20:54:25 UTC
See also {bug 207278} and {bug 237548}.

Comment 7 David Hickenbottom 2008-01-07 19:39:00 UTC
I believe this problem exists in Fedora 8 as well.  I am using (would like to)
PXE boot to load and configure systems and I have been working through the 
issues and I have come to the point where the installation media hosted on a 
local http server is called via the "append" line in the boot configuration 
at the point it is to start downloading the media, is fails with the error:
cannot find media http:\\\\fedora\f8\images\...
if you press OK the dialog box shows the server and path in separate fill-in 
boxes.  However, no matter what I put in those boxes, an extra / is inserted 
and the error repeats.  I have tried different combinations of " and extra 
slashs. none seem to work.

Comment 8 David Hickenbottom 2008-01-07 19:42:34 UTC
Sorry my windows fingers were typing... that should have been:

Comment 9 Chris Lumens 2008-01-07 20:24:33 UTC
Please try with rawhide or F9 alpha, which is coming up alarmingly soon.  I have
reworked the URL method dialog to present just a single line for both the server
and the path.  If you are still seeing problems with the path, please attach
relevant sections from your web server logs so I can work on tracking them down.

Comment 10 David Hickenbottom 2008-01-09 01:47:28 UTC
I tried the rawhide vmlinuz0 and initrd0.img files and this caused a far
different problem.

after the two files are unpacked many lines scroll by and disk drives are
scanned and the message:

WARNING: Cannot find root file system!

Create symlink /dev/root and then exit this shell to continue the boot sequence.
My setup:
tftp server installed and enabled.
firewall ports 67 and 69 UDP opened
dhcpd settings:
ddns-update-style interim;
subnet netmask {
default-lease-time 3600;
max-lease-time 4800;
option routers;
option domain-name-servers;
option subnet-mask;
option domain-name "7bridgeshome.org";
option time-offset -5;

host bridges1 {
hardware ethernet 00:02:B3:06:C3:64;
option host-name "bridges1";
filename "pxelinux.0";

the root tftp directory is /TFTPBOOT
the directory listing:
drwxr-xr-x  3 root root    4096 2008-01-08 19:15 .
drwxr-xr-x 24 root root    4096 2008-01-08 19:09 ..
-rw-r--r--  1 root root 6587351 2008-01-05 18:31 initrd-f8.img
-rw-rw-r--  1 root root 4113900 2008-01-08 18:55 initrd-rawhide.img
-rw-r--r--  1 root root   13408 2007-10-17 11:55 pxelinux.0
drwxr-xr-x  2 root root    4096 2008-01-08 19:16 pxelinux.cfg
-rw-r--r--  1 root root 1978624 2008-01-05 18:31 vmlinuz-f8
-rw-rw-r--  1 root root 2105152 2008-01-08 19:11 vmlinuz-rawhide

the directory listing of pxelinux.cfg is:
drwxr-xr-x 2 root root 4096 2008-01-08 19:16 .
drwxr-xr-x 3 root root 4096 2008-01-08 19:15 ..
-rw-r--r-- 1 root root  362 2008-01-08 19:16 default

the contents of the file default:
prompt 1
default f8
timeout 100

label f8
kernel vmlinuz-rawhide
append initrd=initrd-rawhide.img ramdisk_size=9216 noapic acpi=off ip=dhcp
method= vnc vncpassword=f8

The only new files I used were vmlinuz0 and initrd0.img both renamed to match my

6224b49eb5a6e7613e758125515f1643  initrd-rawhide.img
d041acbb821dc1fc5bf90750fa0cec39  vmlinuz-rawhide

In case you read the pxelinux help guides... you will notice that they all say
that you need a group of files:
You do not.  The system scans for eac file from the most specific (mac address,
IP address and then more generic mac addresses (in hex) and if it does not find
any of those it looks for the file default.

Comment 11 David Hickenbottom 2008-02-08 23:30:11 UTC
I would really like this problem resolved, since I am not a coder, I do not 
know how I can help.  Is there anything I can do?  Do you need more information 
on the problem?  Can I help you test anything?  Do you need help documenting 
anything? thanks. (there is an extra / in the update above.. it should be: )


Comment 12 David Timms 2008-02-12 12:37:38 UTC
(In reply to comment #10)
> I tried the rawhide vmlinuz0 and initrd0.img files and this caused a far
> different problem.
> after the two files are unpacked many lines scroll by and disk drives are
> scanned and the message:
David H:
That would appear to be a different issue than originally reported. Would you
like to retest netboot with F9-alpha {or current rawhide} pxeboot bits ? If you
still see the same errors {ie as in comment 10}, then create a new bug with
those errors.
ps. could it be running out of ramdisk_size=9216 ?

Comment 13 David Timms 2008-02-12 12:56:58 UTC
Created attachment 294654 [details]
screenshot of vmware session during install

(In reply to comment #9)
> Please try with rawhide or F9 alpha, which is coming up alarmingly soon.
> I have reworked the URL method dialog to present just a single line for 
> both the server and the path.
OK. Booted boot.iso. 
The text mode installer has just a URL method {rather than the previous ftp and
http methods}. 
Entering a url eg: ftp://d.f.redhat.com/ to the F9-Alpha os folder works OK.
Second stage loads.
Package choice loads. {unselect the three parts - for a smaller DL/install}
Installation begins.
Install is taking a long time.
VT shows that occasionally download URLs are failing.
The system seems to wait some minutes, then try again - mostly this succeeds.

Note that the echoed Failed URLs are of the form:
WARNING : Try 3/10 for ftp://download.fedora.redhat.com//pub/fedora/linux/ ..
releases/test/9-Alpha/Fedora/i386/os/Packages/finger-0.17-35.fc8.i386.rpm faile
which does have an additional / between the host and the top dir, at least in
the error message. see attach.

Comment 14 David Timms 2008-02-12 13:17:09 UTC
I would say that the originally reported problem and solution {to allow URL's}
works for at least ftp protocol.

Comment 15 David Timms 2008-02-12 13:20:43 UTC
Created attachment 294657 [details]
wireshark-follow tcp stream for ftp control connection.

note that the first attempted {and successful on the redhat ftp server} is to
Perhaps that is a problem on certain types/config of ftp servers ?

Comment 16 David Hickenbottom 2008-02-13 15:21:16 UTC
I ran one test before I had to get to work this morning.  I added the new 
vmlinuz and initrd.img file and retried my test.  It got to the point of the 
original problem (that is a good thing).  In the message stating it could not 
find the media (which it was pointing to fedora 8 not f9 alpha) it showed as the attempted location.  When I pressed the 
key to continue it showed in the UNC fill-in 
space for the media.  When I pressed enter to accept this location, the 
message showed the UNC path as:

When I get home tonight I will fix the path so it points to the correct media 
location for fedora 9 alpha and see if it continue the install. 

Comment 17 David Hickenbottom 2008-02-14 00:27:52 UTC
I fixed the path to the files and it now works as expected.  The message above 
is still accurate.  If you have an invalid path to the distribution, it shows 
the two / marks between the host and the path. BUT IT WORKS Properly...
Thank you!!!

Comment 18 Joel Andres Granados 2008-04-18 11:33:20 UTC
We do a better job on the ftp and url installs.  This should be taken care of in

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