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 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 wifi {
<snip ...>
}
host x00366 {
<snip ...>
}
host x00366-ether {
<snip ...>
}
host nemesis {
hardware ethernet 00:00:F8:75:52:20;
fixed-address 192.168.1.110;
allow bootp;
allow booting;
filename "/tftpboot/boot.img";
}
}
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?
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: