Bug 109324 - kickstart via nfs, media via iso images on e1000 fails on first mount attempt
Summary: kickstart via nfs, media via iso images on e1000 fails on first mount attempt
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 1
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-06 20:23 UTC by Erik S. LaBianca
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-05 15:24:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Erik S. LaBianca 2003-11-06 20:23:45 UTC
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):

How reproducible:


Steps to Reproduce:
1. setup pxe boot using linux ks ksdevice=eth0 on i7500 board
2. setup kickstart file including nfs --server=
3. kickstart system
Actual results:
system asks for a new nfs location, which isn't necessary

Expected results:
system installs

Additional info:
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

Comment 1 Jeremy Katz 2003-11-06 23:06:42 UTC
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)

Comment 2 Erik S. LaBianca 2003-11-06 23:33:14 UTC
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

Determining IP information for eth0... done.

real    0m6.960s
user    0m0.100s
sys     0m0.100s
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=0 ttl=64 time=0.303 ms

--- 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

Comment 3 Michael Young 2003-11-10 22:02:56 UTC
I had a very similar problem with bug 90774, where the e1000 took
15-20 seconds to come up.

Comment 4 John S. Monaco 2004-01-30 20:26:27 UTC
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...
0 seconds.
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.

Comment 5 John S. Monaco 2004-02-02 22:15:49 UTC
The e100 references, in my previous post, should read eepro100. My

Comment 6 Joe Robertson 2004-04-27 08:20:56 UTC
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.

Joe Robertson

Comment 7 Joshua Weage 2004-08-11 13:32:05 UTC
This is a similar bug report <a
which contains a patch that seems to fix the problem.

Comment 8 Jeremy Katz 2004-10-05 15:24:28 UTC
This should be fixed in current code.

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