>> right...the old cylinder/head/sector method.  and i believe the new
>> method is called logical block addressing.  the older method, if i'm
>> not mistaken limited you to booting from the first 500 megs.
>
>No, the old method is limited to 1024 cylinders, 255 heads and 63
>sectors/track (don't ask me why this isn't 256 heads and 64 sectors/track).
>This allows for slightly less than 8GB (to be exact, 16450560 sectors).

hmm...i think i'm thinking of the really old method which limited you
to 1024/16/64 or something thereabouts (possible fencepost error in my
thinking).

as to why it's 255 and not 256...the bios numbers things starting from
1 and 256 is a nine bit number.

>> fwiw - my bios offers "standard ide" and "enhanced ide".  given that
>> the laptop is about a month old, i'm guessing that it's gonna support
>> both.
>
>Hmm, from your dump and the problem you're having, I infer that your
>bios doesn't support the new method.  However, since all your partitions
>start below the 8GB limit, this isn't your problem.  See below.

hmm...that doesn't make me feel happy.  i bought the laptop less than
a month ago and it's supposed to be just about the top of the line
kind of thing.  granted...the bios doesn't say copyright 2000 or
anything, but it does mention 1999.

>> >The netbsd bootmanager (as well as the standard netbsd mbr, and the netbsd
>> >partition bootcode) does use the bios to read the kernel from disk, just as
>> >its linux/freebsd counterparts.  It does however try to use the newer method,
>> >it it determines that the old method wouldn't work.  Thus it is able to
>> >boot from partitions beyond the 8GB limit.
>> 
>> um...do you perhaps have those to slightly backwards there?  :)
>
>Hmm, I'm not sure what you mean by backwards.  All netbsd bootcodes try
>the newer method to access the disk, if the bios claims to support it.

i just thought it sounded funny that it would try the newer method if
the older method didn't work.  i would have expected that to be the
other way around...

>(The standard netbsd mbr and the netbsd partition bootcode do additional
>checks to test whether it's really neccessary to use the new method or
>whether the old method will do, as it looks as though there are some
>bioses which get it wrong; with the bootmanager there isn't enough
>room for this however.)

sure.  makes sense.

>Now to your dumps:
>
>The numbers for the explicit cylinder/head/sector look quite odd, except
>for the start of the first partition.  The numbers for start and size
>look ok.

that's normal.  at least...that's what i expect and have always seen
on disks larger than ~500 megs.

>To fix it, start fdisk with the "-u" option on your disk.  Then during
>iteration through the partitions, answer "y" to the question "Do you
>want to change it? [n] ".  On all the questions for the partition data,
>simply accept the default values.  This should change the explicit
>cylinder/head/sector information.  Then accept the partition entries
>as ok, and at the end let it write back the new partition table.

okay...i'll try that later tonight.  but that'll just write the same
stuff back to the disk, no?

and it probes as:

   wd0: 11513 MB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 23579136 sectors

but those numbers don't multiply together very well.  the 23392 number
that i've got in my disklabel is what freebsd told me.

>After this procedure, you should be able to boot your machine again.

i'll give it a go.

>Don't ask me how those bogus values made their way into the mbr.
>I've got no idea (except that you might have entered them yourself,
>which I rather doubt).

the various operating systems i've installed put them there.  they
always did.

>FYI, to come back to the question whether your bios supports the newer
>method to access the disk, the new method would have used the start
>sector number, not the explicit begin cylinder/head/sector information.
>Since you are using the netbsd bootmanager, and that one always uses the
>new method to boot a partition, if that's available, it would have
>worked.  But since your bios doesn't support the new method, the
>bootmanager falls back to the old method, using those explicit numbers,
>and since they are bogus, it fails.

is there any way to test this, short of watching the boot manager fail
and guessing?  could i smack together a small assembly program that
tries to use this "new method" and see?  something that could test
things like this might be a "very good thing".

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."