RE: Difficulty with netbooting - le0: lost carrier when bringing downthenetbsd kernel

[Mike Begley <spam%hell.org@localhost>]

With the holidays in the rear view, I picked this project again last night.  I have not yet been successful.

To recap - I'm trying to netboot NetBSD 10 an 360 using a raspberry pi using the native OS.

This is my status:

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.

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.

Using tcpdump I can see inbound traffic on port 111, but nothing outbound:

00:38:54.842747 IP (tos 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
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 0x8618 -> 0xf3b4!] UDP, length 28
00:38:54.957915 IP (tos 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
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 0x8618 -> 0x8a45!] UDP, length 28
00:42:22.776920 IP (tos 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
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 0x8618 -> 0xf3b4!] UDP, length 28
00:42:22.891684 IP (tos 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
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 0x8618 -> 0x8a45!] UDP, length 28

I have been using ChatGPT as rubber ducky while I try to tease through this, and 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.  And sometimes it outright lies.

Anyway, where I am at is that bootparamd simply refuses to respond to requests, and seems 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 incompatible with the HP300, and I need to find V2 sources and compile it.  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 fabrication.

Any ideas where to poke next, or what other config data might be helpful?

I am considering just putting NetBSD on the pi, since it seems many of you have already done this successfully.

Thanks,
-mike



-----Original Message-----
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> 
Sent: Wednesday, December 24, 2025 5:46 AM
To: Mike Begley <spam%hell.org@localhost>
Cc: port-hp300%NetBSD.org@localhost; tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: Difficulty with netbooting - le0: lost carrier when bringing downthenetbsd kernel

Hi,

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

Ah, got it. Welcome back to NetBSD/hp300!

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

Indeed, keeping old hp300s (and other machines in the closet) running the latest NetBSD has been a fun project for me, too ;-)

> Regarding carrier lost:
> 
> 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.  
> And, of course, the 360 on one of the Ts.

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.

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

It can happen - old resistors can drift, especially if they have seen moisture/humidity.

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

All of the System interface boards I have are only BNC, but I'm not sure whether there were AUI variants.

> I looked to see if there were any direct 10base2 to 10baseT gadgets 
> out there, and the answer is...no really.

A 10baseT hub with a 10base2 BNC is a reasonable approach, I think.

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

You don't need TFTP for hp300 netboot. The boot ROM uses HP's RMP and talks 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 root directory indicated by BOOTP, and load the kernel from there.

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 (because our machine independent standalone library for bootloaders  just support both NFS and TFTP by default).

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

If that AUI port is on a supported Ethernet interface (and the AUI vs. thinnet selection is set correctly in hardware), it should work the same way - SYS_UBOOT does't inherently require thinnet.

> ChatGPT claimed that the SYS_UBOOT bootstrap loader would only work on 
> the thinnet network connection...but was it hallucinating on this?

AFAIK there is no software-configuable AUI/thin switch on hp300s.

All interfaces/models use hardware jumpers to switch them, so software in SYS_UBOOT (and BOOT ROMs) don't get to choose which physical port.

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

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 require system interface board don't have AUI ports, and such models have such old revisions (C or prior)).

> 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

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):

 https://x.com/tsutsuii/status/1337987154555768832
 https://x.com/tsutsuii/status/1338007445252161538
 https://x.com/tsutsuii/status/1338023590902390785

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 P2314H etc.) can handle it.

> Thanks again,

No problem, thanks,
---
Izumi Tsutsui