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.
Thanks,
Nish
--
Nishanth Aravamudan <nacc(a)us.ibm.com>
IBM Linux Technology Center