From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7264eca72458d500639cb8fcb8c4ca79@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Strange boot behaviour In-Reply-To: <20040212154846.E4743@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 12 Feb 2004 09:35:59 -0500 Topicbox-Message-UUID: dfc54d10-eacc-11e9-9e20-41e7f4b1d025 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.