bug-grub
[Top][All Lists]
Advanced

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

Re: [synthesis] forwarded message from Thierry Laronde


From: Thierry Laronde
Subject: Re: [synthesis] forwarded message from Thierry Laronde
Date: Mon, 28 Jul 2003 13:30:45 +0200
User-agent: Mutt/1.0.1i

On Mon, Jul 28, 2003 at 08:22:23AM +0200, address@hidden wrote:

[all snipped]

I will try to be constructive and synthetize what has been my way of
searching, and pointing that, after some thought, my conclusion is wrong
: if, indeed, GRUB as it seems numbers the partition by increasing
sector number (adjacent partitions from beginning to end) it is the
problem for the reasons given below. But, if Windows has written the
very first entry and the very first lonely partition at the end of the
table it is too at least weird. Even `sfdisk' when run on the partition
table print a warning because the fake order is not respected.

Once I read the first post from the user, I retain "Problem booting;
non-matching numbering, and fix mbr". If something has to be fixed and
if there is a tool to do it (with the result that everything works
again) then this means that something is wrong with the MBR.

To number the partitions in increasing sector number seems at  first
sight logical. In the example given, when a user has one and only one
partition he may legitimaly think that this will be referred to as the
first one (/dev/sda1). To have 3 null partitions is weird.

But what I have missed is that the user may change the partitionning.
Suppose we have once created 3 primary partitions and an extended one,
and that we decide to delete one primary. Accessing the partitions by an
_index_ in the partition table, the number don't change. If, and only
if, a program numbering the partitions in "physical" order takes into
account this hole and gives it a number (this will be simply an "unused"
chunk of disk), everything works as usual. But if we delete _2_ adjacent
partitions, making _1_ hole the numbering will change, and hence all the
starting scripts will potentially fail.

So it seems to me now that GRUB makes some assumptions (to be verified
in the code) that are not optimal for system maintenance.

One final note. The spirit of the MBR (introduced after the Boot Secto
scheme when disk were increasing in size allowing the installation of
more than one OS on a disk) was to allow 4 OSes to live on the  same
disk. It seems at first glance obvious that the fair use (and the
warning of some programs may indicate that it was at least implicit) was
to declare the partitions in order. Some systems, for example BSD have
introduced a partitionning allowing a system to claim a chunk of the
disk (say a primary partition on PC) and then to administrate and
subdivide this chunk under the responsability of the OS (BSD slices).
This was perhaps the best idea.

The sole non spiteful explanation of this lonely partition, starting at 
the very beginning (non counting the first cylinder) but declared as the 4th
could be a partitionning tool that has extended the 4th partition to
recover the 3 first ones. But if this situation (one partition begining
at the beginning but put in the 4th slot) I
still consider this is not normal.

\the end.
-- 
Thierry Laronde <address@hidden>
Site Debian Francophone (aka SDF) : http://www.debian-france.org/




reply via email to

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