Re: Partition 1 does not end on cylinder boundary
From: Rod Smith (rodsmith_at_nessus.rodsbooks.com)
Date: Fri, 9 Apr 2004 03:34:51 -0400
In article <firstname.lastname@example.org>,
email@example.com (P Gentry) writes:
> If you're partial to parted, you can use it also (and
> will likely see different CHS values than with fdisk).
I've never seen parted display CHS values; it just shows partition start
and end points expressed in kilobytes. Also, it seems to ignore the CHS
geometry on the disk and use its own, which can sometimes cause the sorts
of problems that the OP is seeing. I say this a bit tentatively, though; I
don't know precisely what parted does with CHS geometries. I do know I've
seen weirdness with it in this respect, though.
> CHS is a mythical holdover from ~10+ years ago. There is _no_
> standard way to calculate it or use it in CHS-to-LBA-to-CHS
> translations. The BIOS will do it one way, the disk controller
> another, Win disk utils another, and most all Linux utils do it
> differently from each other. Normally this is no problem since disk
> access is done via LBA and linear sector offsets/numbers. Formating a
> partition could be another story.
The real problems come when booting multiple OSs and when some of those
OSs use LBA and others use CHS. (DOS and at least some versions of Windows
9x/Me use CHS, for instance.) If the CHS geometries are inconsistent,
problems can ensue. Some disk tools (such as Partition Magic) will also
choke on such inconsistencies. Usually the result is that the program
becomes useless, but it's at least conceivable that some would end up
causing more problems when they try to fix the inconsistency.
> Word to the wise -- do _not_ mix MS and non-MS partitions in the
> extended partition!
> In an extended partition with non-MS table entries, a Win based disk
> util will likely as not trash your tables or actually _zero_ areas of
> a neighboring partition (especially during a format or partition
> deletion operation). Twice I've had 20-40 MBs zeroed on root! OUCH!
This hasn't been my experience. I've never had problems that I've been
able to trace to mixing Microsoft and non-Microsoft logical partitions in
a single extended partition, and I've done a lot of that sort of thing.
This is also the first I've ever seen this advice, although I have seen
claims about certain Microsoft OSs being unable to "see" FAT partitions
that come after non-FAT partitions. What I HAVE encountered are a couple
of more specific problems:
1) There can be issues depending on the type of extended partition and
its size; if the partition extends beyond the 1024th cylinder, you
should ensure that it's of type 0x0f rather than 0x05, particularly if
it has FAT-16 partitions that straddle or are beyond the 1024-cylinder
boundary. DOS and early versions of Windows are likely to flake out if
they see FAT partitions that fall partly or wholly beyond the 1024th
2) DOS/Windows FDISK can't "see" non-FAT logical partitions in an
extended partition. I've never seen FDISK overwrite or wipe out
such partitions, but I don't believe I've ever deliberately tried to
make that happen, either.
I suspect that the problems you encountered are related to #1, or
possibly #2 or a similar problem with some other utility. If so, IMHO
cautioning against any mixing of Microsoft and non-Microsoft logical
partitions is overly cautious. Certainly some configurations just are not
possible if you follow that advice.
> If you _must_ muck around with partitions on an existing dual boot
> installation, I highly recommend parted to fdisk or sfdisk
Ordinarily I have no qualms with parted, but given the fact that I've
seen it do odd things with CHS geometries, I'm a bit wary of using it on a
disk that's already displaying such problems. My hunch is that it might
just restore the original Linux CHS geometry, and when the OP goes to
install Windows again, it'll convert it back to its own values. That's
just a guess, though.
-- Rod Smith, firstname.lastname@example.org http://www.rodsbooks.com Author of books on Linux, FreeBSD, and networking