Re: Difficulty with netbooting - le0: lost carrier when bringing downthenetbsd kernel
Martin Trusler <[email protected]> Wed, 7 Jan 2026 07:28:49 +0000
| Newsgroups | gmane.os.netbsd.ports.hp300 |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-64EF97EE-8DC4-4AB1-B975-D928FB4E458E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike You might be able to load up NetBSD without a local boot server using the me= thod described on my website: https://www.hp-series300.net/setup.htm#S3 See the notes for installing NetBSD v9.2. I presume it will also work with v= 10. In any event, the NetBoot process for HP9000 series 300 uses RMP and not UDP= .=20 I hope this helps! J P Martin Trusler > On 7 Jan 2026, at 05:57, Mike Begley <[email protected]> wrote: >=20 > =EF=BB=BFWith the holidays in the rear view, I picked this project again l= ast night. I have not yet been successful. >=20 > To recap - I'm trying to netboot NetBSD 10 an 360 using a raspberry pi usi= ng the native OS. >=20 > This is my status: >=20 > Bootstrap loader to the HP: Success > bootp sending bootfile name to HP: Success > bootparamd sending filesystem info: Failure > tftp serving kernel, and then the rest of the fie system: Not there yet. >=20 > Question for the experts - is this the expected order? I'm pretty sure it= is, but sometimes I get the impression that tftp is step 3. >=20 > Using tcpdump I can see inbound traffic on port 111, but nothing outbound:= >=20 > 00:38:54.842747 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto U= DP (17), length 104) 192.168.2.123.1023 > 192.168.2.23.111: [no cksum] UDP, l= ength 76 > 00:38:54.842990 IP (tos 0x0, ttl 64, id 44675, offset 0, flags [DF], proto= UDP (17), length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp cksum 0= x8618 -> 0xf3b4!] UDP, length 28 > 00:38:54.957915 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto U= DP (17), length 104) 192.168.2.123.1023 > 192.168.2.23.111: [no cksum] UDP, l= ength 76 > 00:38:54.958142 IP (tos 0x0, ttl 64, id 44684, offset 0, flags [DF], proto= UDP (17), length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp cksum 0= x8618 -> 0x8a45!] UDP, length 28 > 00:42:22.776920 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto U= DP (17), length 104) 192.168.2.123.1023 > 192.168.2.23.111: [no cksum] UDP, l= ength 76 > 00:42:22.777302 IP (tos 0x0, ttl 64, id 58237, offset 0, flags [DF], proto= UDP (17), length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp cksum 0= x8618 -> 0xf3b4!] UDP, length 28 > 00:42:22.891684 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto U= DP (17), length 104) 192.168.2.123.1023 > 192.168.2.23.111: [no cksum] UDP, l= ength 76 > 00:42:22.891992 IP (tos 0x0, ttl 64, id 58254, offset 0, flags [DF], proto= UDP (17), length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp cksum 0= x8618 -> 0x8a45!] UDP, length 28 >=20 > I have been using ChatGPT as rubber ducky while I try to tease through thi= s, and it has been an interesting experience. Sometimes it'll help me have b= urst of insight, other times it will lead me down a terrible path. And some= times it outright lies. >=20 > Anyway, where I am at is that bootparamd simply refuses to respond to requ= ests, and seems to only listen on UDP, at least according to rpcbind. ChatG= PT claims that this is indicative that I'm using version 1 of bootparamd, wh= ich is incompatible with the HP300, and I need to find V2 sources and compil= e it. Does this sound reasonable, or completely nonsensical? I can't find a= ny real info about a bootparamd version 2 so I don't know if this is a fabri= cation. >=20 > Any ideas where to poke next, or what other config data might be helpful? >=20 > I am considering just putting NetBSD on the pi, since it seems many of you= have already done this successfully. >=20 > Thanks, > -mike >=20 >=20 >=20 > -----Original Message----- > From: Izumi Tsutsui <[email protected]> > Sent: Wednesday, December 24, 2025 5:46 AM > To: Mike Begley <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: Difficulty with netbooting - le0: lost carrier when bringing d= ownthenetbsd kernel >=20 > Hi, >=20 >> I'm not really a new user to HP300; I used NetBSD on a few HP9000/340s >> pretty heavily a few decades ago. I set up netbooting once way back >> for the experience/novelty, but pretty quickly figured out that >> running these machines diskless was pretty painful and SCSI disks were >> relatively plentiful. >=20 > Ah, got it. Welcome back to NetBSD/hp300! >=20 >> I was given this 360 many years ago (probably not a 362 as indicated >> earlier), but never put it to use and it sat in my closet (along with >> a stack of other hp300s) for many years. But I'm building a computer >> museum in my office at work, and I've decided I want to get this >> machine running as representative of Unix minicomputers of the day. >> Also, it seemed like a fun project. >=20 > Indeed, keeping old hp300s (and other machines in the closet) running the l= atest NetBSD has been a fun project for me, too ;-) >=20 >> Regarding carrier lost: >>=20 >> My 10base2 networking consists of a noname 10baseT hub connected via >> cat5 to the raspberry pi and a single 10base2 BNC port, a couple T's >> and terminators, and an approximately 1 meter long length of RG58. =20 >> And, of course, the 360 on one of the Ts. >=20 > I use a similar setup; a noname 10baseT hub with 10base2 BNC port and RG58= , to connect HP319 and other models with the System Interface Boards. >=20 >> I checked the resistance on the terminators and, although they say 50 >> ohms, read out at about 30 & 38 ohms. Not sure if that would be >> enough of a problem (also, do resistors decay over time?). >=20 > It can happen - old resistors can drift, especially if they have seen mois= ture/humidity. >=20 >> I may have a spare system interface board I could swap in, in case >> it's the onboard ethernet that's causing a problem. I can also check >> if there's an AUI port on either. >=20 > All of the System interface boards I have are only BNC, but I'm not sure w= hether there were AUI variants. >=20 >> I looked to see if there were any direct 10base2 to 10baseT gadgets >> out there, and the answer is...no really. >=20 > A 10baseT hub with a 10base2 BNC is a reasonable approach, I think. >=20 >> Regarding my server setup: >> I see that you say that the kernel is delivered via nfs. Does that >> mean there's no need for tftp at all? >=20 > You don't need TFTP for hp300 netboot. The boot ROM uses HP's RMP and talk= s to rbootd(8) to fetch the NetBSD's boot program (SYS_UBOOT). > Then the loaded SYS_UBOOT uses BOOTP to get IP addresses, mounts the NFS r= oot directory indicated by BOOTP, and load the kernel from there. >=20 > Some firmware on other workstations (certain Sun and SGI models) use TFTP t= o load bootloader after rarp/bootparam or bootp, but AFAICT most NetBSD's bo= otloaders use NFS to load a kernel (because our machine independent standalo= ne library for bootloaders just support both NFS and TFTP by default). >=20 >> Also. Regarding the network + nfs: >> I have an AUI port on my machine (in an expansion card), and when I >> use that rather than the I am able to successfully get to the point >> where it keeps asking over and over for the different netbsd kernels, >> over & over (as opposed to using thinnet, where it just hangs on the >> le0a carrier lost errors). Can I use the AUI port to deliver the >> kernel (and the rest of the filesystem) via nfs? >=20 > If that AUI port is on a supported Ethernet interface (and the AUI vs. thi= nnet selection is set correctly in hardware), it should work the same way - S= YS_UBOOT does't inherently require thinnet. >=20 >> ChatGPT claimed that the SYS_UBOOT bootstrap loader would only work on >> the thinnet network connection...but was it hallucinating on this? >=20 > AFAIK there is no software-configuable AUI/thin switch on hp300s. >=20 > All interfaces/models use hardware jumpers to switch them, so software in S= YS_UBOOT (and BOOT ROMs) don't get to choose which physical port. >=20 >> As an aside, ChatGPT suggested that Version D ROMs would allow the >> bootloader to select other LAN interfaces. Also, totally a >> hallucination? I believe I have Version C ROMs, by the way. >=20 > I suspect ChatGPT is mixing up different bits of information (e.g. "Boot R= OM Revision B or later support network boot" and/or old models that require s= ystem interface board don't have AUI ports, and such models have such old re= visions (C or prior)). >=20 >> Totally unrelated: >> I found in my stash a video board for which I have no idea what >> monitors it drives. It's not a bunch of BNC connectors, but a 9-pin >> connector. I don't have the model number on me right now, but when I >> looked for it on the intertubes I the only reference I could find >> referred to it as a monochrome graphics framebuffer. >> Does this right a bell for anyone? I wonder if this is used to >=20 > I think it's A1096A monochrome Hyperion (1280x1024, 1 bit). > I also have the one (donated from Miod Vallat) and even X.org > 1 bpp server should work on it (if your machine have enough RAMs): >=20 > https://x.com/tsutsuii/status/1337987154555768832 > https://x.com/tsutsuii/status/1338007445252161538 > https://x.com/tsutsuii/status/1338023590902390785 >=20 > It looks to use ordinary composite sync (like Sync on Green) so even moder= n LCD with SoG support (including recent most DELL LCD models; I'm using E17= 15S and P2314H etc.) can handle it. >=20 >> Thanks again, >=20 > No problem, thanks, > --- > Izumi Tsutsui --Apple-Mail-64EF97EE-8DC4-4AB1-B975-D928FB4E458E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html class=3D"apple-mail-supports-explicit-dark-mode"><head><meta http-equi= v=3D"content-type" content=3D"text/html; charset=3Dutf-8"></head><body dir=3D= "auto">Hi Mike<div>You might be able to load up NetBSD without a local boot s= erver using the method described on my website: <a href=3D"https://www.= hp-series300.net/setup.htm#S3">https://www.hp-series300.net/setup.htm#S3</a>= </div><div>See the notes for installing NetBSD v9.2. I presume it will also w= ork with v10.</div><div><br></div><div>In any event, the NetBoot process for= HP9000 series 300 uses RMP and not UDP. </div><div>I hope this helps!<= /div><div><br id=3D"lineBreakAtBeginningOfSignature"><div dir=3D"ltr"><div>J= P Martin Trusler</div></div><div dir=3D"ltr"><br><blockquote type=3D"cite">= On 7 Jan 2026, at 05:57, Mike Begley <[email protected]> wrote:<br><br></b= lockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<span>Wi= th the holidays in the rear view, I picked this project again last night. &n= bsp;I have not yet been successful.</span><br><span></span><br><span>To reca= p - I'm trying to netboot NetBSD 10 an 360 using a raspberry pi using the na= tive OS.</span><br><span></span><br><span>This is my status:</span><br><span= ></span><br><span>Bootstrap loader to the HP: Success</span><br><span>bootp s= ending bootfile name to HP: Success</span><br><span>bootparamd sending files= ystem info: Failure</span><br><span>tftp serving kernel, and then the rest o= f the fie system: Not there yet.</span><br><span></span><br><span>Question f= or the experts - is this the expected order? I'm pretty sure it is, bu= t sometimes I get the impression that tftp is step 3.</span><br><span></span= ><br><span>Using tcpdump I can see inbound traffic on port 111, but nothing o= utbound:</span><br><span></span><br><span>00:38:54.842747 IP (tos 0x0, ttl 6= 4, id 0, offset 0, flags [none], proto UDP (17), length 104) 192.168.2.123.1= 023 > 192.168.2.23.111: [no cksum] UDP, length 76</span><br><span>00:38:5= 4.842990 IP (tos 0x0, ttl 64, id 44675, offset 0, flags [DF], proto UDP (17)= , length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp cksum 0x8618= -> 0xf3b4!] UDP, length 28</span><br><span>00:38:54.957915 IP (tos 0x0, t= tl 64, id 0, offset 0, flags [none], proto UDP (17), length 104) 192.168.2.1= 23.1023 > 192.168.2.23.111: [no cksum] UDP, length 76</span><br><span>00:= 38:54.958142 IP (tos 0x0, ttl 64, id 44684, offset 0, flags [DF], proto UDP (= 17), length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp cksum 0x8= 618 -> 0x8a45!] UDP, length 28</span><br><span>00:42:22.776920 IP (tos 0x= 0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 104) 192.168= .2.123.1023 > 192.168.2.23.111: [no cksum] UDP, length 76</span><br><span= >00:42:22.777302 IP (tos 0x0, ttl 64, id 58237, offset 0, flags [DF], proto U= DP (17), length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp cksum= 0x8618 -> 0xf3b4!] UDP, length 28</span><br><span>00:42:22.891684 IP (to= s 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 104) 192= .168.2.123.1023 > 192.168.2.23.111: [no cksum] UDP, length 76</span><br><= span>00:42:22.891992 IP (tos 0x0, ttl 64, id 58254, offset 0, flags [DF], pr= oto UDP (17), length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp c= ksum 0x8618 -> 0x8a45!] UDP, length 28</span><br><span></span><br><span>I= have been using ChatGPT as rubber ducky while I try to tease through this, a= nd it has been an interesting experience. Sometimes it'll help me have= burst of insight, other times it will lead me down a terrible path. A= nd sometimes it outright lies.</span><br><span></span><br><span>Anyway, wher= e I am at is that bootparamd simply refuses to respond to requests, and seem= s to only listen on UDP, at least according to rpcbind. ChatGPT claims= that this is indicative that I'm using version 1 of bootparamd, which is in= compatible with the HP300, and I need to find V2 sources and compile it. &nb= sp;Does this sound reasonable, or completely nonsensical? I can't find= any real info about a bootparamd version 2 so I don't know if this is a fab= rication.</span><br><span></span><br><span>Any ideas where to poke next, or w= hat other config data might be helpful?</span><br><span></span><br><span>I a= m considering just putting NetBSD on the pi, since it seems many of you have= already done this successfully.</span><br><span></span><br><span>Thanks,</s= pan><br><span>-mike</span><br><span></span><br><span></span><br><span></span= ><br><span>-----Original Message-----</span><br><span>From: Izumi Tsutsui &l= t;[email protected]> </span><br><span>Sent: Wednesday, December 24,= 2025 5:46 AM</span><br><span>To: Mike Begley <[email protected]></span><b= r><span>Cc: [email protected]; [email protected]</span><br><span>S= ubject: Re: Difficulty with netbooting - le0: lost carrier when bringing dow= nthenetbsd kernel</span><br><span></span><br><span>Hi,</span><br><span></spa= n><br><blockquote type=3D"cite"><span>I'm not really a new user to HP300; I u= sed NetBSD on a few HP9000/340s </span><br></blockquote><blockquote type=3D"= cite"><span>pretty heavily a few decades ago. I set up netbooting once= way back </span><br></blockquote><blockquote type=3D"cite"><span>for the ex= perience/novelty, but pretty quickly figured out that </span><br></blockquot= e><blockquote type=3D"cite"><span>running these machines diskless was pretty= painful and SCSI disks were </span><br></blockquote><blockquote type=3D"cit= e"><span>relatively plentiful.</span><br></blockquote><span></span><br><span= >Ah, got it. Welcome back to NetBSD/hp300!</span><br><span></span><br><block= quote type=3D"cite"><span>I was given this 360 many years ago (probably not a= 362 as indicated </span><br></blockquote><blockquote type=3D"cite"><span>ea= rlier), but never put it to use and it sat in my closet (along with </span><= br></blockquote><blockquote type=3D"cite"><span>a stack of other hp300s) for= many years. But I'm building a computer </span><br></blockquote><bloc= kquote type=3D"cite"><span>museum in my office at work, and I've decided I w= ant to get this </span><br></blockquote><blockquote type=3D"cite"><span>mach= ine running as representative of Unix minicomputers of the day.</span><br></= blockquote><blockquote type=3D"cite"><span>Also, it seemed like a fun projec= t.</span><br></blockquote><span></span><br><span>Indeed, keeping old hp300s (= and other machines in the closet) running the latest NetBSD has been a fun p= roject for me, too ;-)</span><br><span></span><br><blockquote type=3D"cite">= <span>Regarding carrier lost:</span><br></blockquote><blockquote type=3D"cit= e"><span></span><br></blockquote><blockquote type=3D"cite"><span>My 10base2 n= etworking consists of a noname 10baseT hub connected via </span><br></blockq= uote><blockquote type=3D"cite"><span>cat5 to the raspberry pi and a single 1= 0base2 BNC port, a couple T's </span><br></blockquote><blockquote type=3D"ci= te"><span>and terminators, and an approximately 1 meter long length of RG58.= </span><br></blockquote><blockquote type=3D"cite"><span>And, of cours= e, the 360 on one of the Ts.</span><br></blockquote><span></span><br><span>I= use a similar setup; a noname 10baseT hub with 10base2 BNC port and RG58, t= o connect HP319 and other models with the System Interface Boards.</span><br= ><span></span><br><blockquote type=3D"cite"><span>I checked the resistance o= n the terminators and, although they say 50 </span><br></blockquote><blockqu= ote type=3D"cite"><span>ohms, read out at about 30 & 38 ohms. Not s= ure if that would be </span><br></blockquote><blockquote type=3D"cite"><span= >enough of a problem (also, do resistors decay over time?).</span><br></bloc= kquote><span></span><br><span>It can happen - old resistors can drift, espec= ially if they have seen moisture/humidity.</span><br><span></span><br><block= quote type=3D"cite"><span>I may have a spare system interface board I could s= wap in, in case </span><br></blockquote><blockquote type=3D"cite"><span>it's= the onboard ethernet that's causing a problem. I can also check </spa= n><br></blockquote><blockquote type=3D"cite"><span>if there's an AUI port on= either.</span><br></blockquote><span></span><br><span>All of the System int= erface boards I have are only BNC, but I'm not sure whether there were AUI v= ariants.</span><br><span></span><br><blockquote type=3D"cite"><span>I looked= to see if there were any direct 10base2 to 10baseT gadgets </span><br></blo= ckquote><blockquote type=3D"cite"><span>out there, and the answer is...no re= ally.</span><br></blockquote><span></span><br><span>A 10baseT hub with a 10b= ase2 BNC is a reasonable approach, I think.</span><br><span></span><br><bloc= kquote type=3D"cite"><span>Regarding my server setup:</span><br></blockquote= ><blockquote type=3D"cite"><span>I see that you say that the kernel is deliv= ered via nfs. Does that </span><br></blockquote><blockquote type=3D"ci= te"><span>mean there's no need for tftp at all?</span><br></blockquote><span= ></span><br><span>You don't need TFTP for hp300 netboot. The boot ROM uses H= P's RMP and talks to rbootd(8) to fetch the NetBSD's boot program (SYS_UBOOT= ).</span><br><span>Then the loaded SYS_UBOOT uses BOOTP to get IP addresses,= mounts the NFS root directory indicated by BOOTP, and load the kernel from t= here.</span><br><span></span><br><span>Some firmware on other workstations (= certain Sun and SGI models) use TFTP to load bootloader after rarp/bootparam= or bootp, but AFAICT most NetBSD's bootloaders use NFS to load a kernel (be= cause our machine independent standalone library for bootloaders just s= upport both NFS and TFTP by default).</span><br><span></span><br><blockquote= type=3D"cite"><span>Also. Regarding the network + nfs:</span><br></blockquo= te><blockquote type=3D"cite"><span>I have an AUI port on my machine (in an e= xpansion card), and when I </span><br></blockquote><blockquote type=3D"cite"= ><span>use that rather than the I am able to successfully get to the point <= /span><br></blockquote><blockquote type=3D"cite"><span>where it keeps asking= over and over for the different netbsd kernels, </span><br></blockquote><bl= ockquote type=3D"cite"><span>over & over (as opposed to using thinnet, w= here it just hangs on the </span><br></blockquote><blockquote type=3D"cite">= <span>le0a carrier lost errors). Can I use the AUI port to deliver the= </span><br></blockquote><blockquote type=3D"cite"><span>kernel (and the res= t of the filesystem) via nfs?</span><br></blockquote><span></span><br><span>= If that AUI port is on a supported Ethernet interface (and the AUI vs. thinn= et selection is set correctly in hardware), it should work the same way - SY= S_UBOOT does't inherently require thinnet.</span><br><span></span><br><block= quote type=3D"cite"><span>ChatGPT claimed that the SYS_UBOOT bootstrap loade= r would only work on </span><br></blockquote><blockquote type=3D"cite"><span= >the thinnet network connection...but was it hallucinating on this?</span><b= r></blockquote><span></span><br><span>AFAIK there is no software-configuable= AUI/thin switch on hp300s.</span><br><span></span><br><span>All interfaces/= models use hardware jumpers to switch them, so software in SYS_UBOOT (and BO= OT ROMs) don't get to choose which physical port.</span><br><span></span><br= ><blockquote type=3D"cite"><span>As an aside, ChatGPT suggested that Version= D ROMs would allow the </span><br></blockquote><blockquote type=3D"cite"><s= pan>bootloader to select other LAN interfaces. Also, totally a </span>= <br></blockquote><blockquote type=3D"cite"><span>hallucination? I beli= eve I have Version C ROMs, by the way.</span><br></blockquote><span></span><= br><span>I suspect ChatGPT is mixing up different bits of information (e.g. "= Boot ROM Revision B or later support network boot" and/or old models that re= quire system interface board don't have AUI ports, and such models have such= old revisions (C or prior)).</span><br><span></span><br><blockquote type=3D= "cite"><span>Totally unrelated:</span><br></blockquote><blockquote type=3D"c= ite"><span>I found in my stash a video board for which I have no idea what <= /span><br></blockquote><blockquote type=3D"cite"><span>monitors it drives. &= nbsp;It's not a bunch of BNC connectors, but a 9-pin </span><br></blockquote= ><blockquote type=3D"cite"><span>connector. I don't have the model num= ber on me right now, but when I </span><br></blockquote><blockquote type=3D"= cite"><span>looked for it on the intertubes I the only reference I could fin= d </span><br></blockquote><blockquote type=3D"cite"><span>referred to it as a= monochrome graphics framebuffer.</span><br></blockquote><blockquote type=3D= "cite"><span>Does this right a bell for anyone? I wonder if this is us= ed to</span><br></blockquote><span></span><br><span>I think it's A1096A mono= chrome Hyperion (1280x1024, 1 bit).</span><br><span>I also have the one (don= ated from Miod Vallat) and even X.org</span><br><span>1 bpp server should wo= rk on it (if your machine have enough RAMs):</span><br><span></span><br><spa= n> https://x.com/tsutsuii/status/1337987154555768832</span><br><span> https:= //x.com/tsutsuii/status/1338007445252161538</span><br><span> https://x.com/t= sutsuii/status/1338023590902390785</span><br><span></span><br><span>It looks= to use ordinary composite sync (like Sync on Green) so even modern LCD with= SoG support (including recent most DELL LCD models; I'm using E1715S and P2= 314H etc.) can handle it.</span><br><span></span><br><blockquote type=3D"cit= e"><span>Thanks again,</span><br></blockquote><span></span><br><span>No prob= lem, thanks,</span><br><span>---</span><br><span>Izumi Tsutsui</span><br></d= iv></blockquote></div></body></html>= --Apple-Mail-64EF97EE-8DC4-4AB1-B975-D928FB4E458E--