yahoo-eng-team team mailing list archive

[Scott Moser <ssmoser2+ubuntu@xxxxxxxxx>]

This bug is believed to be fixed in cloud-init in version 18.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
       Status: Fix Committed => Fix Released

-- 
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/1404745

Title:
  cloud-init's growfs/resize fails with gpart dependency on FreeBSD

Status in cloud-init:
  Fix Released

Bug description:
  I've generated a FreeBSD qcow2 including base and kernel with cloud-
  init and dependencies. cloud-init runs when the instance boots, but
  the growpart module fails due to, what appears to be, two separate
  problems.

  One of the dependencies is the gpart port/pkg which, incidentally, is
  a reason it is failing[1]. The growpart module, for a yet unknown
  reason, is calling /usr/local/sbin/gpart with arguments that are valid
  only with FreeBSD's /sbin/gpart. cloud-init executes /sbin/gpart when
  the dependent /usr/local/sbin/gpart is removed that subsequently
  results in the next failure which I think is caused by cloud-init
  itself...

  cloud-init executes growfs, via resizefs, after successful execution
  of gpart recover/resize. The logs[2] illustrate the growfs command as
  growfs /dev/vtbd0p2. By default, FreeBSD's growfs runs interactively
  asking a question which can be mitigated using the '-y' command line
  option. The logs indicate a successful growfs operation, but df
  doesn't reflect it. I suspect the this is due to the default
  interactive nature of growfs.

  [1] http://hostileadmin.com/images/cloud_init_gpart_fail.jpg
  [2] http://hostileadmin.com/images/cloud_init_growfs_fail.jpg

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