Messages in this thread |  | | Date | Sat, 15 Jun 1996 18:00:39 -0700 (PDT) | From | Thomas E Zerucha <> | Subject | Re: My SCSI HD has 34 heads, not 255... |
| |
On Sat, 15 Jun 1996 Andries.Brouwer@cwi.nl wrote:
> > 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
|  |