bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: forwarded message from Thierry Laronde


From: tlaronde
Subject: Re: forwarded message from Thierry Laronde
Date: Mon, 28 Jul 2003 07:43:32 +0200 (MEST)
User-agent: IMP/PHP IMAP webmail program 2.2.42

En réponse à address@hidden:

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

To give some context : users using Windows 2000 were unable to start Windows
after installing GNU/Linux (Redhat) and since nobody wanted to give an answer
I tried to do it.

Second, the problem is at least clear here: since the distribution asked the
bootloader to start (for Windows) a partition numbered the way it is numbered
under Linux (matching the partition entry) it fails because GRUB numbers them
in increasing starting number.

Third, I have never said that CHS are relevant here since the size of the
partitions prevent the use of the legacy CHS access (via Int 13h).

Fourth, I have never seen neither examples given in an order (in the partition
table) distinct from the increasing sector number. The proof is that we had
never had ranked about such failure before, failure exhibited by the difference 
between different way the numbering was done.

There seems to be (user said) a "fixmbr" or so program that reoder the entries
in the partition table. This means that, as stupid as I may be, I'm not the
only one thinking that Windows declaring the partition in the 4th slot when 
nothing prevents it from putting itself in the first one is at least weird.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]