Ok, / is non-sense as it is certainly mounted and also the failing fsck
is fot /mnt. But generally it looks like mountall and cloud-init running
concurrently and anything that opens the device may block a rw access
for the fsck. So any blkid could do that. The window is not very big but
who
This bug was fixed in the package cloud-init - 0.6.3~bzr519-0ubuntu1
---
cloud-init (0.6.3~bzr519-0ubuntu1) precise; urgency=low
* New upstream snapshot.
- [Mike Milner] add support for managing CA Certificates (LP: #915232)
- in ci-info lines, use '.' to for empty field
I believe this is fixed in cloud-init revision 515
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/515
Note, we could also restrict the device type searched by checking
/sys/block/devname/device/type as stefan suggested.
--
You received this bug notification because you
** Branch linked: lp:cloud-init
--
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/898373
Title:
fsck.ext3: Device or resource busy while trying to open /dev/xvda2
To manage
Hm weird. I would have expected at least a rw open on the block device should
fail, let alone a ro (since fsck probably wants to modify the fs). Though I'd
need to check exactly what access mode mount -oro uses (maybe its some ro
exclusive). Actually it is not really a read-only open on the
Hm, when I look at /etc/init/cloud-init-local.conf and */cloud-init.conf
they seem to say start on mounted MOUNTPOINT=/. So I'd somehow expect
mountall to be finished with / at that point. Still the output of cloud-
init and mountall seem to intermix often. As if they are executed around
the same
I think there are 2 things that could be causing this from cloud-init:
a.) cloudinit/CloudConfig/cc_resize.py [1]
This uses blkid, but almost certainly only passes blkid a device node that
represents '/'. It basically does a stat on /, gets major and minor, creates a
device node that has
Note, assuming our theory on the circumstances of the race is correct
above (that it is 'read' or mount of that device), I was unable to
reproduce with a loop device, which I thought would have caused a
similar issue:
1. truncate --size 100m /tmp/my.img
2. mkfs -F -t ext3 /tmp/my.img
3.
** Description changed:
I'm opening this against cloud-init, but I do not actually think that is
valid.
In an ec2 instance for test of alpha-1 images [1], we saw errors on boot like:
- Loading, please wait...
- [1342606.840604] udevd[81]: starting version 175
- Begin: Loading
Seen again at [1] from tests for precise alpha-2 at [2]
--
[1]
Seen in jenkins daily runs in build at [1]. Specifically, see console
log of instance at [2]
--
[1]
after looking at the console pointed at in comment 3, I thought i might
be able to trigger this by issuing 'reboot-instances' on a running node.
I was not successful in doing so.
In a instance of:
eu-west-1 ami-738fb007 ubuntu-precise-daily-i386-server-20120119
I issued reboot via
after doing this, i caught a fsck device busy error:
args=--region=eu-west-1 i-087e0b41'
for((i=12;i50;i++)); do
echo $(date): i=$i; euca-reboot-instances $args sleep 1m
euca-get-console-output $args /tmp/console.hard-reboot$i; done
the 37th boot (attaching) showed this error.
**
** Changed in: cloud-init (Ubuntu)
Importance: Undecided = High
** Changed in: cloud-init (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
** Attachment added: test output console log
https://bugs.launchpad.net/bugs/898373/+attachment/2614073/+files/console-ami-a7cc07ce.log
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
15 matches
Mail list logo
