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

[Christopher Nielsen <cnielsen@pobox.com>]

That didn't work. It shut up 9load about the partitions, but
venti still couldn't open the partition.

Unless someone has a better idea, I'm going to proceed with
incorporating fdisk and prep into /boot and teach boot to
use them to sniff out the partitions.

On Wed, Oct 22, 2003 at 12:59:40PM -0700, Christopher Nielsen wrote:
> 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

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