Re: [9fans] venti+fossil, the boot process, and 48-bit lba

[Charles Forsyth <forsyth@caldo.demon.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

i see. i'd wondered after i'd posted whether this might be it:

the kernel driver doesn't work out partitions on its own any more.
the devices' partition tables are set, for instance in /bin/termrc, by
disk/fdisk -p and disk/prep -p, into /dev/sd??/ctl, but that's not much help if you need the
file systems to get termrc (let alone fdisk or prep), and you need the partitions
to find the file system.  thus, boot adds the results of its own probe to the
internal copy of plan9.ini passed to the kernel, and so the partitions are
defined in time for boot to find them.

/sys/src/9/port/devsd.c has
		 * Use partitions passed from boot program,
		 *	sdC0part=dos 63 123123/plan9 123123 456456
		 * This happens before /boot sets hostname so the
		 * partitions will have the null-string for user.
		...

you could configure fdisk and prep into /boot, and have boot use them, but perhaps the
easiest change for you might be to stop 9load from checking the values (temporarily)
until something better is done.

[-- Attachment #2: Type: message/rfc822, Size: 3637 bytes --]

From: Christopher Nielsen <cnielsen@pobox.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] venti+fossil, the boot process, and 48-bit lba
Date: Wed, 22 Oct 2003 10:29:53 -0700
Message-ID: <20031022172953.GA834@cassie.foobarbaz.net>

On Wed, Oct 22, 2003 at 04:57:55PM +0100, Charles Forsyth wrote:
> >>and head-scratching, it turns out that 9load doesn't know how
> 	...
> >>As a result, when boot tries to start venti and venti
> >>tries to find the arenas, it all goes to hell.
>
> how does 9load cause that to happen?
> the thing that starts venti is a normal kernel, which
> should handle 48-bit LBA.  does 9load (not knowing
> about them) leave the ATA in a state where the kernel
> can't use 48-bits either?
>
> i can see that 9load not knowing 48-bit addressing wouldn't
> be able to see boot/9fat partitions beyond a certain point,
> or perhaps with the right geometry.

one more bit of information. when 9load detects the discs,
it says it can't add the partitions on the 167G drives
because the boundaries are out of range. the upper end of
the boundary that it prints is the upper end of 28-bit
addressing. that's why i concluded it had to do with 48-bit
lba.

this is transcribed by hand, but it looks something like
this:

cannot add sdF0!plan9 [63,351646785) to disk [0,268435455): partition boundaries out of range
cannot add sdF1!plan9 [63,351646785) to disk [0,268435455): partition boundaries out of range

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin