Add a pure sfdisk resizer for cc_growpart

This bug was originally filed in Launchpad as [LP: #1443689](https://bugs.launchpad.net/cloud-init/+bug/1443689)

Launchpad details

affected_projects = []

assignee = None

assignee_name = None

date_closed = None

date_created = 2015-04-13T23:23:49.952628+00:00

date_fix_committed = None

date_fix_released = None

id = 1443689

importance = low

is_complete = False

lp_url = https://bugs.launchpad.net/cloud-init/+bug/1443689

milestone = None

owner = awilliamson

owner_name = Adam Williamson

private = False

status = confirmed

submitter = awilliamson

submitter_name = Adam Williamson

tags = []

duplicates = []

_Launchpad user **Adam Williamson(awilliamson)** wrote on 2015-04-13T23:23:49.952628+00:00_

The 'growpart' tool itself is actually replicating functionality sfdisk already has. When editing a partition, the size can be specified as '+' to indicate 'make this partition as large as possible'.

sfdisk < 2.26 would fail when attempting to do this on a GPT-labelled disk (which is a reasonable enough justification for growpart's existence, I guess), but from 2.26 onwards it works (in my testing, anyway) for both MBR- and GPT-labelled disks.

I've written a patch that introduces a new resizer (using cc_growpart's existing support for multiple resizer backends) which uses sfdisk directly instead of growpart. The new resizer is only considered to be 'available' if the util-linux version appears to be 2.26 or higher.

The effect should be that native sfdisk resizing will be used if util-linux is new enough, but growpart will be used if it's older.

I would envisage that at some point we could decide that everyone's had enough of a chance to update util-linux and growpart could shuffle off this mortal coil, and the code could probably then be substantially simplified.

I'm going to try and tag a launchpad branch which has the patch applied, hope I get it right, my first time trying this...