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?
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