Have you tried adding dhclient to your package list in your kickstart file.
The trick with a nobase install is you can often be surprised by some
of the things that are missing from it.
if you don't have /sbin/dhclient on the host than that is probably your problem.


On Sun, Dec 1, 2013 at 12:21 PM, John Lauro <[log in to unmask]> wrote:
> If the switches have spanning tree protocol (default for most enterprise grade switches), they probably disable the port for 30-60 seconds to make sure there is no loop, and so loading the network driver may unlink the port long enough for the switch to disable the port again for 30-60 seconds.  To test for this issue, have you system working, run a constant ping, unplug the network, wait 5 seconds, plug it in and see how long it takes to start working again.
>
> To avoid this problem, I configure most of my switch ports for spanning-tree portfast.  Alternatively, it might take upto a minute for dhcp to start working...
>
>
> ----- Original Message -----
>> From: "olli hauer" <[log in to unmask]>
>> To: [log in to unmask]
>> Cc: "~Stack~" <[log in to unmask]>
>> Sent: Sunday, December 1, 2013 11:36:06 AM
>> Subject: Re: No DHCP on boot with a fresh install
>>
>> On 2013-11-30 20:24, ~Stack~ wrote:
>> > On 11/30/2013 01:03 PM, Nico Kadel-Garcia wrote:
>> >> You shouldn't have to install NetworkManager for servers. It is
>> >> *NOT*
>> >> your friend.
>> >
>> > I agree. However, I have wasted too much time already on this
>> > problem
>> > (several hours last night and several again this morning) and
>> > installing
>> > NetworkManager is the easy way out at the moment. I need and would
>> > rather focus my attention on the project and not chasing down a
>> > DHCP
>> > problem. It really sucks I have to install so many more unneeded
>> > packages just to get DHCP to work on boot. Such an absurd problem
>> > to have.
>> >
>> >> Neither is DHCP for servers, since sometimes upstream
>> >> switches have not yet detected the active device by the time your
>> >> client has scurried its way through the local host restart. In
>> >> general, I keep servers set statically, and only set them to DHCP
>> >> when
>> >> planning a migration. You might this and see if it brings up the
>> >> network at boot time reliably.
>> >
>> > Agreed. Most of my servers are actually hard set. However, in this
>> > particular project things would be so much better if I had a
>> > working
>> > DHCP at boot.
>> >
>> >> If the upstream detection is the issue, put a "sleep 10" in the
>> >> "start" stanza of /etc/nit.d/network. Amusingly enough, you can
>> >> even
>> >> put it in /etc/sysconfig/network-scripts/ifcfg-eth0, although that
>> >> can
>> >> get irritating and tools like system-config-network or
>> >> NetworkManager
>> >> will happily overwrite it.
>> >
>> > Not a bad idea. I just tried it and didn't get it to work. Maybe 10
>> > seconds is too short?
>> >
>> > I will probably just script something when I have time and shove it
>> > into
>> > puppet. However, it seems to me that others are also having/seen
>> > this
>> > problem. Maybe this should be something fixed upstream?
>> >
>> > Thanks for the help everyone!
>> > ~Stack~
>>
>> Are this bare metal boxes or virtual systems?
>>
>> Perhaps you can find a hint with `dmesg' or by disabling the
>> (annoying)
>> splash boot so you see what happens when the network is initialized.
>>
>> As workaround you can create a simple init script that tries to
>> detect if the network is up and running (ping GW address) and
>> executes
>> ifdown/ifup.
>>
>> --
>> olli
>>