Re: forwarded message from Thierry Laronde

[Andries . Brouwer]

> saw this message on GRUB mailing list, and thought you might be interested

Thanks!

[I am missing the context, so react only to statements here.]

        > Disk /dev/sda: 255 heads, 63 sectors, 4427 cylinders
        > Units = cylinders of 16065 * 512 bytes
        > 
        >    Device Boot    Start       End    Blocks   Id  System
        > /dev/sda4   *         1      2257  18129321    7  HPFS/NTFS
        > 
        > Nr AF  Hd Sec  Cyl  Hd Sec  Cyl    Start     Size ID
        >  1 00   0   0    0   0   0    0        0        0 00
        >  2 00   0   0    0   0   0    0        0        0 00
        >  3 00   0   0    0   0   0    0        0        0 00
        >  4 80   1   1    0 254  63 1023       63 36258642 07

        Here we have the beginning of the explanation. When `fdisk' was
        referring to the partition `3' it was indeed referring to the 4th entry
s/3/4/ ?
        of the partition table, the 3 first being empty.

[Microsoft bashing and other ranting deleted]

        But when one installs another operating system the sole mean is to
        declare a partition in the legacy partition table, so creating
        partitions that will take the place of the empty ones. But the
        bootloader will reorder the partitions in sector increasing order that
        will not match the random numbering enforces by the first partition
        occupying the last slot in the partition.

Here someone is talking about a bootloader (grub?) that will reorder
the partitions in sector increasing order.

Some versions of some operating systems will become very unhappy
when partition table entries are moved between slots in the
partition table. A bootloader or fdisk-type program should never
do something like that without asking the user.

        The size of the Windows extended partition is more or less 18 GB.
        Windows leaves one cylinder at the beginning, and one cylinder at the
        end (the one referred by the 255th head).

No, the CHS entry here is meaningless.

        This is confirmed by the partition table after installing Linux and
        fixing the MBR.

"fixing"

        > Disk /dev/sda: 255 heads, 63 sectors, 4427 cylinders
        > Units = cylinders of 16065 * 512 bytes
        > 
        >    Device Boot    Start       End    Blocks   Id  System
        > /dev/sda2   *         1      2257  18129321    7  HPFS/NTFS
        > /dev/sda3          2258      2662   3253162+   5  Extended
        > /dev/sda4          2663      4427  14177362+  83  Linux
        > /dev/sda5          2258      2411   1236973+  83  Linux
        > /dev/sda6          2412      2662   2016126   82  Linux swap
        > 
        > Nr AF  Hd Sec  Cyl  Hd Sec  Cyl    Start     Size ID
        >  1 00   0   0    0   0   0    0        0        0 00
        >  2 80   1   1    0 254  63 1023       63 36258642 07
        >  3 00   0   1 1023 254  63 1023 36258705  6506325 05
        >  4 00 254  63 1023 254  63 1023 42765030 28354725 83
        >  5 00 254  63 1023 254  63 1023       63  2473947 83
        >  6 00 254  63 1023 254  63 1023       63  4032252 82

        Here we see that an extended partition has been created for Linux,
        since it was not possible to create primary ones due to the fact
        that Windows has managed to occupy already almost all the place
        in the legacy partition table leaving only head 0 plate, and
        head 255 plate.

No, the CHS values are meaningless. There are four primary slots,
one was taken, three were free.

        But here the view given is slightly different. 
        There is still an empty partition (the first one; so /dev/sda1 is
        discarded). But there is also a 4th one (tagged Linux that seems
        to be outside of the extended partition, that is a primary one!).

        # /sbin/sfdisk -l ./final-sda.mbr

        Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
           Device Boot Start     End   #cyls   #blocks   Id  System
        ./sda.mbr1          0       -       0         0    0  Empty
        ./sda.mbr2   *      0+   2256    2257- 18129321    7  HPFS/NTFS
        ./sda.mbr3       2257    2661     405   3253162+   5  Extended
        ./sda.mbr4       2662    4426    1765  14177362+  83  Linux

        So it's clear that :

        The mess has been produced by the way Windows puts itself in the last
        place just in order to occupy all the slots of the partition table.

No mess in sight. Windows did nothing wrong.

        Linux seems to number (to be verified) the partition in the order of
        the partition table

Yes.

(More precisely: The four primary partitions are always numbered,
and always numbered in table order.  The logical partitions are
numbered in chain order.  If the chain zigzags over the disk,
then chain order will differ from sector order.
Neither Linux nor DOS has any objection against zigzagging chains.)

        while GRUB seems to number them in the logical increasing sector
        number. This seems to be the correct way since it is NOT possible
        to access the first sector of the partition without chaining
        the sizes given for the partitions (it is clear that the primary
        Linux partition can not start where it claims it is;

Start at cylinder 2662, that is sector 42765030, yes, that is where
it starts.

        it would seem better for the Linux partition to claim the 255th head,

The author of this text mistakenly thinks that heads have any significance.

        So the problem is caused by Windows,

I have not yet seen any problem.
It was stated that Linux and Grub number partitions differently.
Well, that was probably a choice of the Grub authors.
Somewhat confusing for users.
But then, different Linux kernel versions can also number
partitions differently in complicated situations, especially
when subpartitions are present.

        So, for GRUB users, in order to access correctly the partitions
        you must have the numbers in sector increasing numbers.

        The solution for the distributions, at the moment, is probably
        to fix the MBR.

        There are probably reflexion to be conducted by people writing
        partitionning software, due to the fact that M$ is systematicly
        trying to break compatibility.

Oh, please, stop this nonsense.

Andries