From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Strange boot behaviour Message-ID: <20040216112211.A10644@cackle.proxima.alt.za> References: <20040213081548.K4743@cackle.proxima.alt.za> <20040216083925.A10067@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20040216083925.A10067@cackle.proxima.alt.za>; from Lucio De Re on Mon, Feb 16, 2004 at 08:39:26AM +0200 Date: Mon, 16 Feb 2004 11:22:12 +0200 Topicbox-Message-UUID: e574e28e-eacc-11e9-9e20-41e7f4b1d025 On Mon, Feb 16, 2004 at 08:39:26AM +0200, Lucio De Re wrote: > On Sat, Feb 14, 2004 at 04:49:16PM -0500, David Presotto wrote: > > > > 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. > > > I did miss something: "connect to a root file system on another > machine". Will do now... > I missed something even more obvious: boot from: ether0!/386/9pcf.gz tickle (192.96.32.69!67): /386/9pcf.gz gz... 874346 => 867828+1146820+108996=2123644 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 19287 free pages, 77148K bytes, 309148K swap root is from (tcp, il, local)[local!#S/sd00/fossil]: local ^^^^^^^^ this is OK user[none]: lucio sd53c8xx: bios scntl3(00) stest2(00) sd53c8xx: bios scntl3(00) stest2(00) bopanic: boot process died: unknown ot: can't connect to file server: '#S/sdC0/' file does not exist ^^^^^^^^ this I overlooked pdumpstack anic: boot process died: unknown So I built a new kernel using pccpuf (my eventual target) with a modified boot line as /386/9pccpufs.gz. The effect was different, but disappointing: boot from: ether0!/386/9pccpufs.gz tickle (192.96.32.69!67): /386/9pccpufs.gz gz...870094 => 864947+1145560+142496=2153003 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 22495 free pages, 89980K bytes, 729980K swap root is from (tcp, il, local)[local!#S/sd00/fossil]: sd53c8xx: bios scntl3(00) stest2(00) sd53c8xx: bios scntl3(00) stest2(00) can't read nvram: i/o error authid: proxima authdom: proxima.alt.za secstore key: password: password: can't write key to nvram: fd out of range or not open Now it no longer complains about #S/sd00, but it still can't find the partitions. Wasn't there some mail about setting up the partitions early, a while back? I missed the importance of that thread at the time, I'll refresh my memory right now. Well, it looks to me like I need some adjustments to 9load to identify the partitions on a SCSI disk, as (a) 9load itself fails to find the partition table (but prep/fdisk succeed) and (b) that would explain why 9pcf gets similarly lost. I'll use Russ's part.c of 8 Nov '03 to do some testing. ++L