Description of problem:
When I try to install FC6 on an system witch contains only an hard disk via PXE,
anaconda will hangs for 5 minutes, after enter the ftp server's password.
Then the menu for selecting the server will comes again.
Version-Release number of selected component (if applicable):
that comes with the PXE image of the FC6 DVD
At the console I can seen, that anaconda try's to load an file witch not comes
ERROR: got to setupCdrom without CD device
INFO: transferring ftp://SERVER/PATH/images/updates.img to an fd
INFO: transferring ftp://SERVER/PATH/disc1/images/updates.img to an fd
But the file updates.img don't come with FC.
After images/updates.img anaconda try's to get an file called images/product.img
We try to grab them if they exist, but if they don't, then we're fine. Does it
not try to get images/stage2.img (or images/minstg2.img)?
No, it will not try it.
This sounds like network problems after the FTP config information has been set
up. If there's a really long timeout, it could be NFS being down or configured
incorrectly. What sort of information are you entering on the FTP config
screen? Is this still a problem with F7 test 2? Can you post everything you
see on tty3 so we can get some more context on what's going on?
NFS is not used, only FTP. And there is no timeout.
I only enter the path,server,user name and password.
Is there a way to store the log of anaconda?
Is there an faster server then download.fedora.redhat.com to download FC7 test2?
I meant DNS, not NFS.
If you get to the graphical stage of the installer, you can look at
/tmp/anaconda.log. Otherwise, you'll need to do something like take a picture
of the contents of tty3.
I don't know of any rankings for the mirrors for speed. I guess just try to
pick one close to you, if locations are listed.
I don't come to the graphical stage. I will try the FC 7 test2 tomorrow.
Today FC7 test 3 is out, and I will retry it.
So tested with FC7 test3 same error.:(
Created attachment 151353 [details]
The output of tty3.
Tested with FC7-test4 same error.
Can you add loglevel=debug to your boot flags and take another picture like the
one in comment #10? Also, what are you entering into the fields on the FTP
server dialog? If you're using your own layout, what's the structure of it?
Created attachment 153921 [details]
The output of tty3 with debug.
I enter this in the fields:
under tree under disk1:
drwxr-xr-x 2 ftp ftp 106496 Apr 29 09:06 Fedora
-rw-r--r-- 3 ftp ftp 18385 Apr 05 2005 GPL
-rw-r--r-- 1 ftp ftp 10000 Apr 26 20:57
-rw-r--r-- 1 ftp ftp 147767 Apr 26 20:57 RELEASE-NOTES-en_US.html
-rw-r--r-- 3 ftp ftp 1910 Oct 15 2006 RPM-GPG-KEY
-rw-r--r-- 3 ftp ftp 1706 Oct 15 2006 RPM-GPG-KEY-beta
-rw-r--r-- 3 ftp ftp 1519 Oct 15 2006 RPM-GPG-KEY-fedora
-rw-r--r-- 3 ftp ftp 2043 Oct 15 2006 RPM-GPG-KEY-fedora-extras
-rw-r--r-- 3 ftp ftp 1722 Oct 15 2006 RPM-GPG-KEY-fedora-legacy
-rw-r--r-- 3 ftp ftp 1105 Oct 15 2006 RPM-GPG-KEY-fedora-rawhide
-rw-r--r-- 3 ftp ftp 1076 Oct 15 2006 RPM-GPG-KEY-fedora-test
-rw-r--r-- 3 ftp ftp 1232 Oct 15 2006 RPM-GPG-KEY-rawhide
-r--r--r-- 1 ftp ftp 4320 Apr 26 20:57 TRANS.TBL
-rw-r--r-- 1 ftp ftp 2882 Apr 26 20:57 fedora.css
drwxr-xr-x 4 ftp ftp 4096 Apr 26 20:57 images
drwxr-xr-x 2 ftp ftp 4096 Apr 29 09:06 isolinux
drwxr-xr-x 2 ftp ftp 4096 Apr 26 20:57 repodata
drwxr-xr-x 2 ftp ftp 4096 Apr 29 09:06 stylesheet-images
I have try it with the full DNS name or Fedora/core/DVD/7 as the directory
Here some addition information.
I have tested it today with different network options her the result:
- without DHCP and set the full DNS name:OK
- without DHCP and set only the host name: Fail
- with DHCP both of above fails.
- with DHCP and use the IP address and not the name: OK
Your DHCP server is sending out the following info:
DNS server: 192.168.0.1
domain name: netz-von-frank
So when you tell it to go to 'homer', it would be looking up homer.netz-von-frank.
What happens if you run: 'host homer.netz-von-frank 192.168.0.1' on a machine on
your network? Does that give the right IP?
Yes it is so.
Here the output:
homer.netz-von-frank has address 192.168.0.1
homer.netz-von-frank has address 192.168.1.1
homer.netz-von-frank has IPv6 address fc00:0:0:1::1
Are 192.168.0.1 and 192.168.1.1 within the same network, e.g. 192.168.0.0/23?
Sorry when asking such dumb now - can you be sure, it's not a IPv6 issue of
the FTP/NFS server?
192.168.0.1 and 192.168.1.1 are not in the same network.
And the client can only reach 192.168.0.1 because 192.168.1.X are an pure router
network. IPv6 is disabled on the client. And an normal ftp access from other
system will work.
IÂ´m also trying to install Fedora 7 (final) via PXE/FTP.
IÂ´ve setup an FTP on my 2nd PC, mounted the F7-Image and shared it.
Now, when I boot my machine via FTP an want to install via FTP, Anaconda prompts
me for IP-Address and the address of the FTP.
Now Anaconda connects to my FTP and looks for an "updates.img".
If I select FTP an give a mirror-FTP in the internet, thereÂ´s no problem an it
starts downloading stage2.img.
WahtÂ´s the matter?? I think this is very wierd... :(
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: