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: <20031022195940.GD834@cassie.foobarbaz.net> References: <20031022172953.GA834@cassie.foobarbaz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Date: Wed, 22 Oct 2003 12:59:40 -0700 Topicbox-Message-UUID: 780a8424-eacc-11e9-9e20-41e7f4b1d025 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