Hi,

as reported earlier, my 7600 macppc can no longer boot from the
NetBSD SCSI drive after my G3 processor upgrade (I wish I knew why
-- all it says is "RESETint SCSI bus" followd by "can't OPEN:
scsi-int/sd@1:0"), so I've been booting the kernel from the floppy
drive for a while.  Well, it now seems that the floppy drive has
croaked on me, and it's no longer able to boot from diskette (all I
get is "READ TIMEOUT").

I checked the price for a new floppy drive, and, well, "it's not
PC prices" (they wanted 1350 NOK -- more than 140 USD -- eww).

So, today I tried to boot via the network, and I'm encountering
some of the lossage that's been reported earlier on this list.

I have bootp, tftpd and NFS set up, and I can boot the ofwboot.xcf
(from the Oct 20 snapshot) file just fine using:

0 > boot enet enet:,netbsd.gz -a

(I think I could have managed to get the same effect using just
"boot enet -a".)  To this, OFW responded:

file: 129.241.196.118,/ofwboot.xcfloading XCOFF
tsize=BF40 dsize=1490 bsize=2620 entry=600000 
SECTIONS:
.text    00600000 00600000 0000BF40 000000E0
.data    0060C000 0060C000 00001490 0000C020
.bss     0060D490 0060D490 00002620 00000000
loading .text, done..
loading .data, done..
clearing .bss, done..

>> NetBSD/macppc OpenFirmware Boot, Revision 1.3
>> (root@fkmac26.phc.chalmers.se, Fri Oct 20 08:49:41 CEST 2000)
Boot: 

I typed in "netbsd.gz -a", and it came back:

no active packagefile: 129.241.196.118,
TFTP timeout
TFTP timeout
TFTP timeout

which looks depressingly similar to what others have reported
earlier.  A tcpdump of the mac's ethernet address on the boot server
(a hp300) shows:

14:44:34.833917 129.241.196.117.4280 > 129.241.196.118.62869: udp 4
14:44:34.834701 129.241.196.118.62869 > 129.241.196.117.4280: udp 516
14:44:34.836025 129.241.196.117.4280 > 129.241.196.118.62869: udp 4
14:44:34.836729 129.241.196.118.62869 > 129.241.196.117.4280: udp 180
14:44:34.837481 129.241.196.117.4280 > 129.241.196.118.62869: udp 4
14:44:34.843565 129.241.196.117.4280 > 129.241.196.118.62869: udp 4

This was the end of ofwboot.xcf loading.

14:44:51.442161 129.241.196.117.4285 > 129.241.196.118.69: 10 RRQ ""
14:44:51.748165 129.241.196.118.62868 > 129.241.196.117.4285: udp 19

Whee, doing TFTP again, and it's downhill from here...

14:44:56.445681 129.241.196.117.4286 > 129.241.196.118.69: 10 RRQ ""
14:44:56.588805 arp reply 129.241.196.117 is-at 0:a0:40:35:3e:fc
14:44:56.718845 129.241.196.106 > 129.241.196.117: icmp: redirect 129.241.196.118 to host 129.241.196.118
14:44:56.757185 129.241.196.118.62867 > 129.241.196.117.4286: udp 19
14:45:01.449613 129.241.196.117.4287 > 129.241.196.118.69: 10 RRQ ""
14:45:01.769309 129.241.196.118.62865 > 129.241.196.117.4287: udp 19
14:45:01.838033 129.241.196.106 > 129.241.196.117: icmp: redirect 129.241.196.118 to host 129.241.196.118
14:45:06.453545 129.241.196.117.4288 > 129.241.196.118.69: 10 RRQ ""
14:45:06.628181 129.241.196.106 > 129.241.196.117: icmp: redirect 129.241.196.118 to host 129.241.196.118

I read from the earlier discussion that ofwboot.xcf is supposed to
use NFS to load the kernel.  Quite clearly that is not happening,
and for some reason it falls back to an attempt at loading a file
using TFTP.

I note as a difference to what others have reported that I have this
"no active package" error message printed right after I type in the
kernel file name.  I wonder if that can be an error message caused
by ofwboot.xcf's use of OF primitives, and that this causes the NFS
boot to fail (no, I've not looked at the source code quite yet).

What's particularly irksome is that I've signed up to do the build
for 1.4.3, but I'm currently left with a non-booting machine...

Assistance to fix this netboot problem would be much appreciated.  I
can easily test new versions of ofwboot.xcf.

Best regards,

- Havard