From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Strange boot behaviour In-Reply-To: <20040213081548.K4743@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-hfvsxdffzucumgfdubfduhsoid" Date: Sat, 14 Feb 2004 16:49:16 -0500 Topicbox-Message-UUID: e410e870-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-hfvsxdffzucumgfdubfduhsoid Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit You had two problems: 1) 9load told you Unknown boot device: sd00!9fat!9pcf i.e., it wasn't seeing the 9fat partition. 2) your booted kernel could not start from the partition root is from (tcp, il, local)[local!#S/sd00/fossil]: user[none]: glenda sd53c8xx: bios scntl3(00) stest2(00) boot: can't connect to file server: '#S/sd00/fossil' does not exist All I suggested was that you boot 9pcf off of the net, connect to a root file system on another machine, and then start from there to debug your problem, i.e., see if you could then see '#S/sd00/fossil' etc. You clearly did all the nice booting as your carets indicate: boot from: ether0!/386/9pcdisk.gz ^^^^^^^^^^^^^^^^^^^^^^ note network boot ... root is from (tcp, il, local)[local!#S/sd00/fossil]: il ^^^^^^^^^^^^ ^^ and network FS However you never got to the important part, i.e., to figure out why 9pcf couldn't see your disk. Why did you boot 9pcdisk instead of a 9pcf? We need to find out why 9pcf won't find your disk. Booting a kernel you already know works won't get you anywhere closer to the problem. You need to get a 9pcf working on your machine and then start trying to figure out what is wrong. --upas-hfvsxdffzucumgfdubfduhsoid Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Feb 13 01:17:30 EST 2004 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Fri Feb 13 01:17:27 EST 2004 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id D90131A09D; Fri, 13 Feb 2004 01:17:17 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 8F5811A093; Fri, 13 Feb 2004 01:17:12 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 5A74E1A07D; Fri, 13 Feb 2004 01:16:02 -0500 (EST) Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2D7D619BB7 for <9fans@cse.psu.edu>; Fri, 13 Feb 2004 01:15:57 -0500 (EST) Received: from cackle.proxima.alt.za (localhost [127.0.0.1]) by cackle.proxima.alt.za (8.12.8/8.12.3) with ESMTP id i1D6Fp0V020166 for <9fans@cse.psu.edu>; Fri, 13 Feb 2004 08:15:52 +0200 (SAST) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.12.8/8.12.3/Submit) id i1D6FpHH020165 for 9fans@cse.psu.edu; Fri, 13 Feb 2004 08:15:51 +0200 (SAST) From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Strange boot behaviour Message-ID: <20040213081548.K4743@cackle.proxima.alt.za> Mail-Followup-To: 9fans@cse.psu.edu References: <20040212154846.E4743@cackle.proxima.alt.za> <7264eca72458d500639cb8fcb8c4ca79@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <7264eca72458d500639cb8fcb8c4ca79@plan9.bell-labs.com>; from David Presotto on Thu, Feb 12, 2004 at 09:35:59AM -0500 Organization: Proxima Research & Development Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: lucio@proxima.alt.za List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Fri, 13 Feb 2004 08:15:48 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Level: On Thu, Feb 12, 2004 at 09:35:59AM -0500, David Presotto wrote: > > 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. > There is no 9pcf in 9fat, but the error message suggests that the "device" is unknown. New trace below. > > > > 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. > It isn't impossible, unless I'm misreading the new trace (appended below). It is extremely unlikely that the 9pcdisk and 9pcf kernels are significantly different because of something I did and I suppose supplying sources etc won't really help unless I supply the hardware too :-( > > I take it that this: > sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007 and the next one, I'm not sure which one was used. Maybe there's a problem with a twin controller? > 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. > 9pcf is loaded off the network, it turned out to be the easiest route. But I think you're asking something else, really. > 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. That explains. I was hoping it was a version with debug enabled, but that's not applicable. I'll do some homework. Here is the new boot trace, using 9pcdisk.gz instead of 9pcf.gz, annotated: ----- cut here ----- sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007 sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007 sd53c8xx: bios scntl3(70) stest2(00) sd53c8xx: bios scntl3(70) stest2(00) ether#0: elnk3: port 0x300 irq 11: 00A0244026C9 Unknown boot device: sd00!9fat!9pcf ^^^^^^^ I can put 9pcf on 9fat, if it helps Boot devices: fd0 ether0 boot from: ether0!/386/9pcdisk.gz ^^^^^^^^^^^^^^^^^^^^^^ note network boot tickle (192.96.32.69!67): /386/9pcdisk.gz gz...729520 => 867796+818960+108996=1795752 entry: 80100020 Plan 9 apicbase 0xFEE00100 cpu0: 501MHz GenuineIntel Celeron (cpuid: AX 0x0665 DX 0x183F9FF) ELCR: 1420 #l0: elnk3: 10Mbps port 0x300 irq 11: 00A0244026C9 sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007 sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007 #U/usb0: uhci: port 0xE400 irq 10 19335 free pages, 77340K bytes, 309340K swap root is from (tcp, il, local)[local!#S/sd00/fossil]: il ^^^^^^^^^^^^ ^^ and network FS user[none]: glenda sd53c8xx: bios scntl3(00) stest2(00) sd53c8xx: bios scntl3(00) stest2(00) version... !Adding key: dom=proxima.alt.za proto=p9sk1 user[glenda]: password: ! time... init: starting /bin/rc dossrv: serving #s/dos 9660srv 68: serving /srv/9660 ----- cut here ----- --upas-hfvsxdffzucumgfdubfduhsoid--