This bug was fixed in the package cloud-initramfs-tools - 0.4ubuntu1
---
cloud-initramfs-tools (0.4ubuntu1) precise; urgency=low
* growroot: run 'udevadm settle' before attempting growpart to
allow initial events to finish (LP: #937352)
-- Scott MoserThu, 23 Feb 2012 22:19:
I've just uploaded what we believe/hope will be a fix to this issue.
After much discussion, we decided to add a 'udevadm settle' prior to invoking
'growpart'.
The suspicion is that in the initial flurry of device activation, one of
the udev spawned events still had an open filehandle on the bloc
I've now uploaded some new images, with the improved growroot, and the
output of a failed resize looks like this:
--
Begin: Running /scripts/local-bottom ... [0.892501] vda: vda1
GROWROOT: WARNING: resize failed: attempt to resize /dev/vda failed. sfdisk
output below:
| Checking that no-
Sorry to have brought us down the wrong road with some of my snippets
above.
I just uploaded a new cloud-utils (growpart) which will show the original
output of the failed sfdisk command.
In the original summary of the bug, all that is present is the output of the
*restore* command after the sfd
regarding CHS, i'm fairly sure that its not important. the only reason I
actually use it is so that I can specify (and see) values in sectors
rather than at a larger unit.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.la
Sidenote: it seems the CHS output for a partially used drive will not
necessarily match the drive. Even when fdisk did show the drive values
when creating the partial partition. Adding a second partition that
fills the complete disk will fix that... And sfdisk seems never happy
with the values when
The snippet from comment #5 actually has a major flaw. Since there is no
waiting in the loop after doing the sfdisk --re-read and so we do
actually run into races with the udev triggered partition checks
(blkid/cdrom_id). Adding a udevadm settle after the sfdisk call does
prevent all failures I saw
Experimenting a bit with the snipped from comment #5, I can see the same
happening for a xen based guest. One interesting fact here is that this is
temporary only. So adding a sleep 1 between the umount and the sfdisk command
will suppress that failure.
So it feels like umount returns while the
Adding a "sync" call between umount and sfdisk seems to avoid the
problem. At least the loop ran until I stopped it instead of failing
very early (between one and three iterations).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-initramfs-tools (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/937352
This snippet seems to reproduce the issue for me sporadically, and much simpler
than the attached script. It assumes there is a filesystem already on
/dev/vdb1 and /dev/vdb is partitioned already.
sudo sh -c 'd=$1; p=${d}1; mp=/mnt; cleanup() { umount $mp >/dev/null 2>&1; } ;
trap cleanup EXI
note, it does seem that maybe this should be calling partprobe.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/937352
Title:
root partition in may not be grown
To manage notifications about this bug
This attachment does the following to a given block device input
* create a partition table for the block device with first partition using
roughly half disk space
* mkfs first partition
* mount partition
* run growpart --dry-run
* umount partition
* run growpart
If you run it in a lo
** Description changed:
Not a dupe of bug 906722, but it seems very similar.
Occasionally on openstack clouds, we're seeing the root partition not
being/grown on first-boot as it should be.
This was reported, and I have observed it on precise alpha-2 and will
attach console logs.
** Attachment added: "successful console log"
https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/937352/+attachment/2764047/+files/console-i-148d.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bug
** Attachment added: "failed console log (some user-data output clipped)"
https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/937352/+attachment/2764046/+files/console-i-148c.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subsc
16 matches
Mail list logo
