Bug 6963

This is expected behaviour, when a logical partition is deleted
from an extended partition, and then a new one is created.

Before the delete
mbr partition table has pointer to start of sda5
sda5 partition table has pointer to actual sda5 partition, and
a pointer to sda6.
sda6 partition table has pointer to actual sda6 partition, and
a pointer to sda7, and on.
sda9 (assuming that's the last partition) partition table has
a pointer to actual sda9 partition, and an empty pointer which
will be used for the next partition, when it gets created.

After the delete.
mbr partition table pointer is changed to point to what was sda6,
which by definition, becomes sda5, with the remaining partitions
renumbered, so what was sda9 will become sda8.

When the new partition is created, even though the same space
that was previously used for sda5, is used, the new partition
becomes sda9, and the partition table at the start of sda8
is modified to point to sda9.

If the above is not clear, try taking a look at the output of
sudo /sbin/sfdisk -l -uS -x /dev/sda

When ever partitions are renumbered, and /boot is in one of the
partitions that has been renumbered, grub will have to be fixed
and reinstalled.  Having diskdrake automatically detect when this
is needed, and doing it for the user, would be a nice enhancement,
but it isn't a simple change.

I'm going to close this bug as invalid.  Feel free to add questions
or comments.

Status: NEW => RESOLVED
CC: (none) => davidwhodgins
Resolution: (none) => INVALID

Hello, I would like to see this open as a feature request for drakdisk. I think that drakdisk is here to help the user and it should never force him to do parts of the work by manually editing the system files.
Diskdrake already knows when the partitions get renumbered. It only needs to check which numbers have been changed and make small modifications in the boot menu.

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

Dear Dave Hodgins,

this is wrong what you write:
"When the new partition is created, even though the same space
that was previously used for sda5, is used, the new partition
becomes sda9, and the partition table at the start of sda8
is modified to point to sda9."

The partition has never gone. By clicking on 'empty' only the formatting has been removed. The partition is still shown as /dev/hda5, evening after the renumbering warning message. I wonder why it is renumbering, because I did not click to write the partitions to the disk. I think that diskdrake should only write the partitioning at the end.
All partition numbers are the same at the end of the process. Each of the partitions keeps its number as it has been before. This is not like under Windows.

Therefore the Boot Manager should be working in the end or it should ignore any partitions without a format.

In former versions of diskdrake it has been no problem at all to modify the format of a partition. This is a new problem coming with Mageia 2.

When you format a partition, there should be no problem.

When you delete/add a partition, in the middle or start
of a logical partition chain, all partitioning software
I've seen, will add the new partition at the end of the
chain.  Try it with windows (any version), and it will
do the same thing.  That is required based on how msdos
style partition tables are managed.

The reason for this, is that when you create a new
partition, it doesn't have to be at the start of the
free space.  If you leave a gap between sda5 and sda6,
and then create a new partition in the gap, it will be
sda7, so sda6 does not get renumbered.  You don't want
drive f: to become drive g:, just because you've created
a new partition.

As to modifying diskdrake or the rescue mode to
automatically handle this case, the reason it gets
complicated, is that you may or may not be using the
grub that is installed on this partition, to boot from.

Consider the following case.

You have Mageia 1 installed on sda6, with it's grub
installed in the mbr.  You then install Mageia 2 on
sda7, and have it's version of grub overwrite the version
on the mbr, which automatically includes boot stanzas
for both Mageia 1 and 2.

You boot into Mageia 1.  Delete sda5 and create a new
partition. The partitions get renumbered.  There is no
possible way for diskdrake to determine whether or not
it should overwrite the version of grub on the mbr.

If it does, since it doesn't have a boot stanza for
Mageia 2, you've now lost the ability to boot Mageia
2, and anything else you've put in the menu.lst file
in Mageia 2.

If it doesn't, you're in the position where you can
chroot into Mageia 2, fix the install.sh file, and
re-install grub, before you reboot, or from a rescue
cd.

While it would be nice if the system did not allow
people to make mistakes that prevent the system from
being able to boot, it must not prevent someone who
does know how things work, from making the system
work the way they want.

Just having Mageia 1 and 2 is a fairly simple case.
The admin may have a distro installed using a
filesystem that Mageia can't even read, and have
grub installed on the mbr from that distro.

All of the problems you're describing are caused by
the failure of the format, which then caused you to
choose to delete/create the partition, without the
understanding of the implications.

The only possible bug in what you've described, is
why did the format fail.  To figure out why that is
happening, more info will be required, as I cannot
recreate the problem.

I'm not trying to be obstinate.  I'm trying to make
it clear, that what you are reporting as bugs (with
the exception of the failure to format) are the way
things are supposed to work, so the admin has the
flexibility to set things up the way they want.

Sure, a linux distro could always overwrite the mbr,
just like windows does, but that would not be accepted
by most people.

But diskdrake on Mageia2 should be able to detect which boot manager has been used. Therefore diskdrake should be able to take care of the entries in the Grub Boot Manager which is the mainly used one. There is already now a dialog which asks the user if the Boot Manager shall be rewritten. And on this point diskdrake fails. Why does diskdrake offer this option, when you refuse to make this working also for my case?

(In reply to comment #5)
> But diskdrake on Mageia2 should be able to detect which boot manager has been
> used. Therefore diskdrake should be able to take care of the entries in the

Not possible if grub was installed from a filesystem on another distribution
that mageia cannot even read.

There is no safe way to know for sure which distribution's boot manager was
the last one (the one the admin wants) written to the mbr.

> Grub Boot Manager which is the mainly used one. There is already now a dialog
> which asks the user if the Boot Manager shall be rewritten. And on this point
> diskdrake fails. Why does diskdrake offer this option, when you refuse to make
> this working also for my case?

It may well be grub on the mbr, but there is no way to know if it was grub
from Mageia, Mandriva, or whatever.

It isn't that I don't want diskdrake to be able to handle this case.  It's that
this case should not normally happen, and there is no safe way to handle it in
a multi boot situation.

Regarding the failure to format, as I've replied in the other bug report, the
problem appears to be that umounting the device is not freeing the device, as
it should.  This is a new problem, that I haven't seen even in very recent
testing.  (I've done at least 8 installations on this system over the last
couple of weeks, as I'm part of the qa team, and was setting up a new
computer.)

However there should be at least one tool from Mageia which is able to repair and rewrite the Boot Manager in the same way as the Installation does it.
I have tried diskdrake, MCC and the Rescue DVD. All of them fail to rewrite the Boot Manager again.

then please change your summary (anywany maybe all boot stuff will change or be dead with grub2)

Source RPM: (none) => drakxtools

This is bad news with Grub2. I have just made a fresh Mageia installation where formerly Mandriva has worked perfectly on several harddisks and partitions. But the Mageia installation writes the boot manager in a way that no boot at all is possible any more. I only get 'file not found' errors.

Mageia functions exactly the same as Mandriva in terms of adding/deleting/reformatting hard disk partitions.
(Having done this many times on both Mandriva and Mageia.)

The renumbering of "logical" partitions when a logical partition is deleted is due to the daisy-chaining of logical partitions in a traditional msdos partitioning scheme.

If you want to minimize problems, you can use the expert mode of diskdrake to change a partition type and reformat without deleting, to avoid the renumbering of partitions.
(Or use Gparted, which shows more details, and is included in Mageia.)

Alternately, you could have corrected for the renumbering of logical partitions in grub and /etc/fstab.

The "file not found" errors are due to grub specifying the wrong partition number.  With more recent installs (of Mandriva and all Mageia), only the number of the boot drive is problematic, since the UUID, written on each partition, is used by default otherwise.

So we already have tools to recover from these errors.  But it helps to really understand disk layout.

For this, you can always ask on the forum or on the discussion mailing list.

So closing as invalid

Status: REOPENED => RESOLVED
CC: (none) => andre999mga
Resolution: (none) => INVALID

This is weird. Why should users be forced to use and learn many tools, ask in forums and hopefully get correct answers? 
Diskdrake should instead help users to get their job done quickly without problems and without any need of detailed knowledge of the LINUX internals.

Please create a separate 'enhancement request' bug Franz. 
You can link it to this one if you like.

Thanks

(In reply to Franz Holzinger from comment #11)
> This is weird. Why should users be forced to use and learn many tools, ask
> in forums and hopefully get correct answers? 
> Diskdrake should instead help users to get their job done quickly without
> problems and without any need of detailed knowledge of the LINUX internals.

I understand, the partitioning scheme is indeed somewhat wierd.
But diskdrake is an excellent tool, if used properly.  Other tools are just alternate ways of doing things, or means of recovering from errors in the use of diskdrake.
Let me explain.

This is not a linux-specific problem.
It is due inherent limitations of the Microsoft-inspired partitioning scheme, still used on the majority of PC's.  (Generally referred to as msdos or bios partitioning.)
There is a newer partitioning scheme called gpt, which has only directly accessible partitions, referred to as primary on msdos partitioned disks.  (Generally a maximum of 128 partitions.)
Gpt never has the renumbering problem, since partitions can be numbered in any order, and adding or deleting a partition has no effect on the numbering of existing partitions.  As well, gpt has a partition backup table, for more security.

Gradually the computer industry is moving to gpt, including Microsoft.
Current disks can be converted to gpt, since it is just how the partitions on the disk are accessed (or indexed).
(I have be using gpt on converted disks for several years.)

For the current msdos disk partitioning, it would be useful for Mageia to have a detailed guide to help users avoid problems.
Following such a guide, diskdrake could be very easily used to reliably and quickly do what you wanted to do.
There could even potentially be a help button in diskdrake leading to such a guide.

Note that for Microsoft systems, adding or deleting partitions is a lot trickier than for linux.  (The boot partition must start in an exact location, not just be on the right partition number.  So it is very easy to end up with an unbootable system.)