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

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 usin=
g 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 UD=
P (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 UD=
P (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 UD=
P (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 UD=
P (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 so=
metimes it outright lies.

Anyway, where I am at is that bootparamd simply refuses to respond to reque=
sts, 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, w=
hich is incompatible with the HP300, and I need to find V2 sources and comp=
ile it.  Does this sound reasonable, or completely nonsensical?  I can't fi=
nd 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 <[email protected]>=20
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

Hi,

> I'm not really a new user to HP300; I used NetBSD on a few HP9000/340s=20
> pretty heavily a few decades ago.  I set up netbooting once way back=20
> for the experience/novelty, but pretty quickly figured out that=20
> running these machines diskless was pretty painful and SCSI disks were=20
> relatively plentiful.

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

> I was given this 360 many years ago (probably not a 362 as indicated=20
> earlier), but never put it to use and it sat in my closet (along with=20
> a stack of other hp300s) for many years.  But I'm building a computer=20
> museum in my office at work, and I've decided I want to get this=20
> 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 l=
atest NetBSD has been a fun project for me, too ;-)

> Regarding carrier lost:
>=20
> My 10base2 networking consists of a noname 10baseT hub connected via=20
> cat5 to the raspberry pi and a single 10base2 BNC port, a couple T's=20
> and terminators, and an approximately 1 meter long length of RG58. =20
> 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=20
> ohms, read out at about 30 & 38 ohms.  Not sure if that would be=20
> enough of a problem (also, do resistors decay over time?).

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

> I may have a spare system interface board I could swap in, in case=20
> it's the onboard ethernet that's causing a problem.  I can also check=20
> if there's an AUI port on either.

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

> I looked to see if there were any direct 10base2 to 10baseT gadgets=20
> 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=20
> 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 ro=
ot directory indicated by BOOTP, and load the kernel from there.

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 b=
ootloaders use NFS to load a kernel (because our machine independent standa=
lone 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=20
> use that rather than the I am able to successfully get to the point=20
> where it keeps asking over and over for the different netbsd kernels,=20
> over & over (as opposed to using thinnet, where it just hangs on the=20
> le0a carrier lost errors).  Can I use the AUI port to deliver the=20
> kernel (and the rest of the filesystem) via nfs?

If that AUI port is on a supported Ethernet interface (and the AUI vs. thin=
net 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=20
> 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 S=
YS_UBOOT (and BOOT ROMs) don't get to choose which physical port.

> As an aside, ChatGPT suggested that Version D ROMs would allow the=20
> bootloader to select other LAN interfaces.  Also, totally a=20
> hallucination?  I believe I have Version C ROMs, by the way.

I suspect ChatGPT is mixing up different bits of information (e.g. "Boot RO=
M 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=20
> monitors it drives.  It's not a bunch of BNC connectors, but a 9-pin=20
> connector.  I don't have the model number on me right now, but when I=20
> looked for it on the intertubes I the only reference I could find=20
> 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 E17=
15S and P2314H etc.) can handle it.

> Thanks again,

No problem, thanks,
---
Izumi Tsutsui