[scyld-users] Beoboot failure

[Liaw, Andy]

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 at beowulf.org
[mailto:scyld-users-bounces at beowulf.org] On Behalf Of Gardner Pomper
Sent: Monday, January 30, 2006 6:58 PM
To: Donald Becker
Cc: scyld-users at 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 <becker at scyld.com <mailto:becker at scyld.com> >
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 <http://192.168.1.10>  / 255.255.255.0
<http://255.255.255.0> 
>   Server: 192.168.1.50 <http://192.168.1.50>   boot file
'/var/beowulf/boot.img'
>   BProc master 192.168.1.50 <http://192.168.1.50>  port 2223,
>   VMA server 192.168.1.50 <http://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 at scyld.com
<mailto:becker at scyld.com> 
Scyld Software                          Scyld Beowulf cluster systems
914 Bay Ridge Road, Suite 220           www.scyld.com <http://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