Two more things to note
1.) I just opened bug 672986 that euca-bundle-vol should copy uuid
2.) above, I stated that grub2 loads the kernel on uec and pv-grub. It may
have similar issues.
** Description changed:
- Binary package hint: cloud-init
+ Binary package hint: grub-legacy-ec2
I
Two more things to note
1.) I just opened bug 672986 that euca-bundle-vol should copy uuid
2.) above, I stated that grub2 loads the kernel on uec and pv-grub. It may
have similar issues.
** Description changed:
- Binary package hint: cloud-init
+ Binary package hint: grub-legacy-ec2
I
I tried the same steps and did not get /dev/sdh as the root, but I see
that they do both have the same label, and concur that labels may not be
the best way to differentiate these volumes.
UUID also isn't unique, so I'm at a loss to identify a good way to
determine which is which.
Either way,
EBS volumes and snapshots create this sort of problem regularly for me,
generally with conflicting duplicate XFS UIDs which I have to override.
The best solution for EC2 AMIs may be to always accept that /dev/sda1 is
the boot disk.
--
attaching a volume to maverick instance may boot off it
On Sat, 6 Nov 2010, Eric Hammond wrote:
EBS volumes and snapshots create this sort of problem regularly for me,
generally with conflicting duplicate XFS UIDs which I have to override.
The best solution for EC2 AMIs may be to always accept that /dev/sda1 is
the boot disk.
Well, I chose to
I tried the same steps and did not get /dev/sdh as the root, but I see
that they do both have the same label, and concur that labels may not be
the best way to differentiate these volumes.
UUID also isn't unique, so I'm at a loss to identify a good way to
determine which is which.
Either way,
EBS volumes and snapshots create this sort of problem regularly for me,
generally with conflicting duplicate XFS UIDs which I have to override.
The best solution for EC2 AMIs may be to always accept that /dev/sda1 is
the boot disk.
--
attaching a volume to maverick instance may boot off it
On Sat, 6 Nov 2010, Eric Hammond wrote:
EBS volumes and snapshots create this sort of problem regularly for me,
generally with conflicting duplicate XFS UIDs which I have to override.
The best solution for EC2 AMIs may be to always accept that /dev/sda1 is
the boot disk.
Well, I chose to
--
attaching a volume to maverick instance may boot off it
https://bugs.launchpad.net/bugs/665235
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
