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

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

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;
>                 fixed-address;
>                 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?

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.

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?

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: