[Bug 665235] Re: attaching a volume to maverick instance may boot off it

2010-11-09 Thread Scott Moser 
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 booted a maverick instance, modified it a bit, and created a snapshot
  of that volume.
  
  I then, booted another maverick instance like:
  run-instances ami-548c783d --instance-type t1.micro --block-device-mapping 
/dev/sdh=${SNAPSHOT}:${SIZE}
  
  the surprising result was that the instance booted with root = /dev/sdh.
  
  The reason for that is that menu.lst in the instance says:
  kernel  /boot/vmlinuz-2.6.35-22-virtual root=LABEL=uec-rootfs ro 
console=hvc0
  initrd  /boot/initrd.img-2.6.35-22-virtual
  
  In this instance, there were, then 2 filesystems that had LABEL=uec-rootfs.
  The kernel just chose /dev/sdh.
  
  update-grub-legacy-ec2 is what writes the 'LABEL=uec-rootfs'.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: cloud-init 0.5.15-0ubuntu3
  ProcVersionSignature: User Name 2.6.35-22.33-virtual 2.6.35.4
  Uname: Linux 2.6.35-22-virtual x86_64
  Architecture: amd64
  Date: Fri Oct 22 17:19:50 2010
  Ec2AMI: ami-548c783d
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: us-east-1c
  Ec2InstanceType: t1.micro
  Ec2Kernel: aki-427d952b
  Ec2Ramdisk: unavailable
  PackageArchitecture: all
  ProcEnviron:
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  SourcePackage: cloud-init

** Summary changed:

- attaching a volume to maverick instance may boot off it
+ grub-legacy-ec2: attaching a volume to maverick instance may boot off it

** Also affects: ubuntu-on-ec2
   Importance: Undecided
   Status: New

-- 
grub-legacy-ec2: 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
Server Team, which is subscribed to cloud-init in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 665235] Re: attaching a volume to maverick instance may boot off it

2010-11-06 Thread Clint Byrum 
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, this is definitely an undesirable behavior, so I'm marking
this Confirmed.

** Changed in: cloud-init (Ubuntu)
   Status: New = Confirmed

-- 
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
Server Team, which is subscribed to cloud-init in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 665235] Re: attaching a volume to maverick instance may boot off it

2010-11-06 Thread Eric Hammond 
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
https://bugs.launchpad.net/bugs/665235
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Re: [Bug 665235] Re: attaching a volume to maverick instance may boot off it

2010-11-06 Thread Scott Moser 
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 use label because LABEL= is much newer way of booting,
and with UUID even more so.  I would have used UUID, but at the time that
the initial /boot/grub/menu.lst is written in the vmbuilder code, there is
no UUID because the filesystem has not been written yet (its in a chroot).

update-grub-legacy-ec2 is what ends up writing this.  That is largely a
copy of 'update-grub' from the 'grub' package (not grub2).  I
intentionally left as much the same as I could get a way with.  Because of
that, the problem is even further complicated because when
update-grub-legacy-ec2 runs (on kernel installation or dpkg-reconfigure),
it will end up writing with UUID (which is its prefered mechanism).

That behavior was generally OK to me, but can cause other issues (just as
label does) like bug 671427.

/dev/sda1 does seem like the simplest answer, but its not ideal for 2
reasons
a.) /dev/sda1 is really not what the device should be named (we carry a
patch to turn xen pv disk devices from xvdX to sdX)
b.) on UEC (and on openstack) the root device is likely to be named
/dev/vda1.  This is not *really* a problem, as grub2 loads the kernels on
UEC and pv-grub via update-grub-legacy-ec2's /boot/grub/menu.lst does so
on ec2.

So, lost of info there, but thats why its not as simple as it might first
appear.

-- 
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
Server Team, which is subscribed to cloud-init in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs