Bug 114092 - Anaconda is unable to get an ip address from the dhcp server.
Anaconda is unable to get an ip address from the dhcp server.
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
: SELinux
: 122518 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-01-22 11:19 EST by Tom Diehl
Modified: 2015-01-04 17:04 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-04 12:33:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Red Hat Bugzilla 2004-01-22 11:19:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
when attempting a fresh install via pxe and nfs anaconda is unable to
optain an ip adderss from the dhcp server.

Version-Release number of selected component (if applicable):
Latest rawhide as of 22 Jan 04

How reproducible:

Steps to Reproduce:
1.Boot machine via pxe
2.Answer questions foe lang etc.
3.Tell it to obtain an address via dhcp.    

Actual Results:  Anaconda does not get an ip address. In fact the
following error is printed into the logs on the dhcp server:
Jan 22 11:13:28 sylvester dhcpd: fallback_discard: Resource
temporarily unavailable

Expected Results:  It should get an ip address

Additional info:

FYI On the same machine, if I select my fc1 tree from the boot menu it
gets an address and loads the 2nd stage just fine.
Comment 1 Red Hat Bugzilla 2004-01-22 12:12:49 EST
Does booting with 'selinux=0' help?
Comment 2 Red Hat Bugzilla 2004-01-22 15:49:11 EST
Yes. It gets an address and continues normally up to the point of
mounting the 2nd stage image. It then fails to mount it but I am
assuming that is 114049. :-)
Comment 3 Red Hat Bugzilla 2004-01-22 18:30:11 EST
This seems to have worked in 1.47 and not with 1.52 which includes
bumping from -bk4 to -bk6.  The strange thing is that I although I see
the failure, mikem isn't.  The other thing of note is that I believe
that the following message shows up in the DHCP server's logs when the
problem occurs
  Jan 22 14:59:36 merry dhcpd: fallback_discard: Resource temporarily

which appears to show up as NIC bugs usually from googling.

Tom -- what net card are you using?  I can reproduce on a test box
with an e1000, but an e100 and a tulip both seem fine.

Any ideas from kernel folks added to the cc?
Comment 4 Red Hat Bugzilla 2004-01-22 22:16:02 EST
Are you in enforcing mode when this happens?
Is there a policy loaded?
Can you show me the SELinux log messages from when you boot until this
Comment 5 Red Hat Bugzilla 2004-01-22 23:01:51 EST
Not in enforcing mode, no policy loaded.  No SELinux log messages.

I can also reproduce outside of anaconda with just a simple pump
binary.  http://people.redhat.com/~katzj/testpump.  It will just run
in standalone and try to get an IP many more times than the default
with a little bit more sleeping to make sure the interface came up
(jgarzik's suggestion, but it doesn't appear to have made a difference).

Note that it's only a problem if you start with the interface has no
IP (set to  Initial state of up or down doesn't matter.  If
there's already an IP set for the interface, then it works.  If you
boot with selinux=0, it works.  

e100 and tulip seem to work, tg3 and e1000 fail so it could be
something weird with spanning tree on the switch, although it worked
with the earlier kernel.

Haven't tried jgarzik's other suggestion yet (building from 2.6-netdev
tree), but I'll try to get to that tomorrow.
Comment 6 Red Hat Bugzilla 2004-01-22 23:04:38 EST
They machine has a Realtek 8139 and a 3Com 3c905B in it. Both have the
problem and both work when selinux=0 is passed at boot.
Comment 7 Red Hat Bugzilla 2004-01-23 10:42:21 EST
The SELinux generated logs (e.g. whatever is in syslog since boot) and
the testpump source would be useful.
Comment 8 Red Hat Bugzilla 2004-01-23 11:02:18 EST
Grab the pump src rpm, rpmbuild -bc it.  Grab testpump.c from
http://people.redhat.com/~katzj/testpump.c.  Build with 
  gcc -o testpump testpump.c ./libpump.a

And nothing SELinux related is getting logged that I see (and anaconda
== wacky wacky environment with non-standard syslog, but I should at
least see the things spewed onto other ttys, even if I can't quite get
to them in a file at that point)
Comment 9 Red Hat Bugzilla 2004-01-23 17:26:36 EST
I am seeing this on one machine (IBM x335). This machine has dual
Broadcom NetXtreme BCM5703 nics.  Even this machine occasionally
manages to get an ip without passing selinux=0.
Comment 10 Red Hat Bugzilla 2004-01-24 22:50:33 EST
Is SELinux running in enforcing mode when this happens?

Also, please try and provide me with full tcpdump (binary output)
along with the strace output, and any log messages at either end.
Comment 11 Red Hat Bugzilla 2004-01-24 22:52:39 EST
Not in enforcing mode, no policy loaded.  See comment #5 above.

You should already have strace from the test program (I can't really
get it for anaconda in any sane way, hence why I reduced to a simple
test case).  And I can't get any more tcpdump information than I got
you on Friday until I'm back in the office on Monday.
Comment 12 Red Hat Bugzilla 2004-01-26 00:04:22 EST
> This seems to have worked in 1.47 and not with 1.52 which includes
> bumping from -bk4 to -bk6.

I don't think this is the cause...

(05:05:59:davej@delerium:davej)$ interdiff patch-2.6.1-rc1-bk4
patch-2.6.1-rc1-bk6 | diffstat
 arch/arm/kernel/dma-isa.c |    1
 arch/arm/kernel/fiq.c     |   24 ++++-----
 arch/arm/kernel/module.c  |    7 +-
 arch/arm/mm/mm-armv.c     |  117
 b/Makefile                |    2
 drivers/ide/ide-iops.c    |    9 +++
 drivers/serial/8250.c     |    7 --
 drivers/serial/8250_pnp.c |    5 +
 include/asm-arm/pgtable.h |   13 ++---
 9 files changed, 111 insertions(+), 74 deletions(-

Comment 13 Red Hat Bugzilla 2004-02-13 10:45:14 EST
I have this same problem on FC2-test1, on a machine with an RTl8139
network interface.   Setting selinux=0 on the kernel command line
allows me to get the IP address via dhcp.  

I see in the isolinux.cfg file for FC2-test1 that selinux=0 is used
for the installation -- but there's no mention of this change in the
release notes or the readme.   I think this would be a good candidate
for a release note, as this is a new requirement for network
installations as compared to FC1.
Comment 14 Red Hat Bugzilla 2004-02-13 13:25:21 EST
It was a temporary last minute workaround.  For the final release (for
test2 even), this is going to have to be fixed to enable selinux testing.
Comment 15 Red Hat Bugzilla 2004-02-15 01:23:19 EST
The problem has been identified, and a couple of fixes proposed.

To test, please apply this patch to the kernel:

The final form of the patch is still being discussed on netdev.

Comment 16 Red Hat Bugzilla 2004-02-16 23:21:25 EST
davej committed this patch for the kernel so setting to MODIFIED.  If
the kernel with this patch doesn't fix, I'll reopen.
Comment 26 Red Hat Bugzilla 2004-04-15 00:44:31 EDT
This should be all better with current trees
Comment 27 Red Hat Bugzilla 2004-04-20 14:19:20 EDT
Seems so..  closing...
Comment 28 Red Hat Bugzilla 2004-05-05 14:31:42 EDT
It's baaccckkkk as of 2.6.5-1.350

Arjan/James -- did we lose this fix somehow?
Comment 29 Red Hat Bugzilla 2004-05-05 14:35:16 EDT
*** Bug 122518 has been marked as a duplicate of this bug. ***
Comment 30 Red Hat Bugzilla 2004-05-05 14:38:37 EDT
Arjan removed it.
Comment 32 Red Hat Bugzilla 2004-05-06 11:35:41 EDT
to comment #28:
It's already back with 2.6.5-1.349 (maybe even earlier).

And selinux=0 doesn't seem to work (with neither 1.349 nor 1.350).

I have an e1000.
Comment 33 Red Hat Bugzilla 2004-05-06 11:42:12 EDT
This should be fixed in 1.352.
Comment 34 Red Hat Bugzilla 2004-05-08 12:07:59 EDT
1.353 works for me.
Comment 37 Red Hat Bugzilla 2004-05-10 16:18:30 EDT
I can't kickstart my wife's laptop with 0509's tree.  It fails to find
the pcmcia network interface. It worked in test2 and test3, but not
test1.  The kernel in the rescuecd used to start the install claims to
be 2.6.5-1.358.  2.6.5-1.358 works after installed on the laptop, with
pci=noacpi (also used for the installer boot; see bug 100528) as well
as the pcmcia boot-up work-around mentioned in bug 121742.  I tried
noacpi as well, to no avail.
Comment 38 Red Hat Bugzilla 2004-05-10 19:06:54 EDT
Same broken behavior with 0510's tree.
Comment 40 Red Hat Bugzilla 2004-05-11 02:07:23 EDT
Hmm...  It's most likely a timing issue.  If I move the pcmcia card
from the second slot to the first one, then it works just fine.  It's
a regression nevertheless, but a less serious one.  Did we remove any
sleep()s from between the time we load the pcmcia modules until the
time when we start the cardmgr and probe for cards (or something
equivalent)?  Something like the reversal of the patch in bug 116205,
but in the corresponding anaconda code?
Comment 41 Red Hat Bugzilla 2004-05-12 11:15:56 EDT
I'm changing the platform to all since my bug documenting this issue
on ia64 (Tiger SDV and Altix - both with integrated ethernet boards
of different types) was duplicated to this one.  

So I'm personally hitting this on ia64.  I hope this is ok....
Comment 45 Red Hat Bugzilla 2004-05-25 11:39:59 EDT
Although RHEL4 seems to work ok, I just saw this with rawhide 
using the 2.6.6-1.377 kernel and the 5/25/04 build.  Passing 
selinux=0 to the installer kernel worked though. 

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