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
Server Team, which is subscribed to eucalyptus in Ubuntu.
** 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
Server Team, which is subscribed to eucalyptus in Ubuntu.
** 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
Server Team, which is subscribed to
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
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
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
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
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
** 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
Server Team, which is subscribed to eucalyptus in
** 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
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs mailing list
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
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-
13 matches
Mail list logo
