yahoo-eng-team team mailing list archive

[Rick <vmiller@xxxxxxxxxxxxxxxx>]

Public bug reported:

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

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


** Tags: cloud-init freebsd gpart

-- 
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 Init scripts for use on cloud images:
  New

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