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

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

On Wed, 19 May 2004, Steve Langasek wrote:

> On Mon, May 17, 2004 at 07:58:26PM +0100, Gary Gale wrote:
> > > I'm sorry if I missed this in an earlier message; is there a reason you
> > > didn't try to boot the CD from SRM?  Is your CD not recognized as a boot
> > > device with your particular configuration?
> > Believe me when I say I'd love to be able to boot from SRM, but the 
> > version of the SRM firmware I have (which is the latest version) doesn't 
> > recognise my Adaptec AHA-294X SCSI controller; hence the root cause of the 
> > problem.
> > > If so, your best bet for a direct sarge install (given the lack of MILO
> > > and boot floppy support) might be to use the daily netboot images 
> > > available from <http://people.debian.org/~vorlon/d-i/images/daily/>.
> > OK - sounds like a plan. So 
> > http://people.debian.org/~vorlon/d-i/images/daily/dest/netboot/boot.img is 
> > 4.9 Mb, so that means a CD image. 

Hi Steve,

Progress, at least of sorts ...

> 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 wifi {
<snip ...>

        host x00366 {
<snip ...>

        host x00366-ether {
<snip ...>

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

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?



"There are two major products that came out of Berkeley; LSD and UNIX.
We don't believe this to be a coincidence."

BOFH Excuse #76: Unoptimised hard drive.

Linux, because eventually, you grow up enough to be trusted with a fork()

Reply to: