Re: [9fans] Strange boot behaviour

[David Presotto <presotto@closedmind.org>]

On Thu Feb 12 08:50:42 EST 2004, lucio@proxima.alt.za wrote:

> 1.  Why does 9load not pick up #S/sd00 as a valid boot location?  It
> only offers fd0 and ether0 as options.  Is the missing #S/
> significant?  If so, then the installation is faulty.

The #S isn't a problem.  9load doesn't know about # stuff.
Whatever is wrong, this isn't it.

>
> 2.  Why does the fossil kernel 9pcf.gz not find #S/sd00/fossil?  It
> was created by the installation procedure and 9pcdisk.gz is aware of
> it.  Hm, a missing "disk"?

So, if you load a 9pcf and a 9pcdisk both built from the same sources,
one can see #S/sd00/fossil and the other can't?  That should be
impossible.  I have no idea why that would be.

>
> Note that I have added the PCI IDs for the SCSI controller card to
> sd53c8xx.c and this was OK for the installation process.
>

I take it that this:
	sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
is your disk.  If so, both the 9pcf kernel and 9load found it.  They
just didn't find the partitions.  Can you boot 9pcf off of a
network file server and see if you can look at the device at
all?  Maybe its not sd00?  What partitions do you see.

This would be the easiest way to figure it all out.

> Lastly, 9loaddebug differs from 9load only in the absence of a -H3
> load option and two hash out commands.  It doesn't work, either,
> unless the -H3 is entered, in which case it is not different from
> 9load.  Is it worth keeping?
>

It's there so we have something to run acid over that is in a format
acid understands.  Acid doesn't do well with the -H3 format.