Does anyone have any idea whether the Fsys.atapi driver uses the BIOS
to get the drive geometry?
It’s been observed that the BIOS doesn’t have to have lba48 support in
order for Fsys.atapi to work correctly with a drive > 137GB.
So one might logically infer something from that… but you’d have to
assume that it handles all situations by querying the drive rather
than using the BIOS… an assumption that i can’t guess as to the
likelihood of, since it’s not uncommon for a driver to fall back to
querying the drive when it fails to get the info it needs from the
BIOS.
What’s behind this question is that I am unable to boot a drive that i
made by copying all the files (using cp -R… ) from a QNX4 partition
on one drive to a (newly created) QNX4 partition on another drive.
I’ve also copied everything in a Neutrino partition from the old to
the new drive (all the partitions on the new drive being bigger).
I’ve had no problem getting Neutrino to boot in many different
permutations. I’m using the GRUB bootloader in a small DOS
partition. My partition table looks like:
Under QNX4:
OS Start End _Number Size Boot
name type Cylinder Cylinder Cylinders Blocks
- QNX ( 77) 0 999 1000 2048193 1000 MB *
- QNZ ( 79) 1000 2999 2000 4096512 2000 MB warning
- DOS4 ( 6) 3000 3127 128 262080 127 MB NO
- FAT32 ( 12) 3128 ***** ***** 71789760 35053 MB NO
Under Neutrino:
OS Start End Number Size Boot
name type Cylinder Cylinder Cylinders Blocks
- QNX 77 0 126 126 2048193 1000 MB *
- QNZ 79 127 381 254 4096512 2000 MB
- DOS4 6 382 397 15 262080 127 MB
- FAT32 12 398 4866 4468 71789760 35053 MB
From BIOS:
AUTO/NORMAL LBA LARGE
Cylinder 19166 4867 2395
Head 16 255 128
Sector 255 63 255
Capacity 40039 MB 40035 MB 40027 MB
I think the problem might have something to do with the difference in
geometry being seen by QNX4, Neutrino & the BIOS (all different).
I can’t understand, though, why QNX4 & Neutrino would have different
ideas about the drive geometry… unless one uses the BIOS and the
other queries the drive. I’m not sure even that would adequately
explain it, though.
I haven’t yet tried setting the BIOS drive parameters explicitly and
then re-diniting the filesystems and recopying (i also haven’t tried
going back to Fsys.eide, yet, either). There are so many permutations
that i’d like to get a clue rather than have to try them all.
I am able (using GRUB) to boot QNX4 from my 2nd drive
(/dev/hd1)… which (of course, since i’m using a standard .boot
image) mounts /dev/hd0t77. Everything works fine this way. But when
i tell GRUB to use the stage 2 qnx boot loader located in the first
QNX (type 77) partition, i get an endless string of dots… which i
presume means it can’t find the “.boot” file.
I’ve run chkfys on the drive and its fine. As you can see from above,
the first (77) partition is well within the first 1024 cylinders of
the drive.
I’m not sure what the stage 2 boot loader relies on in determining
drive geometry. But once i boot QNX4 from my 2nd drive (mounting
/dev/hd0t77) everything is fine, including the .boot file. So, my
deduction is that .boot is simply not readable by the stage 2 boot
loader. Could it be “geometry confusion” that is causing the loader
not to be able to find .boot?
Originally, my BIOS was set to AUTO for both drives (i’m not really
sure how that works) which causes it to display the same geometry
parameters as it does for NORMAL. I switched both to LBA (which shows
different parameters, as you can see above) but the behavior didn’t
change. I didn’t change to LBA and then re-dinit, recopy, though
(although i will try this).
My guess is that in order for the stage 2 boot loader to know where to
find .root it must embed some knowledge of its location at the time
that it is placed at the beginning of the partition (i’ve done this
using dinit (-f … <correct boot file>) both in QNX4 and Neutrino
and using dloader in Neutrino… then copying everything… always
with the same result).
So (assuming my guess is correct), is that position info embedded in
the stage 2 loader (telling where .boot is located) somehow geometry
dependent? If that’s possible then having that position information
embedded by a program that understands the geometry differently than
the stage 2 loader could be a problem (lot of surmise there).
I really wish i understood how it is possible for QNX4 and Neutrino to
have totally different ideas about the drive geometry. That might
shed some light on the problem. None of the disk drivers pass any
geometry parameters explicitly… as far as i know. I certainly
didn’t customize them to do this.