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 > >>><n...@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<n...@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 <n...@us.ibm.com> IBM Linux Technology Center _______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
