After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 327261 - specify order of partitions in the partition table
specify order of partitions in the partition table
Status: RESOLVED NOTABUG
Product: gparted
Classification: Other
Component: application
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
: 161640 392760 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-01-16 21:43 UTC by Jan Claeys
Modified: 2012-01-10 22:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Claeys 2006-01-16 21:43:21 UTC
It would be good to have a way to specify the order of partitions in the
partition table; both in the main partition table, and logical partitions in an
extended partition table.

E.g. removing a logical partition causes all subsequent logical partions to get
a lower partition number (/dev/hda6 --> /dev/hda5 etc.), which means you are in
trouble when grub was installed on one of those remaining partitions...
Comment 1 Plors (Bart H) 2006-09-14 10:11:02 UTC
*** Bug 161640 has been marked as a duplicate of this bug. ***
Comment 2 Plors (Bart H) 2006-09-14 10:12:57 UTC
lately there has been some talk about this on the parted-dev list. I don't think anyone reached a conclusion, but at least we're not the only ones thinking about this. (ok, i have not been thinking about this for about 6 months :P )
Comment 3 Plors (Bart H) 2007-01-07 15:14:38 UTC
*** Bug 392760 has been marked as a duplicate of this bug. ***
Comment 4 Phillip Susi 2011-12-19 20:26:13 UTC
This is a limitation of the msdos partition table, not a bug in gparted.  By their nature, logical partitions are numbered in order, and can not have unused numbers in the sequence.

This should be marked NOTABUG.
Comment 5 Curtis Gedak 2012-01-03 18:58:58 UTC
Logical partitions are assigned numbers in the order that these partitions are created.

Unfortunately removing a logical partition will always affect the assigned numbers of all partitions later in the chain.

This cause and effect on assigned device numbers is mentioned in the GParted documentation:
http://gparted.org/display-doc.php?name=help-manual#gparted-delete-partition

JanC,
    Do you agree with closing this bug report, or was there something else that you had in mind?
Comment 6 Jan Claeys 2012-01-07 18:54:56 UTC
Primary partitions are described in a fixed 4-entry list in the MBR, logical partitions are described in a linked list of EBRs inside an extended partition.

But in both cases there is no requirement that the order in which the partition descriptions are stored/linked is the same as the order of the partitions on disk.

To get an idea about what I mean, I partitioned an old 256 MiB USB stick with fdisk:

| $ LANG=C sudo parted /dev/sdg print
| Model: JetFlash TS256MJF2A/120 (scsi)
| Disk /dev/sdg: 262MB
| Sector size (logical/physical): 512B/512B
| Partition Table: msdos
| 
| Number  Start   End    Size    Type      File system  Flags
|  3      82.3MB  156MB  74.0MB  extended               lba
|  6      82.3MB  115MB  32.9MB  logical
|  7      115MB   140MB  24.7MB  logical
|  5      140MB   156MB  16.5MB  logical
|  1      156MB   255MB  98.7MB  primary

As you can see, the ordering of the device name number suffix is not related to the on-disk location of the actual partition.

It is also true that by default this numbering is the result of the order they were created in (at least, if the partitioning tool does not automatically reorder them), but that's only the result of how new partitions are created by most partitioning programs right now, and not really a rule set in stone.

Also, it is true that the logical partitions cannot have unused numbers in the linux device name sequence, but this is not true for primary partitions (primary partitions are numbered based on which one of the four "partition table entries" in the MBR they are defined in).

To conclude: I agree with most of what you guys say, and it might not always make it possible to solve the example problem given in the bug description (it can fix it sometimes), but I'm still convinced that it is possible to change the sequence in which partitions will be numbered because I have done it with lower-level partitioning tools in the past.

----

Some background: IIRC I filed this bug after a chat with Bart and maybe others on IRC long ago, after a couple of users came into the channel for help with their system not booting anymore after removing an "unrelated" partition.  The idea was that it would be easier for "normal" users to reorder partitions in a GUI than it is for them using a low-level partitioning tool or (even worse) a hex editor.

As Bart also points out: this was (and AFAIK is) not implemented in libparted, meaning implementing it would be complicated.

----

In any case, these numbered device names are more and more being replaced by unique ids wherever possible.  As a result, less and less things depend on them not changing, and this feature request also becomes less and less useful over time.   ;-)

So, as implementing this would be complicated and take time probably better used for other less obscure things, I would be okay if you WONTFIX or NOTABUG this feature request...
Comment 7 Phillip Susi 2012-01-08 17:14:06 UTC
The "rule" comes from the law of least surprise.  You don't want to confuse users and break operating systems by renumbering other partitions when you make changes to one partition.  This is why libparted never renumbers partitions, with the exception of when you remove an extended partition and the higher ones come down, and this is only because it can not be avoided.

Of course, if you want to renumber the partitions you certainly can; you just have to delete them and re-create them in the correct order.  I suppose gparted could add an interface to do this automatically, but why bother?  Who actually cares about the order?  Users generally don't know and don't want to know what partition is numbered where as long as it works correctly.

As for the original issue of grub breaking when you remove a logical partition, well, grub-legacy tried to support this for a time, but such efforts have been given up and now grub2 considers that to be a broken/unsupported grub configuration; grub is supposed to be installed to the MBR, not a logical partition.
Comment 8 Curtis Gedak 2012-01-08 19:00:25 UTC
Thank you Jan for the detailed explanation.  I can see that there is some value
in being able to specify the partition ordering.  Of course, as you state, the
value of such a feature is declining with the use of UUIDs becoming more
prevalent.  In addition the numbering of logical partitions is a problem with
MSDOS partition tables, and not the increasingly being used GPT partition
tables.

If I recall, the fdisk command will permit re-numbering partitions based on
disk order, so this functionality is available through another avenue.

I also agree that our time is probably better used for other less obscure
things.  As such I will close this report as NOTABUG, since GParted is working
as designed in this area.

If libparted ever does offer such a feature then this bug report can be
re-opened, or a new one created.
Comment 9 Jan Claeys 2012-01-10 22:23:31 UTC
@Phillip: as said, this bug was filed because back in 2005/2006 some users got into trouble after partitions got renumbered, and certainly it would have been easier for them if they could reorder them in a GUI to get a bootable system again.

Also, remember that back then GRUB1 stage 1.5 & stage 2 were often still stored in /boot, which could be (a directory on) a logical partition, while GRUB2 stores them in the "unused" area between the MBR & the first primary partition, and that means some of the issues we had back then are gone (although we have new issues now, like other applications that also assume that this area is unused... :P ).

----

@Curtis: yes, fdisk has an experimental option to reorder partitions in disk order, but it's quite buggy (it lost one partition when I tried to use it on the example usb stick I gave earlier!), which probably confirms that this is not exactly easy to implement...  ;)

----

Sad-what-if-remark: too bad the kernel doesn't number logical partitions based on the location in the linked list; that would allow the use of an empty EBR to make sure partition numbers don't change...