New foreman discovery kernel option needed

Development
#1

Hello,

I have found out this week that Foreman Discovery image issues
additional DHCP request during boot. It was expected to have only two
requests (one for PXE boot, one for the live image), but we found three
on one site which caused issues during provisioning. For some reason,
ISC DHCP decided to issue three leases instead expected two, therefore
IP has changed and the one reported by facter was no longer valid.

It turned out that it's the RAMDISK requesting the additional
(unnecessary) IP address. The workaround is simple, to add two new
options to the kernel command line (pxelinux.cfg/default, in the Foreman
templates screen modify PXELinux global default and redeploy PXE
templates):

rd.bootif=0 rd.neednet=0

I am changing foreman_discovery README but for those of you who already
have Foreman Discovery in deployment, I recommend to add those options
and reboot all the nodes in the free pool to prevent from unexpected IP
changes.

https://github.com/theforeman/foreman_discovery/pull/91
https://github.com/lzap/foreman_discovery/commit/7a3b5ab8cba998cfd09dc3e11d457b71af4f41ca

This bug is not big deal for Foreman users, because Foreman presents
confirmation dialog with a DHCP conflict that could be overwritten.
Therefor the workaround is already built-in. But this is a blocker for
Staypuft plugin users, because the whole provisioning process is
automated and the conflict blocks the whole workflow.

··· -- Later, Lukas #lzap Zapletal
#2

Thanks, works like a charm!

··· On Friday, October 17, 2014 10:51:49 AM UTC+2, Lukas Zapletal wrote: > > Hello, > > I have found out this week that Foreman Discovery image issues > additional DHCP request during boot. It was expected to have only two > requests (one for PXE boot, one for the live image), but we found three > on one site which caused issues during provisioning. For some reason, > ISC DHCP decided to issue three leases instead expected two, therefore > IP has changed and the one reported by facter was no longer valid. > > It turned out that it's the RAMDISK requesting the additional > (unnecessary) IP address. The workaround is simple, to add two new > options to the kernel command line (pxelinux.cfg/default, in the Foreman > templates screen modify PXELinux global default and redeploy PXE > templates): > > rd.bootif=0 rd.neednet=0 > > I am changing foreman_discovery README but for those of you who already > have Foreman Discovery in deployment, I recommend to add those options > and reboot all the nodes in the free pool to prevent from unexpected IP > changes. > > https://github.com/theforeman/foreman_discovery/pull/91 > > https://github.com/lzap/foreman_discovery/commit/7a3b5ab8cba998cfd09dc3e11d457b71af4f41ca > > This bug is not big deal for Foreman users, because Foreman presents > confirmation dialog with a DHCP conflict that could be overwritten. > Therefor the workaround is already built-in. But this is a blocker for > Staypuft plugin users, because the whole provisioning process is > automated and the conflict blocks the whole workflow. > > -- > Later, > Lukas #lzap Zapletal >
#3

Thanks, out of my curiosity, what kind of problems were you facing to?

LZ

··· -- Later, Lukas #lzap Zapletal