Bug 109324
| Summary: | kickstart via nfs, media via iso images on e1000 fails on first mount attempt | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Erik S. LaBianca <erik.labianca> |
| Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | CC: | jgarzik, m.a.young, xjmonaco |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-10-05 15:24:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Erik S. LaBianca
2003-11-06 20:23:45 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) 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. real 0m6.960s user 0m0.100s sys 0m0.100s 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... 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 "0.0.0.0") I hope this additional information helps. The e100 references, in my previous post, should read eepro100. My mistake. 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. Thanks, Joe Robertson This is a similar bug report <a href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=110036">110036</a> which contains a patch that seems to fix the problem. This should be fixed in current code. |