[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Alpha PWS 433a and Adaptec AHA-294X Boot Blues

One of the things I found useful when playing with TFTP is to get the tftp command line tools and see if you can load the file from the same host through tftp.

The two problems that gave me grief were directory locations, and permissions on the files. If you tell tftpd to run from a directory, I believe it basically chroot's itself in that directory. Thus /tftpboot becomes /tftpboot/tftpboot.

Depending on the variant of tftpd, it is possible to run it from the command line, thus preventing it from going into background mode. Do this and turn up the verbosity, and useful information will get spat out on the terminal it tftpd was started from.

If all else fails, packet sniffers come in handy as well.


Gary Gale wrote:

On Fri, 28 May 2004, Steve Langasek wrote:

On Thu, May 20, 2004 at 03:56:24PM +0100, Gary Gale wrote:

It is not a CD image, it is a netboot image.  That means you put it on a
tftp server located on a machine that has a network connection to your
alpha, and you tell SRM to boot from the network device: for tulip
cards, this is boot ewa0 -fl ""', and I recall that there is another
device name for the other ethernet chipsets that SRM supports for
netbooting but don't remember what that device name is.  (If in doubt,
"show dev" should show you whether there are SRM-recognized ethernet
cards as devices beginning with "e").  This is hoping that at least your
ethernet chip is supported from SRM, even if your SCSI chip isn't.

Right, where to start ...

I've got an existing Linux machine on my internal network which provides DNS and DHCP services to my group of boxes; this machine is called hyperion; the Alpha I'm trying to boot is called nemesis.

On hyperion, I've installed tftpd, which is configured to be invoked via xinetd. My /etc/xinet.d/tftp looks like this

service tftp
       socket_type             = dgram
       protocol                = udp
       wait                    = yes
       user                    = root
       server                  = /usr/sbin/in.tftpd
       server_args             = -l -s /tftpboot
       disable                 = no

I've placed the downloaded boot.img in /tftpboot and added the -l switch so that I'll get some logging output in syslog ... hopefully.

Seeing as I've already got DHCP serving my internal network, I've added a definition for the Alpha to /etc/dhcpd.conf, which looks like this (albeit slightly cut down; I've omitted other definitions for machines which shouldn't have any interest in this)

subnet netmask {
       default-lease-time 604800;
       max-lease-time 2592000;
       option subnet-mask;
       option broadcast-address;
       option routers;
       option domain-name-servers;
       option domain-name "vicchi.org";

       allow bootp;
       allow booting;

       host nemesis {
               hardware ethernet 00:00:F8:75:52:20;
               allow bootp;
               allow booting;
               filename "/tftpboot/boot.img";

For comparison, here are my /etc/dhcp3/dhcpd.conf settings:

host quetz {
  hardware ethernet 08:00:2B:E7:94:9B;
  fixed-address quetz.dodds.net;
  option broadcast-address;
  option routers;
  filename "alpha-netboot.img";
  next-server minbar;

On the Alpha at the SRM console I've done the following

show dev

dva0.	DVA0
ewa0.	EWA0	00-00-F8-75-52-20
pqa0.	PQA0		PCI EIDE
pqb0.	PQB0		PCI EIDE

set ewa0_protocols bootp
set ewa0_mode fast
boot ewa0

(boot ewa0. -flags 0)

Trying BOOTP boot.

Brodcasting BOOTP Request...
..file open failed for bootp/ewa0.
bootstrap failure

Retrying, type ^C to abort ...

From syslog on hyperion I can see the bootp requests being logged; I get three pairs of request/response logs for each attempt that the Alpha makes to net boot

May 20 15:40:55 hyperion dhcpd: BOOTREQUEST from 00:00:f8:75:52:20 via eth0 (non-rfc1048) May 20 15:40:55 hyperion dhcpd: BOOTREPLY for to nemesis (00:00:f8:75:52:20) via eth0 May 20 15:41:05 hyperion dhcpd: BOOTREQUEST from 00:00:f8:75:52:20 via eth0 (non-rfc1048) May 20 15:41:05 hyperion dhcpd: BOOTREPLY for to nemesis (00:00:f8:75:52:20) via eth0 May 20 15:50:31 hyperion dhcpd: BOOTREQUEST from 00:00:f8:75:52:20 via eth0 (non-rfc1048) May 20 15:50:31 hyperion dhcpd: BOOTREPLY for to nemesis (00:00:f8:75:52:20) via eth0

and that's it, I don't see any tftp activity logged and the Alpha seems blissfully unaware that it's being responded to.

From this, it seems that the Alpha is transmitting the bootp requests but it seems to be ignoring the replies. Which indicates some form of configuration error, probably on the part of the dhcpd.conf file (?), but after perusing the man pages and doing some Googling I can't see that I've omitted anything.

So once again, I'm stumped. Any ideas?

Apologies for not replying sooner on this; the last couple of weeks have been manic (to say the least) due to work pressures and a family crisis so this "project" has had to be put on the back burner for a while ...

Are you sure that your tftp server needs an absolute path for filenames
under /tftpboot?  Maybe just changing to "boot.img" for the filename
would do the trick.

No, I'm not 100% sure and the man page for my tftp server doesn't give any hints. Having said that, I've tried almost every path naming variant I could think of, but still got the same lack of results.

It could also be a problem with the alpha ignoring the bootp responses
as you say, in which case I fear I don't have any ideas how to fix it.
Perhaps a different dhcp server would work better?

I think I've got to make the assumption that the hardware's fine - I haven't seen anything to indicate otherwise - else I might as well give up now and I don't want this to beat me. Hey, call me stubborn!

Currently, both the dhcp server (dhcp-2.0p15-8) and the tftp server
(tftp-server-0.17-14) are hosted on a RHL 8.0 box.

I think my next plan of attack is to re-host them on one of my boxes running the latest version of Debian stable and re-try to see if there's any incompatibilities being introduced as a result of these "slightly old" versions.

If that doesn't work, then I think some packet sniffing might be in order to see whether there's any tftp traffic at all.

I'll keep you posted. I've said it before and I'll say it again. The level of support on this list is fantastic. I just hope that one day I'll be able to return the favour to someone else who's having a related (or not!) problem.



Reply to: