From gardner at networknow.org Tue Jan 24 13:37:33 2006 From: gardner at networknow.org (Gardner Pomper) Date: Tue Nov 9 01:14:28 2010 Subject: [scyld-users] Python upgrade breaks admin tools Message-ID: <43D69E1D.3010507@networknow.org> Hi, I have Scyld version 29, and when I upgraded to python 2.4.2, all the admin scripts stopped working, so now I can't check my network card, etc. Anyone have any idea how to fix this? If I can't fix it, then how about a suggestion on how to avoid the problem after I re-install? Thanks, - Gardner From becker at scyld.com Tue Jan 24 14:00:49 2006 From: becker at scyld.com (Donald Becker) Date: Tue Nov 9 01:14:28 2010 Subject: [scyld-users] Python upgrade breaks admin tools In-Reply-To: <43D69E1D.3010507@networknow.org> Message-ID: On Tue, 24 Jan 2006, Gardner Pomper wrote: > I have Scyld version 29, and when I upgraded to python 2.4.2, all the > admin scripts stopped working, so now I can't check my network card, > etc. Anyone have any idea how to fix this? If I can't fix it, then how > about a suggestion on how to avoid the problem after I re-install? Which admin scripts? The only current Scyld-created tool that depends on Python is the Beostatus GUI. There are few old programs e.g. /usr/sbin/config2pxe that still use Python, but we avoid writing new ones in Perl/Python/Ruby for exactly this reason. -- Donald Becker becker@scyld.com Scyld Software Scyld Beowulf cluster systems 914 Bay Ridge Road, Suite 220 www.scyld.com Annapolis MD 21403 410-990-9993 From gardner at networknow.org Tue Jan 24 14:05:23 2006 From: gardner at networknow.org (Gardner Pomper) Date: Tue Nov 9 01:14:28 2010 Subject: [scyld-users] Python upgrade breaks admin tools In-Reply-To: References: <43D69E1D.3010507@networknow.org> Message-ID: <42d22dbf0601241405g3d2eb836oab1fa06568ab56ec@mail.gmail.com> Hi, These aren't Scyld created scripts, they are they regular admin scripts (I assume from the base system you are using; Red Hat Enterprise?). Things like the network-config script from the Start->System menu. - Gardner On 1/24/06, Donald Becker wrote: > > On Tue, 24 Jan 2006, Gardner Pomper wrote: > > > I have Scyld version 29, and when I upgraded to python 2.4.2, all the > > admin scripts stopped working, so now I can't check my network card, > > etc. Anyone have any idea how to fix this? If I can't fix it, then how > > about a suggestion on how to avoid the problem after I re-install? > > Which admin scripts? > > The only current Scyld-created tool that depends on Python is the > Beostatus GUI. There are few old programs e.g. /usr/sbin/config2pxe that > still use Python, but we avoid writing new ones in Perl/Python/Ruby for > exactly this reason. > > > -- > Donald Becker becker@scyld.com > Scyld Software Scyld Beowulf cluster systems > 914 Bay Ridge Road, Suite 220 www.scyld.com > Annapolis MD 21403 410-990-9993 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.scyld.com/pipermail/scyld-users/attachments/20060124/69955eed/attachment.html From paul.milligan at paulsson.com Wed Jan 25 18:46:39 2006 From: paul.milligan at paulsson.com (Paul Milligan) Date: Tue Nov 9 01:14:28 2010 Subject: [scyld-users] GFS and Scyld Message-ID: <43D8380F.6090507@paulsson.com> Donald, are there any plans on integrating the RedHat GFS system into Scyld? Or is Scyld going to stick with PVFS (version 1.6) as the cluster file system. Regards, Paul. ---------------- Paul A. Milligan Sr. Geophysicist. Paulsson Geophysical Services, Inc. (P/GSI) 1215 West Lambert Road Brea, CA 92821-2819 USA Office: 562-697-9711 ext. 108 Fax: 562-697-9773 From gardner at networknow.org Fri Jan 27 14:43:54 2006 From: gardner at networknow.org (Gardner Pomper) Date: Tue Nov 9 01:14:28 2010 Subject: [scyld-users] Beoboot failure Message-ID: <42d22dbf0601271443s715b835ybe5c19b4fb503e93@mail.gmail.com> Hi, I am trying to get my test Scyld cluster up. I have Scyld v29cz running on my head node, and I am trying to get one slave node booting from a CD. The slave finds the master, and is assigned an IP address, but it fails with the following error: Boot information received for interface eth0 from RARP: Assigned IP address: 192.168.1.10 / 255.255.255.0 Server: 192.168.1.50 boot file '/var/beowulf/boot.img' BProc master 192.168.1.50 port 2223, VMA server 192.168.1.50 port 1556, protocol tcp. boot: installing module "kmonte" connect: no route to host Boot image download failure: numerical result ouf of range I hope I got all this right, because it automatically clears the screen and reboots after 5 seconds and I haven't found a way to stop it. Help! Thanks, - Gardner -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.scyld.com/pipermail/scyld-users/attachments/20060127/b08aa4f6/attachment.html From becker at scyld.com Mon Jan 30 13:34:08 2006 From: becker at scyld.com (Donald Becker) Date: Tue Nov 9 01:14:28 2010 Subject: [scyld-users] Beoboot failure In-Reply-To: <42d22dbf0601271443s715b835ybe5c19b4fb503e93@mail.gmail.com> Message-ID: On Fri, 27 Jan 2006, Gardner Pomper wrote: > I am trying to get my test Scyld cluster up. I have Scyld v29cz running on > my head node, and I am trying to get one slave node booting from a CD. The > slave finds the master, and is assigned an IP address, but it fails with the > following error: What version are you using? Are you booting from the distribution CD, or an "iso image" created from Beosetup? Are you running on a x86_64 or IA32? > Boot information received for interface eth0 from RARP: > Assigned IP address: 192.168.1.10 / 255.255.255.0 > Server: 192.168.1.50 boot file '/var/beowulf/boot.img' > BProc master 192.168.1.50 port 2223, > VMA server 192.168.1.50 port 1556, protocol tcp. > boot: installing module "kmonte" > connect: no route to host > Boot image download failure: numerical result ouf of range Hmmm, this appears to be a routing problem. We have seen a similar problem once before in the quick-remaster case, where the old default route prevents a new route from being added, even though the interface was shut down. (This is a kernel routing bug that can be worked around by explicitly deleting the old default route.) > I hope I got all this right, because it automatically clears the screen and > reboots after 5 seconds and I haven't found a way to stop it. The parameter 'fatal_delay' should set that timeout, and the default is normally 120 seconds. The only five second delay is in Two Kernel Monte, and that shouldn't be called. (FYI: The TKM delay may changed with the 'bootmode' flags. The upper 8 bits specify the delay in seconds before switching kernels. This is pretty much useful only for debugging and developers, and isn't likely the delay here.) -- Donald Becker becker@scyld.com Scyld Software Scyld Beowulf cluster systems 914 Bay Ridge Road, Suite 220 www.scyld.com Annapolis MD 21403 410-990-9993 From gardner at networknow.org Mon Jan 30 15:57:43 2006 From: gardner at networknow.org (Gardner Pomper) Date: Tue Nov 9 01:14:28 2010 Subject: [scyld-users] Beoboot failure In-Reply-To: References: <42d22dbf0601271443s715b835ybe5c19b4fb503e93@mail.gmail.com> Message-ID: <42d22dbf0601301557t338c2551u802f5d50f9f82c76@mail.gmail.com> Hi, I am running v29cz of Scyld. Are you asking what version of beoboot? It is from an iso image created from beosetup. I am running 32 bit on a Intel Pentium M (is that x86_64 or IA32?) Where do I change the TKM delay? Is that on the master before I create the ISO image? Thanks! As you can tell, I am lost. - Gardner On 1/30/06, Donald Becker wrote: > > On Fri, 27 Jan 2006, Gardner Pomper wrote: > > > I am trying to get my test Scyld cluster up. I have Scyld v29cz running > on > > my head node, and I am trying to get one slave node booting from a CD. > The > > slave finds the master, and is assigned an IP address, but it fails with > the > > following error: > > What version are you using? > Are you booting from the distribution CD, or an "iso image" created from > Beosetup? > Are you running on a x86_64 or IA32? > > > Boot information received for interface eth0 from RARP: > > Assigned IP address: 192.168.1.10 / 255.255.255.0 > > Server: 192.168.1.50 boot file '/var/beowulf/boot.img' > > BProc master 192.168.1.50 port 2223, > > VMA server 192.168.1.50 port 1556, protocol tcp. > > boot: installing module "kmonte" > > connect: no route to host > > Boot image download failure: numerical result ouf of range > > Hmmm, this appears to be a routing problem. > > We have seen a similar problem once before in the quick-remaster case, > where the old default route prevents a new route from being added, even > though the interface was shut down. (This is a kernel routing bug that > can be worked around by explicitly deleting the old default route.) > > > I hope I got all this right, because it automatically clears the screen > and > > reboots after 5 seconds and I haven't found a way to stop it. > > The parameter 'fatal_delay' should set that timeout, and the default is > normally 120 seconds. The only five second delay is in Two Kernel Monte, > and that shouldn't be called. (FYI: The TKM delay may changed with the > 'bootmode' flags. The upper 8 bits specify the delay in seconds before > switching kernels. This is pretty much useful only for > debugging and developers, and isn't likely the delay here.) > > > > -- > Donald Becker becker@scyld.com > Scyld Software Scyld Beowulf cluster systems > 914 Bay Ridge Road, Suite 220 www.scyld.com > Annapolis MD 21403 410-990-9993 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.scyld.com/pipermail/scyld-users/attachments/20060130/569ee540/attachment.html From andy_liaw at merck.com Tue Jan 31 17:30:59 2006 From: andy_liaw at merck.com (Liaw, Andy) Date: Tue Nov 9 01:14:28 2010 Subject: [scyld-users] Beoboot failure Message-ID: <39B6DDB9048D0F4DAD42CB26AAFF0AFAFED7A0@usctmx1106.merck.com> Not that I know much, but the version should be 29czX, where "X" is something like 3 or 5 (I think 5 is the latest). Pentium M is essentially a Pentium 4, so definitely IA-32. The x86_64 is the AMD64 architecture (cloned by Intel as EMT64). (How did you end up with a mobile chip in a server, anyway?) Andy -----Original Message----- From: scyld-users-bounces@beowulf.org [mailto:scyld-users-bounces@beowulf.org] On Behalf Of Gardner Pomper Sent: Monday, January 30, 2006 6:58 PM To: Donald Becker Cc: scyld-users@beowulf.org Subject: Re: [scyld-users] Beoboot failure Hi, I am running v29cz of Scyld. Are you asking what version of beoboot? It is from an iso image created from beosetup. I am running 32 bit on a Intel Pentium M (is that x86_64 or IA32?) Where do I change the TKM delay? Is that on the master before I create the ISO image? Thanks! As you can tell, I am lost. - Gardner On 1/30/06, Donald Becker > wrote: On Fri, 27 Jan 2006, Gardner Pomper wrote: > I am trying to get my test Scyld cluster up. I have Scyld v29cz running on > my head node, and I am trying to get one slave node booting from a CD. The > slave finds the master, and is assigned an IP address, but it fails with the > following error: What version are you using? Are you booting from the distribution CD, or an "iso image" created from Beosetup? Are you running on a x86_64 or IA32? > Boot information received for interface eth0 from RARP: > Assigned IP address: 192.168.1.10 / 255.255.255.0 > Server: 192.168.1.50 boot file '/var/beowulf/boot.img' > BProc master 192.168.1.50 port 2223, > VMA server 192.168.1.50 port 1556, protocol tcp. > boot: installing module "kmonte" > connect: no route to host > Boot image download failure: numerical result ouf of range Hmmm, this appears to be a routing problem. We have seen a similar problem once before in the quick-remaster case, where the old default route prevents a new route from being added, even though the interface was shut down. (This is a kernel routing bug that can be worked around by explicitly deleting the old default route.) > I hope I got all this right, because it automatically clears the screen and > reboots after 5 seconds and I haven't found a way to stop it. The parameter 'fatal_delay' should set that timeout, and the default is normally 120 seconds. The only five second delay is in Two Kernel Monte, and that shouldn't be called. (FYI: The TKM delay may changed with the 'bootmode' flags. The upper 8 bits specify the delay in seconds before switching kernels. This is pretty much useful only for debugging and developers, and isn't likely the delay here.) -- Donald Becker becker@scyld.com Scyld Software Scyld Beowulf cluster systems 914 Bay Ridge Road, Suite 220 www.scyld.com Annapolis MD 21403 410-990-9993 ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.scyld.com/pipermail/scyld-users/attachments/20060131/a2c3b8b1/attachment.html