Operating System - Linux
1748170 Members
3858 Online
108758 Solutions
New Discussion

DHCP problem when discovering new bare-metal servers

 
jaime serrano
Occasional Contributor

DHCP problem when discovering new bare-metal servers

Hi,

I´m having some problems with my new ICELX and I hope you could give me some info.

I'm using a XEN environment and both the server and the CMS are virtual machines. Maybe it could be important.

Anyway, I post the problem:

The server boots normally within the PXE, detects the DHCP, receive the ram disk image from the tftp and once it has boot almost completely starts to try to locate the dhcp server again looking for an ip for the nic. The problem, and it´s really amazing for me is that the server tries to locate the dhcp throught the loopback, and obviouslly nobody answers.

The message is the following:

DHCPDISCOVER on lo to 255.255.255.255 port 67 interval x (it repeats some times the same message)
NO DHCP OFFERS RECEIVED
No working leases in persistent detabase - sleeping.
I couldn´t configure the network interface using DCHP
Killing off running processes

... and prompt

I'm going to try with physical servers when I can get one but if anyone has some info i will thank you.



4 REPLIES 4
Steven E. Protter
Exalted Contributor

Re: DHCP problem when discovering new bare-metal servers

Shalom,

The DCHP server is either down, not configured or not on the network.

That is the source of the problem.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
jaime serrano
Occasional Contributor

Re: DHCP problem when discovering new bare-metal servers

Thanks Steven for your answer but I'm afraid that is not so simple.

The DHCP is working perfectly since the server can boot from PXE, load the RAM disk image and complete all the steps. The server only has one nic enabled so if the server answers to the DHCP/PXE request once, there is no reason to think it wouldn't do it again.

I have been investigating deeper and I have discovered that the server (remember that is a Xen virtual machine) doesn´t load the nic drivers when it boots from the RAM disc kernel so the only interface available is the loopback. This answer my first question but generates a new one.. Is this due to I´m using a VM and the kernel is not compatible? I suppose it will use generic-Linux drivers so...

Any ideas?

Thanks

William Athanasiou
Occasional Advisor

Re: DHCP problem when discovering new bare-metal servers

The problem is that there's only a limited number of drivers that are loaded before a connection is established with the CMS. The only ethernet drives available are the tg3, e100, and bnx2 drivers. Your virtual machine needs a different driver. Is there a way for the virtual machine's ethernet device to simulate one of those? If not, you can fix this, but it will take a bit of work. You would basically have to crack open the ramdisk's initrd.img (uncompress it, and mount it using -o loop), pull the appropriate drivers out of the boel_binaries.tar.gz (in /usr/share/systemimager/boot/i386/standard) and put them in the my_modules directory. Once that's been done, modify the script in that directory to load the drivers.

Hope that helps.
jaime serrano
Occasional Contributor

Re: DHCP problem when discovering new bare-metal servers

Thanks William for your answer. I have supposed something like it. I will try this work around but at least I know what it´s happening.