cloud-init's growfs/resize fails with gpart dependency on FreeBSD
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| cloud-init |
Undecided
|
Harm Weites |
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/
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://
[2] http://
Related branches
- Bert JW Regeer (community): Approve on 2016-09-12
- Scott Moser: Pending requested 2015-01-11
-
Diff: 24 lines (+1/-2)2 files modifiedcloudinit/config/cc_resizefs.py (+1/-1)
tools/build-on-freebsd (+0/-1)
- Chad Smith: Approve on 2018-05-01
- Server Team CI bot: Approve (continuous-integration) on 2018-04-24
- Harm Weites: Pending requested 2018-04-24
-
Diff: 26 lines (+2/-2)2 files modifiedcloudinit/config/cc_resizefs.py (+1/-1)
tests/unittests/test_handler/test_handler_resizefs.py (+1/-1)
Changed in cloud-init: | |
status: | New → Confirmed |
assignee: | nobody → Harm Weites (harmw) |
Harm Weites (harmw) wrote : | #1 |
Harm Weites (harmw) wrote : | #2 |
Added my branch with the cloud-init code change.
Rick (vmiller) wrote : | #3 |
It has been confirmed that the fixes proposed here do correct the behavior.
Scott Moser (smoser) wrote : | #4 |
Hi, there were some recent changes in trunk at
https:/
I think this is now probably fixed.
Could you please test with a new version of cloud-init and report back?
If the issue is still present, please set teh state to 'confirmed'.
If it is not, then set to fix-committed.
Thanks,
Scott
Changed in cloud-init: | |
status: | Confirmed → Incomplete |
Rick (vmiller) wrote : | #5 |
I can test this in a few months when at the point of generating new FreeBSD qcow2 images. There are competing priorities at this time.
Sergei Butov (myser90) wrote : | #6 |
The problem is still relevant.
https:/
-y ``Expert mode''. Usually growfs will ask you if you took a
backup of your data before and will do some tests whether special
is currently mounted or whether there are any active snapshots on
the file system specified. This will be suppressed. So use this
option with great care!
Without this option FS doesn't resize.
Scott Moser (smoser) wrote : | #7 |
Sergei,
can you verify that the fix suggested
https:/
will actually work ?
that is to say all we need to do is call growfs with '-y' ?
Changed in cloud-init: | |
status: | Incomplete → Confirmed |
Sergei Butov (myser90) wrote : | #8 |
> Sergei,
> can you verify that the fix suggested
> https:/
> will actually work ?
Yes, it's work.
> that is to say all we need to do is call growfs with '-y' ?
Yes. Package 'gpart' is already removed from dependencies.
Chad Smith (chad.smith) wrote : | #9 |
An upstream commit landed for this bug.
To view that commit see the following URL:
https:/
Changed in cloud-init: | |
status: | Confirmed → Fix Committed |
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 |
Scott Moser (smoser) wrote : | #11 |
Just an FYI, This change is being released to Ubuntu 16.04, 17.10 and 18.04 under bug 1777912.
Interested to see this from gpart:
2015-01-11 18:49:23,742 - util.py[DEBUG]: Failed: gpart recover /dev/vtbd0 lib/python2. 7/site- packages/ cloudinit/ config/ cc_growpart. py", line 132, in resize subp([" gpart", "recover", diskdev]) lib/python2. 7/site- packages/ cloudinit/ util.py" , line 1570, in subp nError: Unexpected error while running command. -c][-d] [-E][-e] [-f][-g] [-h][-i] \n [-K <last sector>][-k <# of sectors>][-L][-l <log file>]\n [-n <increment>][-q][-s <sector-size>][-t <module-name>]\n [-V][-v][-W <device>][-w <module- name,weight> ]\ngpart v0.1h (c) 1999-2001 Michail Brzitwa <email address hidden>.\nGuess PC-type hard disk partitions.\n\n'
Traceback (most recent call last):
File "/usr/local/
util.
File "/usr/local/
cmd=args)
ProcessExecutio
Command: ['gpart', 'recover', '/dev/vtbd0']
Exit code: 1
Reason: -
Stdout: ''
Stderr: 'Usage: gpart [options] device\nOptions: [-b <backup MBR>][-C c,h,s][
This was stderr:
Usage: gpart [options] device -c][-d] [-E][-e] [-f][-g] [-h][-i]
[-V][ -v][-W <device>][-w <module- name,weight> ]
Options: [-b <backup MBR>][-C c,h,s][
[-K <last sector>][-k <# of sectors>][-L][-l <log file>]
[-n <increment>][-q][-s <sector-size>][-t <module-name>]
gpart v0.1h (c) 1999-2001 Michail Brzitwa <email address hidden>.
Guess PC-type hard disk partitions.
A little rude, but lets see what happens, since the above is most certainly nothing compared with man gpart...
# find / -name gpart sbin/gpart
/rescue/gpart
/usr/local/
/sbin/gpart
Bingo: we have gpart in base -and- from ports, and according the initscript cloudinit will use /usr/local/sbin first.
Workaround:
After installing the cloudinit port remove gpart: pkg delete -f gpart
Fix:
Lets remove that port from the required dependencies. Ill see what's required to get that going, I think this only involves pushing out a new port release.
The other issue seems to be with growfs, which doesn't grow the filesystem. The cc_resizefs module should be looking like this:
def _resize_ ufs(mount_ point, devpth):
return ('growfs', '-y', devpth)
After this it'll resize as planned. (I can't believe I missed that -y though...)