Subject: Re: install via netboot install kernel problem
To: Maciej W. Rozycki <macro@ds2.pg.gda.pl>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 02/08/2000 09:52:51
In message <Pine.GSO.3.96.1000208181018.17834P-100000@delta.ds2.pg.gda.pl>
"Maciej W. Rozycki" writes:

> That would be strange -- it is an official way of booting DEC equipment,
>it has been documented everywhere and supposedly it was thoroughly tested.
>How are you sure it's a problem with a MOP client and not a server.  Given
>the mopd out there (I refer to version 2.5.3) is buggy as hell...

Uh, this was using the Ultrix 4.2a mopd and config tools, not the
OpenBSD-derived code.  Some PROM revisions on some models of 3100s at
Stanford would not MOP-boot large kernels.  (This was mop-booting
Stanford V-kernels, around 1992. I could try and find the internal manpages
I wrote then, if you really truly care).

> You should probably be able to MOP-boot via a DECnet router.  Of course
>the router would have to support it -- I'm not sure if one exists -- I'm

My recolletion is that MOP over Ethernet isn't routable: its an
end-node-only thing.  I could be wrong, but that's what I recall.

> In fact, I got tired of hardcoding the load and transfer addresses into
>mopd every time I compile an image with a different layout.  I'll be
>writing an ELF backend for mopd in a few days.  I'll send a patch here,
>when it's ready. 

Great, thanks for doing that.  But the code is still buggy, right?

> I think going ELF is the only reasonable solution as it gives us platform
>independence -- one can use a single server binary to supply images for
>MIPS, VAX or whatever; not sure of Alpha -- it seems the protocol does not
>support 64-bit addressing. 

ECOFF would be nice to have, since that's what the DECstation PROMs
support for tftp, and it may make life slightly easier for anyone
migrating from the DEC mop services (e.g., Ultrix bootservers;
I think Simon still uses those).

In a perfect world we'd TFTP-load a standalone bootloaer that got the
kernel via NFS from the diskless root. But we're not quite there yet.

>The current aout support does heavily depend
>on magic numbers which are system specific.  And the current support for
>DEC MOP images is a joke -- look at PMAX image macros, for example --
>different fields seem to overlap in an unresolveable way. 

I havent looked in years, sorry.