This bug was fixed in the package cloud-init - 0.7.5~bzr933-0ubuntu1
---
cloud-init (0.7.5~bzr933-0ubuntu1) trusty; urgency=medium
* debian/control: bump Standards-Version to 3.9.5
* debian/control: drop boto dependency no longer required in trunk.
* New upstream snapshot.
Ok.
I'm not even sure if resizepart can be made to work, at all.
$ parted --help | grep resizepart
resizepart NUMBER ENDresize partition NUMBER
the END seems to be in MB, which is insufficient for my needs. I'd like it to
grow it to the next partition.
There isn't a
** Changed in: cloud-init
Status: Confirmed = Won't Fix
** Changed in: cloud-init (Ubuntu)
Status: Confirmed = Won't Fix
** No longer affects: parted (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init
** Description changed:
As reported in bug 1212444, the partition growing is broken if growpart is
found to be usable.
There are 2 things that are broken,
a.) we invoke parted wrong (passing device after 'resizepart' rather than
before)
b.) parted seems somewhat broken, and I dont
You don't use ---pretend-input-tty in conjunction with --script. The
point is to pretend that you are a human, not a script.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1212492
I'm not using '--script' above. It seems to make no difference in my testing.
Thus the test with 'expect' to try to trick it into using a tty and feed it
info that way.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in
You have to not use --script and parse the output for the warning and
answer yes. I have been mulling over a --force-things system to allow a
script to specify that it expects a specific error and how it should be
handled but it isn't easy the way libparted is structured.
--
You received this
** Description changed:
As reported in bug 1212444, the partition growing is broken if growpart is
found to be usable.
There are 2 things that are broken,
- a.) we invoke parted wrong (passing device after 'resizepart' rather than
before)
- b.) parted seems somewhat broken, and I dont
I dont think i follow what you meant by parse the output for the
warning and answer yes.
Example:
$ echo 1,1000,L | sudo sfdisk /dev/vdb
$ grep vdb /proc/partitions
253 16 20971520 vdb
253 17 504000 vdb1
$ sudo mkfs /dev/vdb1
$ sudo mount /dev/vdb1 /mnt
## now /dev/vdb is
IIRC, parted assumes --script mode when stdin is not a tty. There was
an undocumented switch that the test suite uses to override this, or I
thought that expect allocates a pseudo tty (might need a switch) and
that should also do the trick.
--
You received this bug notification because you are
Phillip,
I guess that basically means I can't use this. :-(
It also seems generally broken as the primary reason for 'resizepart' is to
allow modifying a busy partition table and telling the kernel about it.
Any ideas on how to proceed? Should I file a bug/feature request upstream by
So it looks like we need some way to specify '--force' to parted. The
use case we have is known to have 'in use' partition that we're trying
to grow.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
Currently the only way to have parted resize a busy partition is to use
interactive mode rather than script mode and say yes at the prompt.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
13 matches
Mail list logo
