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?