Re: Alpha PWS 433a and Adaptec AHA-294X Boot Blues
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 192.168.1.0 netmask 255.255.255.0 {
> > default-lease-time 604800;
> > max-lease-time 2592000;
> > option subnet-mask 255.255.255.0;
> > option broadcast-address 192.168.1.255;
> > option routers 192.168.1.200;
> > option domain-name-servers 192.168.1.1;
> > option domain-name "vicchi.org";
> >
> > allow bootp;
> > allow booting;
> >
> > host nemesis {
> > hardware ethernet 00:00:F8:75:52:20;
> > fixed-address 192.168.1.110;
> > 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 64.22.202.19;
> option routers 64.22.202.18;
> filename "alpha-netboot.img";
> next-server minbar;
> }
>
> > On the Alpha at the SRM console I've done the following
>
> > >>> show dev
> > dva0.0.0.0.1 DVA0
> > ewa0.0.0.3.0 EWA0 00-00-F8-75-52-20
> > pqa0.0.0.4.0 PQA0 PCI EIDE
> > pqb0.0.0.4.0 PQB0 PCI EIDE
> > >>> set ewa0_protocols bootp
> > >>> set ewa0_mode fast
> > >>> boot ewa0
> > (boot ewa0.0.0.3.0 -flags 0)
>
> > Trying BOOTP boot.
>
> > Brodcasting BOOTP Request...
> > ..file open failed for bootp/ewa0.0.0.3.0
> > 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 192.168.1.110 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 192.168.1.110 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 192.168.1.110 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.
Cheers
Gary
--
"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: