shoot. I thought I had attached a cleaned up version of that.
I tested your newer diff, and i believe it still to be wrong.
My confusion stems from not knowing how partx_{add,del,resize}_partition
functions understand their 'int partno' argument.
Given the partition table layout created by the following input to sfdisk -uS
$DEV:
0,0,0
4096,2048,L
0,0,0
2048,2048,L
sfdisk --durmp output shows that as:
$ sudo sfdisk -uS --dump /dev/vdb
# partition table of /dev/vdb
unit: sectors
/dev/vdb1 : start= 0, size= 0, Id= 0
/dev/vdb2 : start= 4096, size= 2048, Id=83
/dev/vdb3 : start= 0, size= 0, Id= 0
/dev/vdb4 : start= 2048, size= 2048, Id=83
There are 2 different numbering schemes being mixed here.
a.) the order of blkid_struct_partlist.parts array as returned by get_partlist
To my understanding, this is the order as seen in the partition table.
ie:
vdb2: 1
vdb4: 0
b.) the "human order" that is input to partx.
vdb2: 2
vdb4: 4
The code as it is right now (and with your suggested fix) I believe
makes an invalid assumption about the relationship between A and B.
I'm fairly sure that partx_{add,del,resize}_partition assume 'b' for the
partno parameter.
My fix was to only deal with 'b' in the loop by adding the helper
function that got the partition 'b' with input 'a'. See my cleaned up
patch for example.
** Patch added: "suggested patch"
https://bugs.launchpad.net/ubuntu/+source/cloud-utils/+bug/1244662/+attachment/3945396/+files/lp1244662-partx-update.diff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1244662
Title:
growpart reverses changes because of partx failure
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-utils/+bug/1244662/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
