> Thanks! This didn't work for me with your distributed "netboot'
> because the TFTP server is not the NFS server. But once knowing
> how it works I could make an own "netboot", and the system
> is up and running now.

Does it require that the TFTP server be the same as the NFS server?  I
didn't think that our libsa had the requirement, but i'm not
completely familiar with the libsa code.


> It is still strange that "netboot" boots via network but not from disk.

Not really.  Practically speaking, it's Hard to construct boot device
names to be fed to the firware, so what the firmware provides as the
boot device is passed back to it.  (Note that it's not hard to
construct one instance of the boot device string, but to do so with
the necessary generality to support all the systems we support is, in
fact, hard.)


> The error message is "no vmunix module_list" (OSF1 4.0 bootblks).
> Perhaps such a thing can be faked?

Not easily.  it really wants to boot an ECOFF-format kernel.


> As I mentioned before, there is a problem with PCI probing. `dmesg`
> is appended below. Note that function 1 seems to be read properly.
> (should there be an off-by-1 error? -  but the existing devices are
> properly seen as function 0)

Interesting.  How old is your system's firmware?

If old, i'll say:

	Upgrade your firmware, this is a firmware bug.

If not old, i'll say:

	Can you build a new kernel?

	If so, note the cases in cia_pci.c to handle lossage on the
	EB164, and modify them so they apply to the AlphaStation
	[56]00 (kn20aa) as well.

Those hacks are workarounds for what I consider firmware bugs.
However, if the firware bugs are becoming the norm, rather than the
exception, then i'll expand them to include the kn20aa (and maybe add
similar ones for apecs- and lca-based systems).


cgd