cloud-init: support resizing on MBR partition tables

[mudler]

Seems the automatic resizing from the cloud-init examples in the rpi(also odroidc2, probably) images doesn't work. I get a silent exit status 2. However, the generated command seems correct (sgdisk .. ) which correctly identifies the partition number.

Follow up of #1023

Originally posted by @mudler in #1023 (comment)

[mudler]

@davidcassany could it be related that with sgdisk is gpt the prefered partition table layout? or should not actually be an issue? I'm just wondering, because most of the resizing scenario tests we perform on EFI, but we don't really test outside of it. Considering that arm is mbr, then might be an issue..

[davidcassany]

Isn't RPi using the MSDOS partition tables? If so, then it won't work. Layout plugin only works for GPT partition tables as it is based on sgdisk.

The real fix for that is using the partitioner package from elemental-cli in yip as it supports MSDOS and GPT. Indeed updating yip layout plugin to relay on elemental-cli partitioner package has been my midterm intention since we started elemental-cli. It should be relatively simple to do so as the API in partitioner module is intentionally copying the layout yip plugin for that exact purpose.

[mudler]

ok, treating it as a feature request then as we never actually supported this before in MBR

[mudler]

Isn't RPi using the MSDOS partition tables? If so, then it won't work. Layout plugin only works for GPT partition tables as it is based on sgdisk.

The real fix for that is using the partitioner package from elemental-cli in yip as it supports MSDOS and GPT. Indeed updating yip layout plugin to relay on elemental-cli partitioner package has been my midterm intention since we started elemental-cli. It should be relatively simple to do so as the API in partitioner module is intentionally copying the layout yip plugin for that exact purpose.

Another way is also to consume directly the partitioner from elemental-cli in the elemental-cli cloud init runner, but I'm not sure if it already works as a drop-in replacement for the layout plugin currently in yip, anyhow both ways sounds fine!

[davidcassany]

Another way is also to consume directly the partitioner from elemental-cli in the elemental-cli cloud init runner, but I'm not sure if it already works as a drop-in replacement for the layout plugin currently in yip

I don't think so, as I believe console interface and probably few other details are not fully aligned. Anyway it is worth finding the best way to express or sort out this dependencies since having elemental-cli requiring yip and yip requiring some elemental-cli package looks like leading to confusions or strange circular dependency issues.

[mudler]

Anyway it is worth finding the best way to express or sort out this dependencies since having elemental-cli requiring yip and yip requiring some elemental-cli package looks like leading to confusions or strange circular dependency issues.

Yes indeed, better or yip takes the 'extended' layout plugin code, or either elemental-cli just replaces with its own, leaving the yip layout plugin as it is currently. I'd suggest elemental-cli to use their own in place of the yip one to avoid code dups (unless we split the layout code in a standalone lib..) as it is more straightforward