Bug 250003 - DHCP client sometimes does not get an IP address with kernel-2.6.22.1-33.fc7
Summary: DHCP client sometimes does not get an IP address with kernel-2.6.22.1-33.fc7
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 249698 249886 249950 249999 250032 250034 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-29 10:27 UTC by Bernd Bartmann
Modified: 2007-11-30 22:12 UTC (History)
10 users (show)

Fixed In Version: 2.6.22.1-41.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-08-01 14:29:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bernd Bartmann 2007-07-29 10:27:35 UTC
Description of problem:
Since updating to kernel-2.6.22.1-33.fc7 I'm having massive problems to get an
IP address via DHCP. During startup the boot process stays forever at "Getting
IP address for eth0". The kernel has not locked up as I still can use
CTRL-ATL-DEL to reboot. Also, everything is ok if I set the IP address manually
with ifconfig, only DHCP seems to fail. The network card is an Intel E1000.
There is nothing in the logs as syslog is started after network in rc5.d.

Version-Release number of selected component (if applicable):
2.6.22.1-33.fc7 

How reproducible:
Sometimes, when using DHCP

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Peter Bieringer 2007-07-29 15:05:51 UTC
Me, too, looks like 2.6.22 has a bug here. Perhaps related:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227266

Comment 2 Milan Kerslager 2007-08-01 09:33:34 UTC
A lot of different machines does not get IP by DHCP client here with
kernel-2.6.22.1-33.fc7 because the client indefinitely waiting even receiving
DHCP reply (as seen by manual executing with debugging output enabled). Older
kernels based on 2.6.21 works ok. I don't have access to all FC7 kernel updates
to find which update breaked it up exactly (but I am able to try with some URL
to the archive).

There is no difference between old and new motherboards (from 800MHz to
completly new systems from different manufacturers) or different Ethernet cards
(onboard or in the slot) except some modern mobos only waits for ~10 or so
minutes and then continuing and works ok.

Comment 3 Peter Bieringer 2007-08-01 09:42:33 UTC
Is there any reason why such a buggy (see also
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249857) kernel would be not
replaced by a working one (e.g. roll-back using EPOCH)? Many non-experienced F7
users are now sitting in front of a no longer proper working desktop (no net, no
proper time on desktop and in syslog), probably having no idea, what's happen
after the latest applied kernel updates.

BTW: FC6 users have no such problems (at the moment)


Comment 4 Milan Kerslager 2007-08-01 10:53:51 UTC
Older kernel works OK and user is able to make a choice at startup. Also fixed
IP is OK.

The kernel-2.6.22.1-41.fc7 (released today) seems to solve the problem.

The bug could be closed and reopened if problem persit somewhere.

Comment 5 Milan Kerslager 2007-08-01 11:01:22 UTC
*** Bug 250034 has been marked as a duplicate of this bug. ***

Comment 6 Milan Kerslager 2007-08-01 11:03:12 UTC
*** Bug 249999 has been marked as a duplicate of this bug. ***

Comment 7 Milan Kerslager 2007-08-01 11:04:02 UTC
*** Bug 249950 has been marked as a duplicate of this bug. ***

Comment 8 Milan Kerslager 2007-08-01 11:04:45 UTC
*** Bug 249931 has been marked as a duplicate of this bug. ***

Comment 9 Milan Kerslager 2007-08-01 11:07:00 UTC
*** Bug 249886 has been marked as a duplicate of this bug. ***

Comment 10 Milan Kerslager 2007-08-01 11:07:13 UTC
*** Bug 249698 has been marked as a duplicate of this bug. ***

Comment 11 Chuck Ebbert 2007-08-01 19:29:16 UTC
*** Bug 250032 has been marked as a duplicate of this bug. ***


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