Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!ukma!rex!samsung!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!kth.se!ugle.unit.no!hanche From: hanche@imf.unit.no (Harald Hanche-Olsen) Newsgroups: comp.sys.apollo Subject: Re: Problems booting diskless on Ethernet Message-ID: Date: 28 Feb 91 18:41:28 GMT References: <50081142.1bc5b@pisa.ifs.umich.edu> <5011bdff.20b6d@apollo.HP.COM> Sender: news@ugle.unit.no Organization: The Norwegian Institute of Technology, Trondheim, Norway. Lines: 68 In-Reply-To: vinoski@apollo.HP.COM's message of 27 Feb 91 19:03:00 GMT In article <5011bdff.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes: In article <50081142.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >In article , hanche@imf.unit.no (Harald Hanche-Olsen) writes: > Does anybody know anything about the protocol used when booting > diskless from another node? >The net read routine in the PROM is very simple-minded. It does no timeout/ >retransmission. That means that if you have trouble loading netboot, you >have to start over. I don't remember whether netboot (the thing that says >".......loaded xxx bytes" does much better, but you used to be able to get >it to retry by hitting the space bar. I tried the space bar and it doesn't help. >You can also read the stdout from netman (by running it in a pad, for >example) and it may tell you about problems it's having communicating with >the partner. I would recommend this. Like I said above, netboot has to run on bare hardware in a very tight memory space, so it doesn't handle errors too gracefully. The netman program, however, has the full power of the OS underneath it, so it can be a little more verbose about what it's doing. I tried this, with the following result: # /sys/net/netman NETMAN -- User level network server -- 1990/05/17 ----- Message received from node 9952 on 2/26/1991 at 5:03:54 PM. --- Sysboot Request from Node 9952 Rqst for file: "netboot". ----- Message received from node 9952 on 2/26/1991 at 5:03:55 PM. --- Load Range Request --- DOMAIN_OS (0:15) Rqst for file: "//mummi/sau8/DOMAIN_OS". ----- Message received from node 9952 on 2/26/1991 at 5:03:55 PM. --- Load Range Request --- DOMAIN_OS (16:31) Rqst for file: "//mummi/sau8/DOMAIN_OS". ( intervening messages excruciatingly boring, hence omitted ) ----- Message received from node 9952 on 2/26/1991 at 5:04:03 PM. --- Load Range Request --- DOMAIN_OS (160:175) Rqst for file: "//mummi/sau8/DOMAIN_OS". ==== And here it stopped. Meanwhile, on the screen of node 9952, something like ... 00004000 BYTES LOADED. ... 00008000, ... C000, 10000, 14000, 18000, 1C000, 20000, 24000, ... 00028000 BYTES LOADED. (Stuck at beginnng of next line) At this point I tried Jim's suggestion, and hit the space bar. No response on either node. I did some calculation on the above numbers: Netman reports load range as kilobytes, in decimal. After the next-to-last request has been honored, (144:159) we have loaded 160KB or 16#28000 bytes, as is last reported on 9952's screen. Then more pages are requested, but not one of them is received. Well, thanks for the help. I guess it's time to give the hardware a good shakedown... - Harald Hanche-Olsen Division of Mathematical Sciences The Norwegian Institute of Technology N-7034 Trondheim, NORWAY