[rescue] Q about sun2 boot flow

[Todd Vernon]

Walter, I honestly don’t know the answer but was interested to see what AI (ChatGPT) would say.  No idea if it’s correct but sending along as it seems to reference Sun docs:

——

Walter’s missing piece is documented very explicitly in the SunOS 3.0 nd(4P) man page, and it’s a little different from the modern ndbootd mental model.

For the original SunOS ND boot, the sequence is:

1. The Sun-2 PROM reads blocks 1–15 of /dev/ndp0. Those blocks contain bootnd.
2. bootnd is not simply loading another fixed range of raw blocks. It understands enough of the Unix filesystem on the public ND device to find and load the file /boot.
3. /boot then understands the filesystem and loads /vmunix from that same public ND filesystem.
4. Once vmunix is executing, the kernel’s ND driver takes over and mounts its configured root, typically the client’s private ND partition such as nd0.

Sun’s own documentation literally describes it as:
PROM loads blocks 1 thru 15 of /dev/ndp0 (bootnd)
bootnd loads /boot
/boot loads /vmunix
So yes, there is effectively a third piece, if we’re calling the PROM-loaded bootnd stage 1. But /boot isn’t sitting at some predetermined ND block number after block 16. It’s an ordinary file in the filesystem contained on /dev/ndp0. bootnd reads the filesystem metadata over ND, locates /boot, and loads it. Then /boot similarly locates and loads /vmunix. The SunOS 3 reboot documentation also identifies /boot as the system bootstrap and /vmunix as the system image.
That’s the important distinction with NetBSD’s ndbootd. Modern ndbootd deliberately constructs a fake minimal ND disk:

• block 0: disk label-ish
• blocks 1–15: bootyy
• block 16 onward: netboot

It only exists to get far enough to switch to RARP/bootparams/NFS.
The original SunOS scheme instead expects /dev/ndp0 to be a real Sun filesystem exported block-for-block via ND. Thus the old path is essentially:
Sun-2 PROM
  |
  | ND raw block reads, ndp0
  v
blocks 1-15
  |
  v
bootnd
  |
  | ND reads of filesystem on ndp0
  v
/pub filesystem: /boot
  |
  | ND reads of filesystem on ndp0
  v
/pub filesystem: /vmunix
  |
  v
SunOS kernel
  |
  | kernel ND driver
  v
private ND root, e.g. nd0
And that also explains why Walter’s observation about ndd is important. ndbootd alone cannot reproduce the historical SunOS 1/2/3 boot environment, because the historical loader needs continued arbitrary block access to the actual public filesystem after the initial boot blocks. You need an ND implementation that exports the complete disk/partition image, which sounds like exactly what ndd can provide.
There’s an additional useful confirmation in Sun’s own description of ND: public devices /dev/ndp* were actual read-only filesystems containing shared /bin, /usr/bin, libraries, etc., not merely bootloader storage. The boot files normally came from /dev/ndp0.

So I think the answer to send Walter is essentially:
“Your assumption that stage 1 requests a stage-2 binary beginning at ND block 16 applies to ndbootd/NetBSD-style booting. Native SunOS 3.x doesn’t work that way. The PROM loads blocks 1–15 (bootnd) from /dev/ndp0; bootnd then interprets the filesystem on /dev/ndp0 and loads /boot; /boot loads /vmunix from that filesystem. The kernel subsequently mounts its configured ND root, e.g. nd0. Therefore to reproduce a native SunOS 1.x–3.x network boot, the server needs to export a genuine public ND filesystem, not merely serve the bootstrap blocks.”
That’s a pretty definitive answer. Sun’s 1985 nd(4P) documentation essentially answers his question word-for-word.

---
Todd Vernon
Entrepreneur | Investor
Email: todd at toddvernon.com
LinkedIn: toddvernon
On Sep 2, 2026 at 2:46 PM -0400, Walter Belgers via rescue <rescue at sunhelp.org>, wrote:
> Hi,
>
> I am trying to get a Sun 2 to boot from the network. Booting NetBSD or SunOS 4.0.3 is not a problem, it's your plain old rarp/tftp/nfs sequence but with ndbootd added for the stage1 and stage2 boot loaders.
>
> But, I'd like to netboot an older SunOS (1.x/2.x/3.x) using ND (network disk) and am trying to understand the boot process. As far as I understand, this happens:
>
> b ie() will send an ND request to "minor 0x40" (the public disk) for blocks 0~15, which are 512b blocks with 0 being a disk label and the rest making up stage 1 (which can be 7.5KB at most).
>
> Stage 1will then run and request blocks 16 and higher from ND minor 0x40 which is then run as stage 2.
>
> But.. what happens then? How does stage 2 boot the kernel? Is there a third stage boot loader in the boot blocks that is fetched via ND? Or does the kernel also come from ND minor 0x40? I am trying to figure this out by reading the code but I'm not a coder and could not figure this out :-/. I also asked Tom Lyon who AFAIK wrote ND but after 40 years his memory was a bit hazy ;-)
>
> Eventually, /dev/nd0 (or equivalent as stated in /etc/fstab) will be mounted as the root filesystem, which is again served via ND, but this can be on minor 0 (/dev/ndp == minor 0x40, /dev/nd0 == minor 0). Ndbootd only implements booting via minor 0x40 so cannot be used for this, but there's a tool ndd that can provide this functionality. Both can run together as they will ignore requests for the other minor.
>
> At one point I had a setup that used a 2nd stage bootloader that used NFS (yes, cheating) to mount the root filesystem and start a SunOS 3.2 kernel, which would then revert to using ND to bootstrap the system. (2nd stage: "root on nfs:/export/sunos/root fstype nfs", but kernel says "root on nd0" and act accordingly).
>
> I do know I could just run SunOS 4.0.3 and set up a boot service but I'd like to run the boot server on modern hardware (without cheating and using an emulator).
>
> Regards,
> Walter.
>
>
> _______________________________________________
> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sunhelp.org/pipermail/rescue_sunhelp.org/attachments/20260903/50a699a0/attachment.html>