I kept on testing this throughout the most part of the morning and I feel that we should not use this patch. There are two main reasons: 1. The patch is not valid for all types of partitions. Its valid for primary, but not for logical. The logical ones continue to be renumbered (even with this patch). 2. Even if we manage to figure out a way to make it work with logical partitions, it would not survive a reboot. Some questions that need answering: 1. Why does it work with primary? With primary partitions there is a section of 4 consecutive partition structures (primary_part_structure). When we use the patch, we avoid making sure that the partition structures are used consecutively. In other words we can have something in primary_part_structure[0] that will always be called part1. We can also have nothing in primary_part_structure[1] and it would be a slot only for part2. And we can have something in primary_part_structure[2] that will always be called part3. Without the patch the slots without partitions are pushed to the end and the ones with something on them are pushed to the front. So when primary_part_structure[n] is free and primary_part_structure[n+1] contains a valid partition primary_part_structure[n] = primary_part_structure[n+k] 2. Why does it not work with logical partition? Because logical partitions have a different setup. Look at http://en.wikipedia.org/wiki/Extended_boot_record. These partitions have no way of tracking the relation between the partition and the partition number (as opposed to the primary ones). They are just a linked list and the first part in the list will be N and the next N+1 and the next N+2.... So since there is no way of tracking the relationship, parted (correctly) updates its internal structure by renumbering the parts. 3. Is there a way to make parted keep track of the part-number/partition relation ? IMO, yes. But its something that is not worth considering because whatever strange numbering order we end up with, it will be lost on reboot. 4. Why is it lost on reboot? I believe that it is because the kernel just starts from the first logical partition and numbers from there. 5. What do you suggest to solve the referencing of a partition? To reference the partition (and anything on top of a real device) with start block and end block. You will end up having to say something like getPartByGeometry(start, end). FYI, parted already has this (or something very similar). With ped_disk_get_partition_by_sector, parted will return the partition that contains that sector. If I am mistaken in any of this I would really appreciate a correction :) Regards. On Fri, May 22, 2009 at 09:35:34AM -1000, David Cantrell wrote: > On 05/22/2009 09:27 AM, Chris Lumens wrote: >>> This is a hack that hans proposed for the parted issue. Don't see this >>> causing any problems. >>> clumens: what do you think of this for a temporary solution for the >>> enumeration issue? >> >> Applying this patch to parted in package CVS, adding the following patch >> to pyparted, rebuilding both, and putting both in an updates.img fixes >> the problem for me in my simple test case. >> >> diff --git a/src/pydisk.c b/src/pydisk.c >> index 82500e5..84dcbd4 100644 >> --- a/src/pydisk.c >> +++ b/src/pydisk.c >> @@ -1403,6 +1403,9 @@ PyObject *py_ped_disk_remove_partition(PyObject >> *s, PyObject *args) { >> } >> } >> >> + if (ped_disk_enumerate_on()) >> + ped_disk_toggle_do_enumerate(); >> + >> ret = ped_disk_remove_partition(disk, out_part); >> if (ret == 0) { >> if (partedExnRaised) { >> >> My simple test case is a partition layout with multiple logical >> partitions. Having that as a pre-existing layout and then doing >> autopart consistently fails for me. These patches correct that. > > The fix seems reasonable to me. Existing API functionality is/can-be > preserved in libparted. > > In pyparted, I suppose we should also expose > ped_disk_toggle_do_enumerate(), but that's not critical for now. > > The libparted patch has my vote. > > -- > David Cantrell <dcantrell@xxxxxxxxxx> > Red Hat / Honolulu, HI -- Joel Andres Granados Brno, Czech Republic, Red Hat. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
