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

[Christopher Nielsen <cnielsen@pobox.com>]

I modified 9load as Russ suggested. I cannot test it just yet,
but I will do so when I get home.

It was a very simple, one-line change that, should it work, will
suffice until a better solution is available.

On Wed, Oct 22, 2003 at 06:58:56PM +0100, Charles Forsyth wrote:
> 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.

> From: Christopher Nielsen <cnielsen@pobox.com>
> To: 9fans@cse.psu.edu
> Date: Wed, 22 Oct 2003 10:29:53 -0700
> Subject: Re: [9fans] venti+fossil, the boot process, and 48-bit lba
>
> 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


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