yahoo-eng-team team mailing list archive

[Adam Williamson <awilliam@xxxxxxxxxx>]

Public bug reported:

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...

** Affects: cloud-init
     Importance: Undecided
         Status: New

** Branch linked: lp:~awilliamson/cloud-init/sfdisk-resizer

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1443689

Title:
  Add a pure sfdisk resizer for cc_growpart

Status in Init scripts for use on cloud images:
  New

Bug description:
  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...

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1443689/+subscriptions