From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Nielsen To: 9fans@cse.psu.edu Subject: Re: [9fans] venti+fossil, the boot process, and 48-bit lba Message-ID: <20031023021628.GH834@cassie.foobarbaz.net> References: <20031022172953.GA834@cassie.foobarbaz.net> <20031022195940.GD834@cassie.foobarbaz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031022195940.GD834@cassie.foobarbaz.net> User-Agent: Mutt/1.5.3i Date: Wed, 22 Oct 2003 19:16:28 -0700 Topicbox-Message-UUID: 780eeb9a-eacc-11e9-9e20-41e7f4b1d025 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 > > 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