[RFC PATCH] ensure DHCP is current via sync

[Nishanth Aravamudan]

Hi,

I encountered a rather annoying problem with cobbler for ppc64 systems.
The way these machines netboot is controlled by the SMS configuration,
and if the SMS menu receives a DHCP response, even if it eventually
fails, it will stay in an infinite loop within the netboot code. That
code is not modifiable by me (owned by system firmware). What I
encountered with Cobbler was that after an install succeeded, the DHCP
configuration file was left alone. So the DHCP server would respond on
the network on the next boot and the target server never booted from the
disk.

I worked around this by only generating the DHCP configuration if a
system does have netboot_enabled set and re-generating the DHCP files
via sync() whenever disable_netboot() is called.

Signed-off-by: Nishanth Aravamudan <nacc(a)us.ibm.com&gt;

diff --git a/cobbler/modules/manage_isc.py b/cobbler/modules/manage_isc.py
index b8f857f..8681d94 100644
--- a/cobbler/modules/manage_isc.py
+++ b/cobbler/modules/manage_isc.py
@@ -161,6 +161,9 @@ class IscManager:
                 interface["owner"] = blended_system["name"]
                 interface["enable_gpxe"] =
blended_system["enable_gpxe"]
 
+                if not interface["netboot_enabled"]:
+                    continue
+
                 interface["filename"] = "/pxelinux.0"
                 # can't use pxelinux.0 anymore
                 if distro is not None:
diff --git a/cobbler/remote.py b/cobbler/remote.py
index 0035e34..28cf180 100644
--- a/cobbler/remote.py
+++ b/cobbler/remote.py
@@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
         obj.set_netboot_enabled(0)
         # disabling triggers and sync to make this extremely fast.
        
systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
+        # re-generate dhcp configuration
+        self.api.sync()
         return True
 
     def upload_log_data(self, sys_name, file, size, offset, data, token=None,**rest):

-- 
Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
IBM Linux Technology Center

[James Cammarata]

On Wed, Mar 28, 2012 at 11:24 AM, Nishanth Aravamudan
<nacc(a)linux.vnet.ibm.com&gt; wrote:
>  Hi,
>
>  I encountered a rather annoying problem with cobbler for ppc64 systems.
>  The way these machines netboot is controlled by the SMS configuration,
>  and if the SMS menu receives a DHCP response, even if it eventually
>  fails, it will stay in an infinite loop within the netboot code. That
>  code is not modifiable by me (owned by system firmware). What I
>  encountered with Cobbler was that after an install succeeded, the DHCP
>  configuration file was left alone. So the DHCP server would respond on
>  the network on the next boot and the target server never booted from the
>  disk.
>
>  I worked around this by only generating the DHCP configuration if a
>  system does have netboot_enabled set and re-generating the DHCP files
>  via sync() whenever disable_netboot() is called.
>
>  Signed-off-by: Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
>
>  diff --git a/cobbler/modules/manage_isc.py b/cobbler/modules/manage_isc.py
>  index b8f857f..8681d94 100644
>  --- a/cobbler/modules/manage_isc.py
>  +++ b/cobbler/modules/manage_isc.py
>  @@ -161,6 +161,9 @@ class IscManager:
>                  interface["owner"] = blended_system["name"]
>                  interface["enable_gpxe"] =
> blended_system["enable_gpxe"]
>
>  +                if not interface["netboot_enabled"]:
>  +                    continue
>  +
>                  interface["filename"] = "/pxelinux.0"
>                  # can't use pxelinux.0 anymore
>                  if distro is not None:
>  diff --git a/cobbler/remote.py b/cobbler/remote.py
>  index 0035e34..28cf180 100644
>  --- a/cobbler/remote.py
>  +++ b/cobbler/remote.py
>  @@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
>          obj.set_netboot_enabled(0)
>          # disabling triggers and sync to make this extremely fast.
>         
> systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
>  +        # re-generate dhcp configuration
>  +        self.api.sync()
>          return True
>
>      def upload_log_data(self, sys_name, file, size, offset, data, token=None,**rest):
>
>  -- 
Does this still happen if you use the cobbler trigger to set
netboot-enabled to false? Not sure if that's a valid option for
whatever OS you're building or not but take a look at the
kickstart_done snippet.

Forcing a full sync every time a system changes the netboot-enabled
flag is probably not a good solution though, as this is a very
time-consuming operation for cobbler installations with a large number
of distros/systems/profiles. Unfortunately, ISC's dhcpd doesn't have a
great CLI command option so doing dynamic updates doesn't seem to
work, unless someone can point me to some good docs on the subject.
Everything I've found says the CLI management tool is spotty at best.

[Nishanth Aravamudan]

On 28.03.2012 [18:40:09 -0500], James Cammarata wrote:
>  On Wed, Mar 28, 2012 at 11:24 AM, Nishanth Aravamudan
>  <nacc(a)linux.vnet.ibm.com&gt; wrote:
>  > Hi,
>  >
>  > I encountered a rather annoying problem with cobbler for ppc64 systems.
>  > The way these machines netboot is controlled by the SMS configuration,
>  > and if the SMS menu receives a DHCP response, even if it eventually
>  > fails, it will stay in an infinite loop within the netboot code. That
>  > code is not modifiable by me (owned by system firmware). What I
>  > encountered with Cobbler was that after an install succeeded, the DHCP
>  > configuration file was left alone. So the DHCP server would respond on
>  > the network on the next boot and the target server never booted from the
>  > disk.
>  >
>  > I worked around this by only generating the DHCP configuration if a
>  > system does have netboot_enabled set and re-generating the DHCP files
>  > via sync() whenever disable_netboot() is called.
>  >
>  > Signed-off-by: Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
>  >
>  > diff --git a/cobbler/modules/manage_isc.py b/cobbler/modules/manage_isc.py
>  > index b8f857f..8681d94 100644
>  > --- a/cobbler/modules/manage_isc.py
>  > +++ b/cobbler/modules/manage_isc.py
>  > @@ -161,6 +161,9 @@ class IscManager:
>  >                 interface["owner"] = blended_system["name"]
>  >                 interface["enable_gpxe"] =
> blended_system["enable_gpxe"]
>  >
>  > +                if not interface["netboot_enabled"]:
>  > +                    continue
>  > +
>  >                 interface["filename"] = "/pxelinux.0"
>  >                 # can't use pxelinux.0 anymore
>  >                 if distro is not None:
>  > diff --git a/cobbler/remote.py b/cobbler/remote.py
>  > index 0035e34..28cf180 100644
>  > --- a/cobbler/remote.py
>  > +++ b/cobbler/remote.py
>  > @@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
>  >         obj.set_netboot_enabled(0)
>  >         # disabling triggers and sync to make this extremely fast.
>  >        
> systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
>  > +        # re-generate dhcp configuration
>  > +        self.api.sync()
>  >         return True
>  >
>  >     def upload_log_data(self, sys_name, file, size, offset, data,
> token=None,**rest):
>  >
>  > --
>  
>  Does this still happen if you use the cobbler trigger to set
>  netboot-enabled to false? Not sure if that's a valid option for
>  whatever OS you're building or not but take a look at the
>  kickstart_done snippet. 
I'm not sure I understand entirely. I have 'pxe_just_once' set to 1 in
my /etc/cobbler/settings, and that does nicely unset the netboot enabled
flag for the systems that are net-installed. However, the problem I saw
(and I can try and test without my changes to re-confirm this) is that
the DHCP server is still configured to respond over the network when
this flag is changed (by default), so the netbooting machine gets a DHCP
response, but the netboot environment no longer exists, and we fail. But
system firmware is so dumb in this instnace that it just cycles there,
rather than failing over ...

>  Forcing a full sync every time a system changes the netboot-enabled
>  flag is probably not a good solution though, as this is a very
>  time-consuming operation for cobbler installations with a large number
>  of distros/systems/profiles. Unfortunately, ISC's dhcpd doesn't have a
>  great CLI command option so doing dynamic updates doesn't seem to
>  work, unless someone can point me to some good docs on the subject.
>  Everything I've found says the CLI management tool is spotty at best. 
Would it be possible to perhaps add a 'dhcpsync()' variant of sync that
only ensured the DHCP configuration was updated (with the above chnage
to ensure netboot disabled servers weren't listed)?

If not, I'm happy to carry the above chagne locally.

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
IBM Linux Technology Center

[James Cammarata]

> > Does this still happen if you use the cobbler trigger to set
> > netboot-enabled to false? Not sure if that's a valid option for
> > whatever OS you're building or not but take a look at the
> > kickstart_done snippet.
>
>  I'm not sure I understand entirely. I have 'pxe_just_once' set to 1 in
>  my /etc/cobbler/settings, and that does nicely unset the netboot enabled
>  flag for the systems that are net-installed. However, the problem I saw
>  (and I can try and test without my changes to re-confirm this) is that
>  the DHCP server is still configured to respond over the network when
>  this flag is changed (by default), so the netbooting machine gets a DHCP
>  response, but the netboot environment no longer exists, and we fail. But
>  system firmware is so dumb in this instnace that it just cycles there,
>  rather than failing over ... 
Interesting, what it should be doing is creating a PXE file but with
the only option being to boot from local disk. Maybe that doesn't work
for ppc64 systems?

> > Forcing a full sync every time a system changes the
> netboot-enabled
> > flag is probably not a good solution though, as this is a very
> > time-consuming operation for cobbler installations with a large number
> > of distros/systems/profiles. Unfortunately, ISC's dhcpd doesn't have a
> > great CLI command option so doing dynamic updates doesn't seem to
> > work, unless someone can point me to some good docs on the subject.
> > Everything I've found says the CLI management tool is spotty at best.
>
>  Would it be possible to perhaps add a 'dhcpsync()' variant of sync that
>  only ensured the DHCP configuration was updated (with the above chnage
>  to ensure netboot disabled servers weren't listed)?
>
>  If not, I'm happy to carry the above chagne locally. 
I would accept a patch for that, I could see it being useful to
regenerate the dhcp config without doing a full sync.

[Nishanth Aravamudan]

On 04.04.2012 [17:39:24 -0500], James Cammarata wrote:
>  >> Does this still happen if you use the cobbler trigger to
> set
>  >> netboot-enabled to false? Not sure if that's a valid option for
>  >> whatever OS you're building or not but take a look at the
>  >> kickstart_done snippet.
>  >
>  > I'm not sure I understand entirely. I have 'pxe_just_once' set to 1 in
>  > my /etc/cobbler/settings, and that does nicely unset the netboot enabled
>  > flag for the systems that are net-installed. However, the problem I saw
>  > (and I can try and test without my changes to re-confirm this) is that
>  > the DHCP server is still configured to respond over the network when
>  > this flag is changed (by default), so the netbooting machine gets a DHCP
>  > response, but the netboot environment no longer exists, and we fail. But
>  > system firmware is so dumb in this instnace that it just cycles there,
>  > rather than failing over ...
>  
>  Interesting, what it should be doing is creating a PXE file but with
>  the only option being to boot from local disk. Maybe that doesn't work
>  for ppc64 systems? 
Yeah, I don't think that's how netbooting works in general. Basically,
once we have a netboot configuration (either hard-coded in the SMS menus
or discovered via DHCP), we tftpboot yaboot, and then yaboot goes and
looks for a yaboot.conf (or per-MAC address configuration, if present).
yaboot itself is what does the kernel/initrd netloading. So i think what
happens is DHCP says 'hey go load yaboot', and we perhaps load yaboot
(as it's globally present in /var/lib/tftpboot) but then there is no
corresponding per-MAC address configuration, so we fail to find a kernel
to load (installer or otherwise). And since there is no yaboot.conf
found, we don't have an easy way to fallback to the disk (which has its
own yaboot, etc.)

>  >> Forcing a full sync every time a system changes the
> netboot-enabled
>  >> flag is probably not a good solution though, as this is a very
>  >> time-consuming operation for cobbler installations with a large number
>  >> of distros/systems/profiles. Unfortunately, ISC's dhcpd doesn't have a
>  >> great CLI command option so doing dynamic updates doesn't seem to
>  >> work, unless someone can point me to some good docs on the subject.
>  >> Everything I've found says the CLI management tool is spotty at best.
>  >
>  > Would it be possible to perhaps add a 'dhcpsync()' variant of sync that
>  > only ensured the DHCP configuration was updated (with the above chnage
>  > to ensure netboot disabled servers weren't listed)?
>  >
>  > If not, I'm happy to carry the above chagne locally.
>  
>  I would accept a patch for that, I could see it being useful to
>  regenerate the dhcp config without doing a full sync. 
Sounds good, I'll start working on the changes. Do you prefer all
changes to come as pull requests?

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
IBM Linux Technology Center

[Bill Peck]

On 04/04/2012 06:39 PM, James Cammarata wrote:
> >> Does this still happen if you use the cobbler trigger to set
> >> netboot-enabled to false? Not sure if that's a valid option for
> >> whatever OS you're building or not but take a look at the
> >> kickstart_done snippet.
> > I'm not sure I understand entirely. I have 'pxe_just_once' set to 1 in
> > my /etc/cobbler/settings, and that does nicely unset the netboot enabled
> > flag for the systems that are net-installed. However, the problem I saw
> > (and I can try and test without my changes to re-confirm this) is that
> > the DHCP server is still configured to respond over the network when
> > this flag is changed (by default), so the netbooting machine gets a DHCP
> > response, but the netboot environment no longer exists, and we fail. But
> > system firmware is so dumb in this instnace that it just cycles there,
> > rather than failing over ...
>  Interesting, what it should be doing is creating a PXE file but with
>  the only option being to boot from local disk. Maybe that doesn't work
>  for ppc64 systems? 
We netboot ppc64 systems every day in cobbler.  They are a
little 
different from x86 systems in that the netboot entry *must* be deleted 
since there is no localboot equivalent.

> >> Forcing a full sync every time a system changes the netboot-enabled
> >> flag is probably not a good solution though, as this is a very
> >> time-consuming operation for cobbler installations with a large number
> >> of distros/systems/profiles. Unfortunately, ISC's dhcpd doesn't have a
> >> great CLI command option so doing dynamic updates doesn't seem to
> >> work, unless someone can point me to some good docs on the subject.
> >> Everything I've found says the CLI management tool is spotty at best.
> > Would it be possible to perhaps add a 'dhcpsync()' variant of sync that
> > only ensured the DHCP configuration was updated (with the above chnage
> > to ensure netboot disabled servers weren't listed)?
> >
> > If not, I'm happy to carry the above chagne locally.
>  I would accept a patch for that, I could see it being useful to
>  regenerate the dhcp config without doing a full sync.
>  _______________________________________________
>  cobbler-devel mailing list
>  cobbler-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler-devel

[James Cammarata]

> > Interesting, what it should be doing is creating a PXE file but
> with
> > the only option being to boot from local disk. Maybe that doesn't work
> > for ppc64 systems?
>
>  We netboot ppc64 systems every day in cobbler.  They are a little different
>  from x86 systems in that the netboot entry *must* be deleted since there is
>  no localboot equivalent. 
Good to know, I had not looked at the ppc64 pxe stuff at all.

[Bill Peck]

On 04/05/2012 08:45 AM, James Cammarata wrote:
> >> Interesting, what it should be doing is creating a PXE file
> but with
> >> the only option being to boot from local disk. Maybe that doesn't work
> >> for ppc64 systems?
> > We netboot ppc64 systems every day in cobbler.  They are a little different
> > from x86 systems in that the netboot entry *must* be deleted since there is
> > no localboot equivalent.
>  Good to know, I had not looked at the ppc64 pxe stuff at all.
>  _______________________________________________
>  cobbler-devel mailing list
>  cobbler-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler-devel 
It very well could be the version of yaboot that this person is using 
behaves differently.

I did a strings on our version and its the same version but the release 
is much higher..
"Welcome to yaboot version 1.3.14 (Red Hat 1.3.14-23.fc12)"

In action_dlcontent it has:
yaboot-1.3.14-12

And the md5sums are definitely different.

I can send the newer yaboot to the list if needed.

[Nishanth Aravamudan]

On 05.04.2012 [09:36:04 -0400], Bill Peck wrote:
>  On 04/05/2012 08:45 AM, James Cammarata wrote:
>  >>>Interesting, what it should be doing is creating a PXE file but with
>  >>>the only option being to boot from local disk. Maybe that doesn't work
>  >>>for ppc64 systems?
>  >>We netboot ppc64 systems every day in cobbler.  They are a little different
>  >>from x86 systems in that the netboot entry *must* be deleted since there is
>  >>no localboot equivalent.
>  >Good to know, I had not looked at the ppc64 pxe stuff at all.
>  >_______________________________________________
>  >cobbler-devel mailing list
>  >cobbler-devel(a)lists.fedorahosted.org
>  >https://fedorahosted.org/mailman/listinfo/cobbler-devel
>  
>  It very well could be the version of yaboot that this person is
>  using behaves differently.
>  
>  I did a strings on our version and its the same version but the
>  release is much higher..
>  "Welcome to yaboot version 1.3.14 (Red Hat 1.3.14-23.fc12)"
>  
>  In action_dlcontent it has:
>  yaboot-1.3.14-12
>  
>  And the md5sums are definitely different.
>  
>  I can send the newer yaboot to the list if needed. 
We (IBM/LTC) definitely support getting the latest & greatest yaboot put
in cobbler. I can build one from source and send it out too.

Also, it would probably make sense not to depend on /yaboot-1.3.14 but
/yaboot, which is the normal path.

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
IBM Linux Technology Center

[Nishanth Aravamudan]

On 04.04.2012 [13:26:40 -0700], Nishanth Aravamudan wrote:
>  On 28.03.2012 [18:40:09 -0500], James Cammarata wrote:
>  > On Wed, Mar 28, 2012 at 11:24 AM, Nishanth Aravamudan
>  > <nacc(a)linux.vnet.ibm.com&gt; wrote:
>  > > Hi,
>  > >
>  > > I encountered a rather annoying problem with cobbler for ppc64 systems.
>  > > The way these machines netboot is controlled by the SMS configuration,
>  > > and if the SMS menu receives a DHCP response, even if it eventually
>  > > fails, it will stay in an infinite loop within the netboot code. That
>  > > code is not modifiable by me (owned by system firmware). What I
>  > > encountered with Cobbler was that after an install succeeded, the DHCP
>  > > configuration file was left alone. So the DHCP server would respond on
>  > > the network on the next boot and the target server never booted from the
>  > > disk.
>  > >
>  > > I worked around this by only generating the DHCP configuration if a
>  > > system does have netboot_enabled set and re-generating the DHCP files
>  > > via sync() whenever disable_netboot() is called.
>  > >
>  > > Signed-off-by: Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
>  > >
>  > > diff --git a/cobbler/modules/manage_isc.py b/cobbler/modules/manage_isc.py
>  > > index b8f857f..8681d94 100644
>  > > --- a/cobbler/modules/manage_isc.py
>  > > +++ b/cobbler/modules/manage_isc.py
>  > > @@ -161,6 +161,9 @@ class IscManager:
>  > >                 interface["owner"] =
> blended_system["name"]
>  > >                 interface["enable_gpxe"] =
> blended_system["enable_gpxe"]
>  > >
>  > > +                if not interface["netboot_enabled"]:
>  > > +                    continue
>  > > +
>  > >                 interface["filename"] = "/pxelinux.0"
>  > >                 # can't use pxelinux.0 anymore
>  > >                 if distro is not None:
>  > > diff --git a/cobbler/remote.py b/cobbler/remote.py
>  > > index 0035e34..28cf180 100644
>  > > --- a/cobbler/remote.py
>  > > +++ b/cobbler/remote.py
>  > > @@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
>  > >         obj.set_netboot_enabled(0)
>  > >         # disabling triggers and sync to make this extremely fast.
>  > >        
> systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
>  > > +        # re-generate dhcp configuration
>  > > +        self.api.sync()
>  > >         return True
>  > >
>  > >     def upload_log_data(self, sys_name, file, size, offset, data,
> token=None,**rest):
>  > >
>  > > --
>  > 
>  > Does this still happen if you use the cobbler trigger to set
>  > netboot-enabled to false? Not sure if that's a valid option for
>  > whatever OS you're building or not but take a look at the
>  > kickstart_done snippet.
>  
>  I'm not sure I understand entirely. I have 'pxe_just_once' set to 1 in
>  my /etc/cobbler/settings, and that does nicely unset the netboot enabled
>  flag for the systems that are net-installed. However, the problem I saw
>  (and I can try and test without my changes to re-confirm this) is that
>  the DHCP server is still configured to respond over the network when
>  this flag is changed (by default), so the netbooting machine gets a DHCP
>  response, but the netboot environment no longer exists, and we fail. But
>  system firmware is so dumb in this instnace that it just cycles there,
>  rather than failing over ... 
So on a P7 machine I'm testing on, here's what I see happen without my
changes. I netboot & install FC16 and it works perfectly. The system
reboots after installation and the result on the console is:

TFTP BOOT ---------------------------------------------------
Server IP.....................9.3.191.134
Client IP.....................9.3.192.206
Gateway IP....................9.3.192.1
Subnet Mask...................255.255.255.0
( 1  ) Filename................./yaboot-1.3.14
TFTP Retries..................5 
Block Size....................1024 
FINAL PACKET COUNT = 194 
FINAL FILE SIZE = 198376  BYTES

Elapsed time since release of system processors: 39016 mins 13 secs

ipv6 = <0>
siaddr = <9.3.191.134>
file = <>
ciaddr = <9.3.192.206>
giaddr = <9.3.192.1>
bootp_retries = <0>
tftp_retries = <5>
addl_params = <1024>
dhcpv6 = <<NULL>>
blksize = <<NULL>>
Try to netboot


TFTP BOOT ---------------------------------------------------
Server IP.....................9.3.191.134
Client IP.....................9.3.192.206
Gateway IP....................9.3.192.1
Subnet Mask...................255.255.255.0
( 1  ) Filename.................\etc\01-82-5c-6d-80-0a-04
TFTP Retries..................5 
Block Size....................1024 
1 
2 
3 
        !BA017021 !

Error, can't read config file



TFTP BOOT ---------------------------------------------------
Server IP.....................9.3.191.134
Client IP.....................9.3.192.206
Gateway IP....................9.3.192.1
Subnet Mask...................255.255.255.0
( 1  ) Filename.................\etc\yaboot.conf
TFTP Retries..................5 
Block Size....................1024 
1 
2 
3 
        !BA017021 !

Error, can't read config file
Welcome to yaboot version 1.3.16
Enter "help" to get some basic usage information
boot:

with no boot options available.

So the problem is, as I mentioned earlier, that we respond over DHCP
with the yaboot binary itself, but there is no corresponding
configuration file and yaboot fails to work. Now, it would be nice if
yaboot could somehow fall back to the next OF boot device (in theory
this is available to yaboot to figure out). I will talk to Tony Breeds
about it and see if that's possible, but I think we still want to fix
this for current yaboot/cobbler installations.

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
IBM Linux Technology Center

[Nishanth Aravamudan]

On 28.03.2012 [18:40:09 -0500], James Cammarata wrote:
>  On Wed, Mar 28, 2012 at 11:24 AM, Nishanth Aravamudan
>  <nacc(a)linux.vnet.ibm.com&gt; wrote:
>  > Hi,
>  >
>  > I encountered a rather annoying problem with cobbler for ppc64 systems.
>  > The way these machines netboot is controlled by the SMS configuration,
>  > and if the SMS menu receives a DHCP response, even if it eventually
>  > fails, it will stay in an infinite loop within the netboot code. That
>  > code is not modifiable by me (owned by system firmware). What I
>  > encountered with Cobbler was that after an install succeeded, the DHCP
>  > configuration file was left alone. So the DHCP server would respond on
>  > the network on the next boot and the target server never booted from the
>  > disk.
>  >
>  > I worked around this by only generating the DHCP configuration if a
>  > system does have netboot_enabled set and re-generating the DHCP files
>  > via sync() whenever disable_netboot() is called.
>  >
>  > Signed-off-by: Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
>  >
>  > diff --git a/cobbler/modules/manage_isc.py b/cobbler/modules/manage_isc.py
>  > index b8f857f..8681d94 100644
>  > --- a/cobbler/modules/manage_isc.py
>  > +++ b/cobbler/modules/manage_isc.py
>  > @@ -161,6 +161,9 @@ class IscManager:
>  >                 interface["owner"] = blended_system["name"]
>  >                 interface["enable_gpxe"] =
> blended_system["enable_gpxe"]
>  >
>  > +                if not interface["netboot_enabled"]:
>  > +                    continue
>  > +
>  >                 interface["filename"] = "/pxelinux.0"
>  >                 # can't use pxelinux.0 anymore
>  >                 if distro is not None:
>  > diff --git a/cobbler/remote.py b/cobbler/remote.py
>  > index 0035e34..28cf180 100644
>  > --- a/cobbler/remote.py
>  > +++ b/cobbler/remote.py
>  > @@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
>  >         obj.set_netboot_enabled(0)
>  >         # disabling triggers and sync to make this extremely fast.
>  >        
> systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
>  > +        # re-generate dhcp configuration
>  > +        self.api.sync()
>  >         return True
>  >
>  >     def upload_log_data(self, sys_name, file, size, offset, data,
> token=None,**rest):
>  >
>  > --
>  
>  Does this still happen if you use the cobbler trigger to set
>  netboot-enabled to false? Not sure if that's a valid option for
>  whatever OS you're building or not but take a look at the
>  kickstart_done snippet. 
I am looking at kick_start_done and not entirely sure what it does :) I
see it echo's values at the end, but I'm not sure how that ties to
anything else?

I will note that with pxe_just_once (which I have set here), the
netboot_enabled flag does get unset after installation, but as I
mentioned in my other e-mail that's insufficient for yaboot.

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
IBM Linux Technology Center

[Bill Peck]

On 04/05/2012 11:26 AM, Nishanth Aravamudan wrote:
>  On 04.04.2012 [13:26:40 -0700], Nishanth Aravamudan wrote:
> > On 28.03.2012 [18:40:09 -0500], James Cammarata wrote:
> >> On Wed, Mar 28, 2012 at 11:24 AM, Nishanth Aravamudan
> >> <nacc(a)linux.vnet.ibm.com&gt;  wrote:
> >>> Hi,
> >>>
> >>> I encountered a rather annoying problem with cobbler for ppc64 systems.
> >>> The way these machines netboot is controlled by the SMS configuration,
> >>> and if the SMS menu receives a DHCP response, even if it eventually
> >>> fails, it will stay in an infinite loop within the netboot code. That
> >>> code is not modifiable by me (owned by system firmware). What I
> >>> encountered with Cobbler was that after an install succeeded, the DHCP
> >>> configuration file was left alone. So the DHCP server would respond on
> >>> the network on the next boot and the target server never booted from the
> >>> disk.
> >>>
> >>> I worked around this by only generating the DHCP configuration if a
> >>> system does have netboot_enabled set and re-generating the DHCP files
> >>> via sync() whenever disable_netboot() is called.
> >>>
> >>> Signed-off-by: Nishanth Aravamudan&lt;nacc(a)us.ibm.com&gt;
> >>>
> >>> diff --git a/cobbler/modules/manage_isc.py b/cobbler/modules/manage_isc.py
> >>> index b8f857f..8681d94 100644
> >>> --- a/cobbler/modules/manage_isc.py
> >>> +++ b/cobbler/modules/manage_isc.py
> >>> @@ -161,6 +161,9 @@ class IscManager:
> >>>                  interface["owner"] =
> blended_system["name"]
> >>>                  interface["enable_gpxe"] =
> blended_system["enable_gpxe"]
> >>>
> >>> +                if not interface["netboot_enabled"]:
> >>> +                    continue
> >>> +
> >>>                  interface["filename"] = "/pxelinux.0"
> >>>                  # can't use pxelinux.0 anymore
> >>>                  if distro is not None:
> >>> diff --git a/cobbler/remote.py b/cobbler/remote.py
> >>> index 0035e34..28cf180 100644
> >>> --- a/cobbler/remote.py
> >>> +++ b/cobbler/remote.py
> >>> @@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
> >>>          obj.set_netboot_enabled(0)
> >>>          # disabling triggers and sync to make this extremely fast.
> >>>         
> systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
> >>> +        # re-generate dhcp configuration
> >>> +        self.api.sync()
> >>>          return True
> >>>
> >>>      def upload_log_data(self, sys_name, file, size, offset, data,
> token=None,**rest):
> >>>
> >>> --
> >> Does this still happen if you use the cobbler trigger to set
> >> netboot-enabled to false? Not sure if that's a valid option for
> >> whatever OS you're building or not but take a look at the
> >> kickstart_done snippet.
> > I'm not sure I understand entirely. I have 'pxe_just_once' set to 1 in
> > my /etc/cobbler/settings, and that does nicely unset the netboot enabled
> > flag for the systems that are net-installed. However, the problem I saw
> > (and I can try and test without my changes to re-confirm this) is that
> > the DHCP server is still configured to respond over the network when
> > this flag is changed (by default), so the netbooting machine gets a DHCP
> > response, but the netboot environment no longer exists, and we fail. But
> > system firmware is so dumb in this instnace that it just cycles there,
> > rather than failing over ...
>  So on a P7 machine I'm testing on, here's what I see happen without my
>  changes. I netboot&  install FC16 and it works perfectly. The system
>  reboots after installation and the result on the console is:
>
>  TFTP BOOT ---------------------------------------------------
>  Server IP.....................9.3.191.134
>  Client IP.....................9.3.192.206
>  Gateway IP....................9.3.192.1
>  Subnet Mask...................255.255.255.0
>  ( 1  ) Filename................./yaboot-1.3.14
>  TFTP Retries..................5
>  Block Size....................1024
>  FINAL PACKET COUNT = 194
>  FINAL FILE SIZE = 198376  BYTES
>
>  Elapsed time since release of system processors: 39016 mins 13 secs
>
>  ipv6 =<0>
>  siaddr =<9.3.191.134>
>  file =<>
>  ciaddr =<9.3.192.206>
>  giaddr =<9.3.192.1>
>  bootp_retries =<0>
>  tftp_retries =<5>
>  addl_params =<1024>
>  dhcpv6 =<<NULL>>
>  blksize =<<NULL>>
>  Try to netboot
>
>
>  TFTP BOOT ---------------------------------------------------
>  Server IP.....................9.3.191.134
>  Client IP.....................9.3.192.206
>  Gateway IP....................9.3.192.1
>  Subnet Mask...................255.255.255.0
>  ( 1  ) Filename.................\etc\01-82-5c-6d-80-0a-04
>  TFTP Retries..................5
>  Block Size....................1024
>  1
>  2
>  3
>           !BA017021 !
>
>  Error, can't read config file
>
>
>
>  TFTP BOOT ---------------------------------------------------
>  Server IP.....................9.3.191.134
>  Client IP.....................9.3.192.206
>  Gateway IP....................9.3.192.1
>  Subnet Mask...................255.255.255.0
>  ( 1  ) Filename.................\etc\yaboot.conf
>  TFTP Retries..................5
>  Block Size....................1024
>  1
>  2
>  3
>           !BA017021 !
>
>  Error, can't read config file
>  Welcome to yaboot version 1.3.16
>  Enter "help" to get some basic usage information
>  boot:
>
>  with no boot options available.
>
>  So the problem is, as I mentioned earlier, that we respond over DHCP
>  with the yaboot binary itself, but there is no corresponding
>  configuration file and yaboot fails to work. Now, it would be nice if
>  yaboot could somehow fall back to the next OF boot device (in theory
>  this is available to yaboot to figure out). I will talk to Tony Breeds
>  about it and see if that's possible, but I think we still want to fix
>  this for current yaboot/cobbler installations. 
This is exactly what happens with the version of yaboot we are using.

I need to ask around to find out who built this version of yaboot for us 
and where the source is.  Once I find this out I'll pass it along to the 
list.

>  Thanks,
>  Nish
>

[Nishanth Aravamudan]

On 05.04.2012 [11:58:54 -0400], Bill Peck wrote:
>  On 04/05/2012 11:26 AM, Nishanth Aravamudan wrote:
>  >On 04.04.2012 [13:26:40 -0700], Nishanth Aravamudan wrote:
>  >>On 28.03.2012 [18:40:09 -0500], James Cammarata wrote:
>  >>>On Wed, Mar 28, 2012 at 11:24 AM, Nishanth Aravamudan
>  >>><nacc(a)linux.vnet.ibm.com>  wrote:
>  >>>>Hi,
>  >>>>
>  >>>>I encountered a rather annoying problem with cobbler for ppc64 systems.
>  >>>>The way these machines netboot is controlled by the SMS configuration,
>  >>>>and if the SMS menu receives a DHCP response, even if it eventually
>  >>>>fails, it will stay in an infinite loop within the netboot code. That
>  >>>>code is not modifiable by me (owned by system firmware). What I
>  >>>>encountered with Cobbler was that after an install succeeded, the DHCP
>  >>>>configuration file was left alone. So the DHCP server would respond on
>  >>>>the network on the next boot and the target server never booted from the
>  >>>>disk.
>  >>>>
>  >>>>I worked around this by only generating the DHCP configuration if a
>  >>>>system does have netboot_enabled set and re-generating the DHCP files
>  >>>>via sync() whenever disable_netboot() is called.
>  >>>>
>  >>>>Signed-off-by: Nishanth Aravamudan<nacc(a)us.ibm.com>
>  >>>>
>  >>>>diff --git a/cobbler/modules/manage_isc.py
> b/cobbler/modules/manage_isc.py
>  >>>>index b8f857f..8681d94 100644
>  >>>>--- a/cobbler/modules/manage_isc.py
>  >>>>+++ b/cobbler/modules/manage_isc.py
>  >>>>@@ -161,6 +161,9 @@ class IscManager:
>  >>>>                 interface["owner"] =
> blended_system["name"]
>  >>>>                 interface["enable_gpxe"] =
> blended_system["enable_gpxe"]
>  >>>>
>  >>>>+                if not interface["netboot_enabled"]:
>  >>>>+                    continue
>  >>>>+
>  >>>>                 interface["filename"] =
> "/pxelinux.0"
>  >>>>                 # can't use pxelinux.0 anymore
>  >>>>                 if distro is not None:
>  >>>>diff --git a/cobbler/remote.py b/cobbler/remote.py
>  >>>>index 0035e34..28cf180 100644
>  >>>>--- a/cobbler/remote.py
>  >>>>+++ b/cobbler/remote.py
>  >>>>@@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
>  >>>>         obj.set_netboot_enabled(0)
>  >>>>         # disabling triggers and sync to make this extremely fast.
>  >>>>        
> systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
>  >>>>+        # re-generate dhcp configuration
>  >>>>+        self.api.sync()
>  >>>>         return True
>  >>>>
>  >>>>     def upload_log_data(self, sys_name, file, size, offset, data,
> token=None,**rest):
>  >>>>
>  >>>>--
>  >>>Does this still happen if you use the cobbler trigger to set
>  >>>netboot-enabled to false? Not sure if that's a valid option for
>  >>>whatever OS you're building or not but take a look at the
>  >>>kickstart_done snippet.
>  >>I'm not sure I understand entirely. I have 'pxe_just_once' set to 1
> in
>  >>my /etc/cobbler/settings, and that does nicely unset the netboot enabled
>  >>flag for the systems that are net-installed. However, the problem I saw
>  >>(and I can try and test without my changes to re-confirm this) is that
>  >>the DHCP server is still configured to respond over the network when
>  >>this flag is changed (by default), so the netbooting machine gets a DHCP
>  >>response, but the netboot environment no longer exists, and we fail. But
>  >>system firmware is so dumb in this instnace that it just cycles there,
>  >>rather than failing over ...
>  >So on a P7 machine I'm testing on, here's what I see happen without my
>  >changes. I netboot&  install FC16 and it works perfectly. The system
>  >reboots after installation and the result on the console is:
>  >
>  >TFTP BOOT ---------------------------------------------------
>  >Server IP.....................9.3.191.134
>  >Client IP.....................9.3.192.206
>  >Gateway IP....................9.3.192.1
>  >Subnet Mask...................255.255.255.0
>  >( 1  ) Filename................./yaboot-1.3.14
>  >TFTP Retries..................5
>  >Block Size....................1024
>  >FINAL PACKET COUNT = 194
>  >FINAL FILE SIZE = 198376  BYTES
>  >
>  >Elapsed time since release of system processors: 39016 mins 13 secs
>  >
>  >ipv6 =<0>
>  >siaddr =<9.3.191.134>
>  >file =<>
>  >ciaddr =<9.3.192.206>
>  >giaddr =<9.3.192.1>
>  >bootp_retries =<0>
>  >tftp_retries =<5>
>  >addl_params =<1024>
>  >dhcpv6 =<<NULL>>
>  >blksize =<<NULL>>
>  >Try to netboot
>  >
>  >
>  >TFTP BOOT ---------------------------------------------------
>  >Server IP.....................9.3.191.134
>  >Client IP.....................9.3.192.206
>  >Gateway IP....................9.3.192.1
>  >Subnet Mask...................255.255.255.0
>  >( 1  ) Filename.................\etc\01-82-5c-6d-80-0a-04
>  >TFTP Retries..................5
>  >Block Size....................1024
>  >1
>  >2
>  >3
>  >         !BA017021 !
>  >
>  >Error, can't read config file
>  >
>  >
>  >
>  >TFTP BOOT ---------------------------------------------------
>  >Server IP.....................9.3.191.134
>  >Client IP.....................9.3.192.206
>  >Gateway IP....................9.3.192.1
>  >Subnet Mask...................255.255.255.0
>  >( 1  ) Filename.................\etc\yaboot.conf
>  >TFTP Retries..................5
>  >Block Size....................1024
>  >1
>  >2
>  >3
>  >         !BA017021 !
>  >
>  >Error, can't read config file
>  >Welcome to yaboot version 1.3.16
>  >Enter "help" to get some basic usage information
>  >boot:
>  >
>  >with no boot options available.
>  >
>  >So the problem is, as I mentioned earlier, that we respond over DHCP
>  >with the yaboot binary itself, but there is no corresponding
>  >configuration file and yaboot fails to work. Now, it would be nice if
>  >yaboot could somehow fall back to the next OF boot device (in theory
>  >this is available to yaboot to figure out). I will talk to Tony Breeds
>  >about it and see if that's possible, but I think we still want to fix
>  >this for current yaboot/cobbler installations.
>  
>  This is exactly what happens with the version of yaboot we are using.
>  
>  I need to ask around to find out who built this version of yaboot
>  for us and where the source is.  Once I find this out I'll pass it
>  along to the list. 
Hrm, I just built yaboot 1.3.17 from the git tree, and it does the same
thing (although it tries more configuration files (MAC address prefixes,
etc.)) before failing identically. So either your yaboot has some local
modifications that should go upstream, or your yaboot.conf is different?

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
IBM Linux Technology Center

[Nishanth Aravamudan]

On 05.04.2012 [13:09:19 -0700], Nishanth Aravamudan wrote:
>  On 05.04.2012 [11:58:54 -0400], Bill Peck wrote:
>  > On 04/05/2012 11:26 AM, Nishanth Aravamudan wrote:
>  > >On 04.04.2012 [13:26:40 -0700], Nishanth Aravamudan wrote:
>  > >>On 28.03.2012 [18:40:09 -0500], James Cammarata wrote:
>  > >>>On Wed, Mar 28, 2012 at 11:24 AM, Nishanth Aravamudan
>  > >>><nacc(a)linux.vnet.ibm.com>  wrote:
>  > >>>>Hi,
>  > >>>>
>  > >>>>I encountered a rather annoying problem with cobbler for ppc64
> systems.
>  > >>>>The way these machines netboot is controlled by the SMS
> configuration,
>  > >>>>and if the SMS menu receives a DHCP response, even if it eventually
>  > >>>>fails, it will stay in an infinite loop within the netboot code.
> That
>  > >>>>code is not modifiable by me (owned by system firmware). What I
>  > >>>>encountered with Cobbler was that after an install succeeded, the
> DHCP
>  > >>>>configuration file was left alone. So the DHCP server would respond
> on
>  > >>>>the network on the next boot and the target server never booted from
> the
>  > >>>>disk.
>  > >>>>
>  > >>>>I worked around this by only generating the DHCP configuration if a
>  > >>>>system does have netboot_enabled set and re-generating the DHCP
> files
>  > >>>>via sync() whenever disable_netboot() is called.
>  > >>>>
>  > >>>>Signed-off-by: Nishanth Aravamudan<nacc(a)us.ibm.com>
>  > >>>>
>  > >>>>diff --git a/cobbler/modules/manage_isc.py
> b/cobbler/modules/manage_isc.py
>  > >>>>index b8f857f..8681d94 100644
>  > >>>>--- a/cobbler/modules/manage_isc.py
>  > >>>>+++ b/cobbler/modules/manage_isc.py
>  > >>>>@@ -161,6 +161,9 @@ class IscManager:
>  > >>>>                 interface["owner"] =
> blended_system["name"]
>  > >>>>                 interface["enable_gpxe"] =
> blended_system["enable_gpxe"]
>  > >>>>
>  > >>>>+                if not interface["netboot_enabled"]:
>  > >>>>+                    continue
>  > >>>>+
>  > >>>>                 interface["filename"] =
> "/pxelinux.0"
>  > >>>>                 # can't use pxelinux.0 anymore
>  > >>>>                 if distro is not None:
>  > >>>>diff --git a/cobbler/remote.py b/cobbler/remote.py
>  > >>>>index 0035e34..28cf180 100644
>  > >>>>--- a/cobbler/remote.py
>  > >>>>+++ b/cobbler/remote.py
>  > >>>>@@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
>  > >>>>         obj.set_netboot_enabled(0)
>  > >>>>         # disabling triggers and sync to make this extremely fast.
>  > >>>>        
> systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
>  > >>>>+        # re-generate dhcp configuration
>  > >>>>+        self.api.sync()
>  > >>>>         return True
>  > >>>>
>  > >>>>     def upload_log_data(self, sys_name, file, size, offset, data,
> token=None,**rest):
>  > >>>>
>  > >>>>--
>  > >>>Does this still happen if you use the cobbler trigger to set
>  > >>>netboot-enabled to false? Not sure if that's a valid option for
>  > >>>whatever OS you're building or not but take a look at the
>  > >>>kickstart_done snippet.
>  > >>I'm not sure I understand entirely. I have 'pxe_just_once' set
> to 1 in
>  > >>my /etc/cobbler/settings, and that does nicely unset the netboot enabled
>  > >>flag for the systems that are net-installed. However, the problem I saw
>  > >>(and I can try and test without my changes to re-confirm this) is that
>  > >>the DHCP server is still configured to respond over the network when
>  > >>this flag is changed (by default), so the netbooting machine gets a DHCP
>  > >>response, but the netboot environment no longer exists, and we fail. But
>  > >>system firmware is so dumb in this instnace that it just cycles there,
>  > >>rather than failing over ...
>  > >So on a P7 machine I'm testing on, here's what I see happen without my
>  > >changes. I netboot&  install FC16 and it works perfectly. The system
>  > >reboots after installation and the result on the console is:
>  > >
>  > >TFTP BOOT ---------------------------------------------------
>  > >Server IP.....................9.3.191.134
>  > >Client IP.....................9.3.192.206
>  > >Gateway IP....................9.3.192.1
>  > >Subnet Mask...................255.255.255.0
>  > >( 1  ) Filename................./yaboot-1.3.14
>  > >TFTP Retries..................5
>  > >Block Size....................1024
>  > >FINAL PACKET COUNT = 194
>  > >FINAL FILE SIZE = 198376  BYTES
>  > >
>  > >Elapsed time since release of system processors: 39016 mins 13 secs
>  > >
>  > >ipv6 =<0>
>  > >siaddr =<9.3.191.134>
>  > >file =<>
>  > >ciaddr =<9.3.192.206>
>  > >giaddr =<9.3.192.1>
>  > >bootp_retries =<0>
>  > >tftp_retries =<5>
>  > >addl_params =<1024>
>  > >dhcpv6 =<<NULL>>
>  > >blksize =<<NULL>>
>  > >Try to netboot
>  > >
>  > >
>  > >TFTP BOOT ---------------------------------------------------
>  > >Server IP.....................9.3.191.134
>  > >Client IP.....................9.3.192.206
>  > >Gateway IP....................9.3.192.1
>  > >Subnet Mask...................255.255.255.0
>  > >( 1  ) Filename.................\etc\01-82-5c-6d-80-0a-04
>  > >TFTP Retries..................5
>  > >Block Size....................1024
>  > >1
>  > >2
>  > >3
>  > >         !BA017021 !
>  > >
>  > >Error, can't read config file
>  > >
>  > >
>  > >
>  > >TFTP BOOT ---------------------------------------------------
>  > >Server IP.....................9.3.191.134
>  > >Client IP.....................9.3.192.206
>  > >Gateway IP....................9.3.192.1
>  > >Subnet Mask...................255.255.255.0
>  > >( 1  ) Filename.................\etc\yaboot.conf
>  > >TFTP Retries..................5
>  > >Block Size....................1024
>  > >1
>  > >2
>  > >3
>  > >         !BA017021 !
>  > >
>  > >Error, can't read config file
>  > >Welcome to yaboot version 1.3.16
>  > >Enter "help" to get some basic usage information
>  > >boot:
>  > >
>  > >with no boot options available.
>  > >
>  > >So the problem is, as I mentioned earlier, that we respond over DHCP
>  > >with the yaboot binary itself, but there is no corresponding
>  > >configuration file and yaboot fails to work. Now, it would be nice if
>  > >yaboot could somehow fall back to the next OF boot device (in theory
>  > >this is available to yaboot to figure out). I will talk to Tony Breeds
>  > >about it and see if that's possible, but I think we still want to fix
>  > >this for current yaboot/cobbler installations.
>  > 
>  > This is exactly what happens with the version of yaboot we are using.
>  > 
>  > I need to ask around to find out who built this version of yaboot
>  > for us and where the source is.  Once I find this out I'll pass it
>  > along to the list.
>  
>  Hrm, I just built yaboot 1.3.17 from the git tree, and it does the same
>  thing (although it tries more configuration files (MAC address prefixes,
>  etc.)) before failing identically. So either your yaboot has some local
>  modifications that should go upstream, or your yaboot.conf is different? 
James, given that yaboot 1.3.17 is available, does it make sense to
update the online bootloader to that (so the get bootloaders script
snags that instead?) Additionally, it seems like it would be better for
the in-code reference to be just to '/yaboot' rather than
'/yaboot-1.3.14'.

AFAICT, no binary version of yaboot is stored wrt Cobbler except on the
fedorahosted site?

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc(a)us.ibm.com&gt;
IBM Linux Technology Center

[Bill Peck]

On 04/09/2012 03:08 PM, Nishanth Aravamudan wrote:
>  On 05.04.2012 [13:09:19 -0700], Nishanth Aravamudan wrote:
> > On 05.04.2012 [11:58:54 -0400], Bill Peck wrote:
> >> On 04/05/2012 11:26 AM, Nishanth Aravamudan wrote:
> >>> On 04.04.2012 [13:26:40 -0700], Nishanth Aravamudan wrote:
> >>>> On 28.03.2012 [18:40:09 -0500], James Cammarata wrote:
> >>>>> On Wed, Mar 28, 2012 at 11:24 AM, Nishanth Aravamudan
> >>>>> <nacc(a)linux.vnet.ibm.com&gt;   wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I encountered a rather annoying problem with cobbler for ppc64
> systems.
> >>>>>> The way these machines netboot is controlled by the SMS
> configuration,
> >>>>>> and if the SMS menu receives a DHCP response, even if it
> eventually
> >>>>>> fails, it will stay in an infinite loop within the netboot code.
> That
> >>>>>> code is not modifiable by me (owned by system firmware). What I
> >>>>>> encountered with Cobbler was that after an install succeeded, the
> DHCP
> >>>>>> configuration file was left alone. So the DHCP server would
> respond on
> >>>>>> the network on the next boot and the target server never booted
> from the
> >>>>>> disk.
> >>>>>>
> >>>>>> I worked around this by only generating the DHCP configuration if
> a
> >>>>>> system does have netboot_enabled set and re-generating the DHCP
> files
> >>>>>> via sync() whenever disable_netboot() is called.
> >>>>>>
> >>>>>> Signed-off-by: Nishanth Aravamudan&lt;nacc(a)us.ibm.com&gt;
> >>>>>>
> >>>>>> diff --git a/cobbler/modules/manage_isc.py
> b/cobbler/modules/manage_isc.py
> >>>>>> index b8f857f..8681d94 100644
> >>>>>> --- a/cobbler/modules/manage_isc.py
> >>>>>> +++ b/cobbler/modules/manage_isc.py
> >>>>>> @@ -161,6 +161,9 @@ class IscManager:
> >>>>>>                  interface["owner"] =
> blended_system["name"]
> >>>>>>                  interface["enable_gpxe"] =
> blended_system["enable_gpxe"]
> >>>>>>
> >>>>>> +                if not interface["netboot_enabled"]:
> >>>>>> +                    continue
> >>>>>> +
> >>>>>>                  interface["filename"] =
> "/pxelinux.0"
> >>>>>>                  # can't use pxelinux.0 anymore
> >>>>>>                  if distro is not None:
> >>>>>> diff --git a/cobbler/remote.py b/cobbler/remote.py
> >>>>>> index 0035e34..28cf180 100644
> >>>>>> --- a/cobbler/remote.py
> >>>>>> +++ b/cobbler/remote.py
> >>>>>> @@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
> >>>>>>          obj.set_netboot_enabled(0)
> >>>>>>          # disabling triggers and sync to make this extremely
> fast.
> >>>>>>         
> systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
> >>>>>> +        # re-generate dhcp configuration
> >>>>>> +        self.api.sync()
> >>>>>>          return True
> >>>>>>
> >>>>>>      def upload_log_data(self, sys_name, file, size, offset,
> data, token=None,**rest):
> >>>>>>
> >>>>>> --
> >>>>> Does this still happen if you use the cobbler trigger to set
> >>>>> netboot-enabled to false? Not sure if that's a valid option for
> >>>>> whatever OS you're building or not but take a look at the
> >>>>> kickstart_done snippet.
> >>>> I'm not sure I understand entirely. I have 'pxe_just_once'
> set to 1 in
> >>>> my /etc/cobbler/settings, and that does nicely unset the netboot enabled
> >>>> flag for the systems that are net-installed. However, the problem I saw
> >>>> (and I can try and test without my changes to re-confirm this) is that
> >>>> the DHCP server is still configured to respond over the network when
> >>>> this flag is changed (by default), so the netbooting machine gets a DHCP
> >>>> response, but the netboot environment no longer exists, and we fail. But
> >>>> system firmware is so dumb in this instnace that it just cycles there,
> >>>> rather than failing over ...
> >>> So on a P7 machine I'm testing on, here's what I see happen without
> my
> >>> changes. I netboot&   install FC16 and it works perfectly. The system
> >>> reboots after installation and the result on the console is:
> >>>
> >>> TFTP BOOT ---------------------------------------------------
> >>> Server IP.....................9.3.191.134
> >>> Client IP.....................9.3.192.206
> >>> Gateway IP....................9.3.192.1
> >>> Subnet Mask...................255.255.255.0
> >>> ( 1  ) Filename................./yaboot-1.3.14
> >>> TFTP Retries..................5
> >>> Block Size....................1024
> >>> FINAL PACKET COUNT = 194
> >>> FINAL FILE SIZE = 198376  BYTES
> >>>
> >>> Elapsed time since release of system processors: 39016 mins 13 secs
> >>>
> >>> ipv6 =<0>
> >>> siaddr =<9.3.191.134>
> >>> file =<>
> >>> ciaddr =<9.3.192.206>
> >>> giaddr =<9.3.192.1>
> >>> bootp_retries =<0>
> >>> tftp_retries =<5>
> >>> addl_params =<1024>
> >>> dhcpv6 =<<NULL>>
> >>> blksize =<<NULL>>
> >>> Try to netboot
> >>>
> >>>
> >>> TFTP BOOT ---------------------------------------------------
> >>> Server IP.....................9.3.191.134
> >>> Client IP.....................9.3.192.206
> >>> Gateway IP....................9.3.192.1
> >>> Subnet Mask...................255.255.255.0
> >>> ( 1  ) Filename.................\etc\01-82-5c-6d-80-0a-04
> >>> TFTP Retries..................5
> >>> Block Size....................1024
> >>> 1
> >>> 2
> >>> 3
> >>>          !BA017021 !
> >>>
> >>> Error, can't read config file
> >>>
> >>>
> >>>
> >>> TFTP BOOT ---------------------------------------------------
> >>> Server IP.....................9.3.191.134
> >>> Client IP.....................9.3.192.206
> >>> Gateway IP....................9.3.192.1
> >>> Subnet Mask...................255.255.255.0
> >>> ( 1  ) Filename.................\etc\yaboot.conf
> >>> TFTP Retries..................5
> >>> Block Size....................1024
> >>> 1
> >>> 2
> >>> 3
> >>>          !BA017021 !
> >>>
> >>> Error, can't read config file
> >>> Welcome to yaboot version 1.3.16
> >>> Enter "help" to get some basic usage information
> >>> boot:
> >>>
> >>> with no boot options available.
> >>>
> >>> So the problem is, as I mentioned earlier, that we respond over DHCP
> >>> with the yaboot binary itself, but there is no corresponding
> >>> configuration file and yaboot fails to work. Now, it would be nice if
> >>> yaboot could somehow fall back to the next OF boot device (in theory
> >>> this is available to yaboot to figure out). I will talk to Tony Breeds
> >>> about it and see if that's possible, but I think we still want to fix
> >>> this for current yaboot/cobbler installations.
> >> This is exactly what happens with the version of yaboot we are using.
> >>
> >> I need to ask around to find out who built this version of yaboot
> >> for us and where the source is.  Once I find this out I'll pass it
> >> along to the list.
> > Hrm, I just built yaboot 1.3.17 from the git tree, and it does the same
> > thing (although it tries more configuration files (MAC address prefixes,
> > etc.)) before failing identically. So either your yaboot has some local
> > modifications that should go upstream, or your yaboot.conf is different?
>  James, given that yaboot 1.3.17 is available, does it make sense to
>  update the online bootloader to that (so the get bootloaders script
>  snags that instead?) Additionally, it seems like it would be better for
>  the in-code reference to be just to '/yaboot' rather than
>  '/yaboot-1.3.14'.
>
>  AFAICT, no binary version of yaboot is stored wrt Cobbler except on the
>  fedorahosted site?
>
>  Thanks,
>  Nish
>  
The version of yaboot that redhat uses has additional patches that allow 
it to fallback to the local filesystem *if* the TFTPBOOT/etc/HEXIP file 
doesn't exist.

http://www.rpmseek.com/rpm/yaboot-1.3.14-27.fc12.src.html?hl=com&cx=8...:

I don't know which patch does this though..

[James Cammarata]

> > AFAICT, no binary version of yaboot is stored wrt Cobbler except
> on the
> > fedorahosted site?
> >
> > Thanks,
> > Nish
> >
>
>  The version of yaboot that redhat uses has additional patches that allow it
>  to fallback to the local filesystem *if* the TFTPBOOT/etc/HEXIP file doesn't
>  exist.
>
>
> http://www.rpmseek.com/rpm/yaboot-1.3.14-27.fc12.src.html?hl=com&cx=8...:
>
>  I don't know which patch does this though.. 
Regardless, it'd probably be a good idea to move all of the special
boot loaders to github and to modify cobbler to pull them from there
so we can update them easier.