Description of problem:
I'm using PXE to kickstart a Tyan 7500 system, using linux ks
ksdevice=eth0. I'm copying the kickstart file from nfs, which is on
the same server as the dhcp server. The kickstart file is copied over
fine, and the network is reinitialized. When the computer tries to
mount the media to complete the install, it reports an error along the
lines of "The directory could not be mounted". Selecting ok, leaving
the nfs mount information exactly the same, and hitting ok to try
again mounts the directory just fine, after which the kickstart succeeds.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. setup pxe boot using linux ks ksdevice=eth0 on i7500 board
2. setup kickstart file including nfs --server=192.168.1.10
3. kickstart system
system asks for a new nfs location, which isn't necessary
I'm guessing that the primary ethernet (an e1000) isn't fully
initialized by the time anaconda attempts to nfs mount the install
media. If it the nfs mount was automatically retried, or a pause was
added after eth0 reinitialization, i think this problem would go away.
It looks closely related to bug 103952
Jeff -- how long should conceivably be waited here? We already try to
wait for five seconds to ensure that the link is up before continuing
-- longer is kind of annoying for the cases when there actually isn't
link (especially for hardware/drivers where link reporting doesn't work)
If you can suggest a way to determine how long to wait, or to get more
detailed information, I'd be happy to try it. Looking at the debug
consoles there is no output. I just know that the install works
perfectly as soon as I have it try the second time manually.
There may be something else going on too, it seems to me like 5
seconds ought to be plenty of time to wait...
If this helps, heres how long it takes to reinit the device with dhcp
under a working system. FYI I have tried the kickstart with a static
ip and get the sames results:
[root@fisher root]# ifdown eth0; time ifup eth0; ping -c1 192.168.1.10
Determining IP information for eth0... done.
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=0 ttl=64 time=0.303 ms
--- 192.168.1.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.303/0.303/0.303/0.000 ms, pipe 2
I had a very similar problem with bug 90774, where the e1000 took
15-20 seconds to come up.
I realize it's from the development section at the Fedora web-site,
but I ftp'ed the i386 related files to the KickStart server we use for
testing, and attempted to do and NFS KickStart install. I have
identical problems with an e100 and an e1000 port.
On the KickStart server, /var/log/messages reports:
dhcpd: receive_packet failed on eth2: Resource temporarily unavailable
and on the clients I see on tty3:
sending dhcp request through device eth1
waiting for link...
pump told us: No DHCP reply recieved
and on tty4:
eth1 NIC Link is Up 100 Mbps Full duplex
(also all of the "breq" messages involving IPs were populated with
I hope this additional information helps.
The e100 references, in my previous post, should read eepro100. My
This sounds very much like a problem I'm having.
I'm working with fc2 test2 and have found that if I'm using the e1000
driver for the onboard Gigabit interface (Dell 1600sc) the nfs mount
always fails. If I insert a 3COM 3C904c card and use the e100
driver, the entire process works as it should.
When I use the e1000, the interactive install via pxeboot works as it
should - it is only when I try to do a kickstart that I have
problems. If I put the kickstart file on a floppy, the file is read
OK then it fails when it tries to mount the install media via NFS.
This is a similar bug report <a
which contains a patch that seems to fix the problem.
This should be fixed in current code.