This issue is now being tracked upstream at
http://eucalyptus.atlassian.net/browse/EUCA-2667
Please watch that issue for further updates.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/457283
Title:
** Also affects: eucalyptus/2.0
Importance: Undecided
Status: New
** Changed in: eucalyptus/2.0
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/457283
Title:
** Changed in: eucalyptus
Assignee: (unassigned) => Dmitrii Zagorodnov (dmitrii)
--
x86_64 images should be presented a /dev/sdb, not a /dev/sda2
https://bugs.launchpad.net/bugs/457283
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I'll point out, that at least in the lucid version of eucalyptus, there
is valid data stating where the ephemeral storage is in the metadata
service. So, if the image is set to query metadata service for the
ephemeral device, then this will work properly.
I know, its a layer of indirection, but i
This is really on the (we do our best to keep it)short-list of steps
that one currently needs to perform in order to migrate images (to and
from). Remember that images which are configured to run on xen will
almost surely need some minor modifications (...kernel modules?) in
order to boot properly
Disagree on priority - that assumes that only ubuntu karmic (or later)
images will ever be used, and breaks compatibility with every other
ec2-compatible image out there. (And not breaks like "annoyingly the
hostname is 172 & everything works fine", but actual "firstboot scripts
will fail, dogs and
Lowering priority since ec2-init works around this bug for Lucid for
now. The issue is still present, though not trivially solved. Might be
deferred until Lucid+1, unless a contained fix can be found.
** Changed in: eucalyptus (Ubuntu)
Importance: Medium => Low
--
x86_64 images should be pr
fwiw this problem seems to happen with both the x86_64 and i386 images
in the imagestore (oddly, the i386 one seems to be listed as x86_64 in
euca-describe-images).
--
x86_64 images should be presented a /dev/sdb, not a /dev/sda2
https://bugs.launchpad.net/bugs/457283
You received this bug notifi
** Also affects: eucalyptus
Importance: Undecided
Status: New
--
x86_64 images should be presented a /dev/sdb, not a /dev/sda2
https://bugs.launchpad.net/bugs/457283
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bu
Just for informational purposes, the way that bug 458850 was fixed, if
updates are done to Eucalyptus such that ephemeral storage is on
/dev/sdb instead of /dev/sda2 ec2-init should correctly adjust.
--
x86_64 images should be presented a /dev/sdb, not a /dev/sda2
https://bugs.launchpad.net/bugs/
** Tags added: uec
--
x86_64 images should be presented a /dev/sdb, not a /dev/sda2
https://bugs.launchpad.net/bugs/457283
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://
Fixing bug 458850 is needed to work around this issue in the instance
itself.
** Changed in: eucalyptus (Ubuntu)
Status: Confirmed => Triaged
--
x86_64 images should be presented a /dev/sdb, not a /dev/sda2
https://bugs.launchpad.net/bugs/457283
You received this bug notification because
I can confirm this.
fstab says /dev/sdb.
But I do have /dev/sda2.
I am able to mount /dev/sda2, but it is formatted ext2.
The kvm command line on the node is:
root 9680 1 0 Oct20 ?00:07:53 /usr/bin/kvm -S -M
pc-0.11 -m 256 -smp 1 -name i-39AE0679 -uuid 8f8c4f4c-bbdb-
e95a-c88
13 matches
Mail list logo