Re: forwarded message from Thierry Laronde

[tlaronde]

En réponse à address@hidden:

And now about misinterpretation about my mail.

> 
> [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/ ?

Some "fdisk" programs (user can tell) spoke about Windows partition as the
"third slot", starting at 0, while others spoke about the 4th partition
(for example Linux).

>       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.

GRUB physically reorders nothing : it "numbers" the partitions in increasing
starting sector number (to be verified too but since the "4th partition" was
accessed via (hd0,1) it seems obvious), it logically reorders : it touches 
nothing on the partition table.

> 
> 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.

I know since all these partitions exceed the capacity of the CHS (int 13h) 
possibilities. I was speaking about the fake and useless CHS entries (the one
orginally designed to be passed directly to INT 13h) and was wondering if 
claiming the last head would enforce another numbering scheme.

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

Initially, after Redhat install the partition table was something like :

1 -> 3 in what order? empty, extended, Linux
4 Windows

> 
>       > 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.

See above.
> 
>       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.

See above.

> 
>       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.

I speak about the CHS entries (parameter to INT 13h). Fortunately absolute 
sector and size are coded on 4 bytes each. But the "legacy" CHS entries are 
meaningless, and the partition can not start where it is said to start in
the cylinder/sector entry. Of course cylinder 2662 is correct, but this is
not accessible via INT 13h.

> 
>       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
>