>
> Linux does not use CHS at all, so, except when booting or using
> fdisk it does not matter (for Linux) what geometry you invent.
>
All true, but fdisk and lilo are making the call and complain or give
strange results when the number returned by the call disagrees with
reality. And it does mater for other OSes on the same disk that any
information used to alter the disk structure be correct.
> : Which of my four systems should I run the FDISK on?
>
> Doesn't matter. It will run fine on all of them.
>
It will run fine. It will not format a partition where a subsequent run
will not get confused, and wouldn't work properly if I had a card where
the low level driver insisted that no disk could be larger than 1GB (my
disk is 1.6Gb - and the section of code that did the truncation has been
commented out since the problem originally came up - check out
ultrastor.c and wd7000.c).
> : Running the linux fdisk to create a
> : new linux partition anywhere else would destroy the DOS partition.
>
> I don't think so. (And `the' linux fdisk is undefined. There are several.)
>
If the dos driver or bios can't understand anything but X/32/64, and the
linux fdisk creates something with Y/63/255 dos won't find the boot sector
(It also happens across different DOS installs). DOS accesses disks with
CHS, Linux doesn't. But if you fdisk under linux, when you want to do
something under DOS, it had better have the same understanding of the CHS
setup, or if you fdisk under DOS with 63/255, an linux thinks it is 32/64
complaints will be seen, and any changes will likely destroy the partition
table.
> :: If you really need to use LILO or FDISK, they both provide options
> :: to handle this case. If you are just accessing file systems,
> :: where's the problem?
>
> : This functionality is not documented (for fdisk) in the manpage, nor
> : online.
>
> Hmm. For fdisk 3.04:
> ...
I have 2.1. Apparently RedHat is slightly behind. The problem originally
surfaced a few months ago.
For 2.1 and cfdisk, last time I tried them, the "disk geometery
automatically" simply meant calling the biosparam function via the sd
ioctl, and then complaining about all the wierd numbers (as the root
message of this thread had as an example) when it used what was returned.
>From all of this, my next effort might be to add the partition geometery
determination code from scsicam into the various flavors of fdisking
programs if they don't already implement it (but not overriding the
biosparam for new disks - only for prepartitioned disks). If all this
stuff is already there, the question will be moot after a few upgrade
cycles.
lilo 1.9 doesn't appear to have anything other than a call to the ioctl.
> No reason to use kernel patches as a substitute for reading the docs.
Unless reading the docs doesn't help because the utility is relying on the
kernel to provide correct information, isn't getting it, doesn't detect
it, and happily continues. The problem I ran into is that the KERNEL says
the disk is X/32/64, but it is really Y/63/255. fdisk (2.1) accepts it,
but displays messages about wierd mapping having failed to automatically
determine the correct geometery.
> Andries
zerucha@shell.portal.com ; finger zerucha@jobe.portal.com for PGP key