Red Hat Bugzilla – Bug 114092
Anaconda is unable to get an ip address from the dhcp server.
Last modified: 2015-01-04 17:04:24 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
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
Expected Results: It should get an ip address
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.
Does booting with 'selinux=0' help?
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. :-)
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
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?
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
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 0.0.0.0). 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.
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.
The SELinux generated logs (e.g. whatever is in syslog since boot) and
the testpump source would be useful.
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)
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.
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.
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.
> 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(-
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.
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.
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.
davej committed this patch for the kernel so setting to MODIFIED. If
the kernel with this patch doesn't fix, I'll reopen.
This should be all better with current trees
Seems so.. closing...
It's baaccckkkk as of 2.6.5-1.350
Arjan/James -- did we lose this fix somehow?
*** Bug 122518 has been marked as a duplicate of this bug. ***
Arjan removed it.
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.
This should be fixed in 1.352.
1.353 works for me.
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.
Same broken behavior with 0510's tree.
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?
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....
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.