Don't forget that Windows is essentially DOS. When you boot in
MS-DOS mode, you have the system that Windows bootstraps itself
with.
> If you know that no other fdisk-type program than DOS FDISK
> has ever touched the partition table, then probably partitions
> end at cylinder boundaries. But if for example Linux or SCO software
> has created partitions then there is no guarantee for this to be true.
Linux fdisk will only let you break these rules in expert mode.
> And even if only DOS FDISK has been used but the disk was moved
> between computers, or within one computer between SCSI controllers,
> it may be false.
Really?!?! I'd imagine the DOS MBR code uses the CHS locations of
partitions to determine where to find the boot sector. If what you
said is true, a hard disk that can bootstrap on one machine can't
on another.
I guess I should check if the DOS/Windows MBR uses LBA or CHS to
find the boot sector.
> It seems the hard disk's actual geometry, and the geometry as DOS
> sees it are two different things.
>
> There is no actual geometry.
Don't hard drives have a defined number of heads, and a defined number
of tracks per head, and sectors per track? Even if software can't
determine it, it is defined.
> Yes, if possible. But in a Linux context you'll find that most
> disks are unknown to the BIOS - many people only put their boot
> disk in the BIOS setup.
If the hard disk doesn't have a geometry defined by the BIOS, then
Linux can't get it. But then, DOS can't either. So what on earth
does DOS do, (assuming it's using CHS, not LBA)?
> The objections remain: (i) Many disks are not found in the BIOS setup.
> So the BIOS tells you nothing.
In this case, use the "normal" methods.
> (ii) It seems impossible in general
> to correlate the BIOS disk numbering with the Linux disk numbering.
> One could at boot time let the BIOS read each of the disks and
> compute a md5 checksum of the first 100 blocks of each disk, and
> afterwards let Linux read the disks and compute md5 checksums,
> and compare. For the disks that occur in the BIOS setup this should
> give a correlation with high confidence.
Could you use the v3.0 BIOS standard's interface and device
path, mentioned in Ralf Brown's intlist?
> But I have a much simpler solution for you.
> Assume that all disks always have 63 sectors/track and 255 heads.
> Your program will work well on all modern hardware.
I've had bug reports where users have had disks with < 255 heads.
> Or ask the Linux kernel for the geometry. It gives reasonable
> answers. You complained that these are not `right', but right
> is not well-defined, and they are in most cases right enough
> to enable LILO to boot.
Perhaps, but I'd also like DOS/Windows to boot. In this case,
`right' is defined as allows DOS to boot, and access the disk
properly. Linux uses the LBA entries in the partition table
only, so there's no issue for Linux.
> Or guess a geometry from the partition table.
What if it's a fresh disk, where the user installs Linux first?
> Or let a user specify the desired geometry explicitly.
How's the user supposed to know? I guess they can get it from
the BIOS, so this solution is usable, but a nicer one is
preferable.
> Geometry is a problem of the past. It does not exist anymore.
> DOS does not exist anymore. People use 25 GB disks where DOS
> can only use 500 MB without translations and 8 GB with translations.
> If it were easy to be perfectly DOS-compatible, yes, that would be
> good to achieve. But now that it turns out to be almost impossible
> it doesnt really matter much. And it is easy to achieve DOS
> compatibility in 95% of the cases.
I'm beginning to agree. With Win95, you can just use LBA partitions,
and Win95 ignores the CHS (I just tested it). If anyone's using
DOS still, then their computer is so ancient it won't have the new
BIOS stuff anyway, so it won't make a difference.
> In fact not only is geometry a thing of the past - the DOS-type
> partition table is going to die soon.
Why?
Anyway, it seems the solution is to always write out partition tables
with LBA partitions, not CHS. It seems we don't need to care about
aligning partitions to cylinder boundaries, so there's no need for
geometry at all, for Windows 95 and up.
*BUT*, does anyone know if the Win 95 LBA partition type was
introduced in the original release? If was 95 B that it was introduced,
then we could run into problems - I but there are a heap of systems
running the original Win 95. I have a horrible suspicion it was
introduced in 95 B, because the FAT16 LBA partition number is larger
than the FAT32 one, implying it was conceived afterwards (perhaps).
FAT32 was 95 B.
In which case the problem can't be so easily swept aside...
Andrew Clausen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/