From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 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: Always 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.
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 problem occurs Jan 22 14:59:36 merry dhcpd: fallback_discard: Resource temporarily unavailable 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 happens?
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: http://people.redhat.com/jmorris/net/nf-csum-writable-01.patch 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. Jesse