booting the T1000

booting the T1000

[Rene Rebe]

Hi all,

I gave the current Ubuntu boot image a try on a T1000. The file I got has this
md5sum:

49f61b1efbc662b4f12061a9571ac65b  boot.img

I used the existing arpd and hpa-tftpd setup to network boot that new box, but
the box does not appear to like loading the kerne image.

In a blog of someone working on the Ubuntu suport I found a note
about "problems with hpa-tftpd", so I tried iputils/tftpd and atftpd without
success. Note  that an Ultra30 booted the same image served from the
same daemons just fine.

This is what atftp logged:

Jun 29 09:21:22 g5 atftpd[7209]: Serving C0A80271 to 192.168.2.113:32768
Jun 29 09:21:27 g5 atftpd[7209]: timeout: retrying...
Jun 29 09:21:47 g5 last message repeated 4 times
Jun 29 09:21:52 g5 atftpd[7209]: client (192.168.2.113) not responding

Maybe someone can enlighten me which tftp server is compaible with
the Niagara boxes?

Thanks in advance,

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
            http://exactcode.de | http://t2-project.org | http://rebe.name
            +49 (0)30 / 255 897 45

Re: booting the T1000

[David Miller]

From: Rene Rebe <rene@exactcode.de>
Date: Thu, 29 Jun 2006 09:37:49 +0200

> In a blog of someone working on the Ubuntu suport I found a note
> about "problems with hpa-tftpd", so I tried iputils/tftpd and atftpd without
> success. Note  that an Ultra30 booted the same image served from the
> same daemons just fine.

iputils inetd doesn't work well with tftpd at all, it propagates the
non-blocking setting of the socket down to tftpd which is not expecting
this.

Use netkit-inetd and it should go fine.  That's what I'm using here.

Re: booting the T1000

[Rene Rebe]

Hi,

On Thursday 29 June 2006 11:04, David Miller wrote:
> From: Rene Rebe <rene@exactcode.de>
> Date: Thu, 29 Jun 2006 09:37:49 +0200
> 
> > In a blog of someone working on the Ubuntu suport I found a note
> > about "problems with hpa-tftpd", so I tried iputils/tftpd and atftpd without
> > success. Note  that an Ultra30 booted the same image served from the
> > same daemons just fine.
> 
> iputils inetd doesn't work well with tftpd at all, it propagates the
> non-blocking setting of the socket down to tftpd which is not expecting
> this.
> 
> Use netkit-inetd and it should go fine.  That's what I'm using here.

Thanks for this hints, switching to netkit-tftpd made the OBP tftp client
load the image ,-)

Yours,

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
            http://exactcode.de | http://t2-project.org | http://rebe.name
            +49 (0)30 / 255 897 45

Re: booting the T1000

[Tom 'spot' Callaway]

On Thu, 2006-06-29 at 09:37 +0200, Rene Rebe wrote:
> Hi all,
> 
> I gave the current Ubuntu boot image a try on a T1000. The file I got has this
> md5sum:
> 
> 49f61b1efbc662b4f12061a9571ac65b  boot.img
> 
> I used the existing arpd and hpa-tftpd setup to network boot that new box, but
> the box does not appear to like loading the kerne image.

Try this:

T2000 fails to net boot from a Linux tftp boot server 
ALOM issues a broadcast not the ip of the tftp server 
Introduced in OBP 4.17 as part of WANboot project 
Workaround is to force OBP to transmit an ip address:

setenv network-boot-arguments rarp,file=tftp://10.20.30.40

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

Re: booting the T1000

[David S. Miller]

From: "Tom 'spot' Callaway" <tcallawa@redhat.com>
Date: Thu, 29 Jun 2006 15:27:58 -0500

> Try this:

As you can see from my response and his acknowledgment, this
wasn't the problem he was running into.

The default inetd package in Ubuntu, from iputils, is simply buggy,
because it sets it's sockets to non-blocking and leaves that setting
on the socket when it passes the connection on to the real application
from inetd.  Applications expect the socket to be in blocking mode.
As a result, tftpd craps out because it unexpectedly gets -EAGAIN on a
read().

To be honest this is a horrible selection of a default inetd
implementation, netkit-inetd is probably what should be used instead.

Changing over to netkit-inetd fixes the problem.

Re: booting the T1000

[Tom 'spot' Callaway]

On Thu, 2006-06-29 at 13:45 -0700, David S. Miller wrote:
> From: "Tom 'spot' Callaway" <tcallawa@redhat.com>
> Date: Thu, 29 Jun 2006 15:27:58 -0500
> 
> > Try this:
> 
> As you can see from my response and his acknowledgment, this
> wasn't the problem he was running into.

I'm getting email out of order today, apologies. (I only now received
your message from 4:04 AM).

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

Re: booting the T1000

[Chris Newport]

David S. Miller wrote:

>The default inetd package in Ubuntu, from iputils, is simply buggy,
>because it sets it's sockets to non-blocking and leaves that setting
>on the socket when it passes the connection on to the real application
>from inetd.  Applications expect the socket to be in blocking mode.
>As a result, tftpd craps out because it unexpectedly gets -EAGAIN on a
>read().
>
>To be honest this is a horrible selection of a default inetd
>implementation, netkit-inetd is probably what should be used instead.
>
>  
>
Is this really the root of the issue ?.
For about the last 5 years I have suffered similar issues with tftpd in 
Slackware, Solaris, and NetBSD, all of which use different inetd 
implementations.

Running tftpd standalone has always fixed it.

I could be wrong, but there seem to be generic issues running tftpd via 
inetd, often only intermittently reproduceable. 

Re: booting the T1000

[David Miller]

From: Chris Newport <crn@netunix.com>
Date: Thu, 29 Jun 2006 22:37:08 +0100

> I could be wrong, but there seem to be generic issues running tftpd via 
> inetd, often only intermittently reproduceable. 

It reproduces only when tftpd is invoked from inetd before the client
sends out the first packet.

If inetd gets a non-blocking socket, it chokes on the first read()
when data is not available in the socket receive buffer.  If the
client is fast enough, or the tftpd server slow enough, this will
never happen.

That's why it might be intermittently reproducable.

Believe me, I traced this one down to the source :)