UEC images do not mount ephemeral disk on /mnt at boot

Bug #458850 reported by Thierry Carrez on 2009-10-23
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ec2-init (Ubuntu)
High
Scott Moser
Karmic
High
Scott Moser

Bug Description

Binary package hint: ec2-init

Due to compatibility bugs in Eucalyptus (bug 457281 and bug 457283) UEC images can't automount the /mnt space, which is a common expectation among EC2 users.

We should fix this on the image side (ec2-init ? vmbuilder ?) so that it adapts to what is provided to it (an ext2 /dev/sda2 in UEC case, an ext3 /dev/sda2 or /dev/sdb in EC2 case), rather than using a static fstab.

Related branches

Thierry Carrez (ttx) on 2009-10-23
Changed in ec2-init (Ubuntu):
importance: Undecided → High
status: New → Confirmed
assignee: nobody → Scott Moser (smoser)
Changed in ec2-init (Ubuntu Karmic):
milestone: none → ubuntu-9.10
tags: added: uec-images
Thierry Carrez (ttx) on 2009-10-23
Changed in ec2-init (Ubuntu Karmic):
status: Confirmed → In Progress
Scott Moser (smoser) wrote :

This is just to collect information about ephemeral storage on UEC and
ec2.

on ec2, instance types are described at:
http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?instance-types.html

type | arch | ephemeral disk| mounted ?
-----------------------------------------------
m1.small | i386 | 150G sda2 ___ | sda2 -> /mnt
c1.medium | i386 | 340G sda2 ___ | sda2 -> /mnt
m1.large | amd64| 420G sd[bc] _ | sdb -> /mnt
m1.xlarge | amd64| 420G sd[bcde] | sdb -> /mnt
c1.xlarge | amd64| 420G sd[bcde] | sdb -> /mnt

The above can be summed up as:
if arch is i386, there is a single device, and that is sda2
if arch is amd64, there is more than 1 device, vmbuilder writes /etc/fstab
that mounts the first (sdb) to /mnt

on Eucalyptus, the available ephemeral disks depends on configuration.
The storage available to an instance depends on the configuration of its
instance type. If the configured storage amount is greater than the size
of the root filesystem, then the instance will have access to a partition
in /dev/sda2 that has a size of (config_value - root_size - swap_size).

In all cases on eucalyptus, /dev/sda2 contains an empty ext2 the filesystem.

Some other things to note:
* In all cases UEC and EC2, /dev/sda1 is a filesystem the size of the
  registered image, and is mounted on /
* In EUC, ephemeral storage is a ext2 filesystem. In ec2, it is ext3.
* on ec2, i686 instances have a ~ 1G swap partition on /dev/sda3
* I'm not exactly certain on how swap_size (in Euca) is determined. in
  default config of m1.small, there is ~ 650M partition for swap (663212
  blocks).

Scott Moser (smoser) wrote :

I collected information on ec2 by starting up an instance of each type, and then running:

for host in ${host_list}; do
ssh -i my-key.pem ubuntu@${host} sh < ~/t/fs-info.sh
done 2>&1 | tee output.txt

fs-info.sh is attached here.

Scott Moser (smoser) wrote :

for reference, i'm also attaching output of the above:

Scott Moser (smoser) wrote :

I attached suggested patch for this to bug 458576 "suggested fix".
http://launchpadlibrarian.net/34426390/fix.debdiff

Dustin Kirkland  (kirkland) wrote :

I built and verified Scott's fix. It works properly for me.

I uploaded the patched package. It's now up to the release team to accept this.

:-Dustin

Changed in ec2-init (Ubuntu Karmic):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ec2-init - 0.4.999-0ubuntu7

---------------
ec2-init (0.4.999-0ubuntu7) karmic; urgency=low

  * work around differences in eucalyptus ephemeral mounts (LP: #458850)
  * get 'ec2:' prefix on ssh public key fingerprint (LP: #458576)

 -- Scott Moser <email address hidden> Mon, 26 Oct 2009 16:18:06 -0400

Changed in ec2-init (Ubuntu Karmic):
status: Fix Committed → Fix Released
Scott Moser (smoser) wrote :

The following shows that this did not regress the mounting of /mnt on 20091027 build that included this fix.

$ printf "%s: %s\n" $(wget -O - -q 169.254.169.254/latest/meta-data/ami-id) \
   $(wget -O - -q http://169.254.169.254/latest/meta-data/ami-manifest-path )
ami-cb0ae9a2: ubuntu-images-testing-us/ubuntu-karmic-daily-i386-server-20091027.manifest.xml
$ dpkg-query --show ec2-init
ec2-init 0.4.999-0ubuntu7
$ df -h /mnt/
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 147G 188M 140G 1% /mnt

$ printf "%s: %s\n" $(wget -O - -q 169.254.169.254/latest/meta-data/ami-id) \
   $(wget -O - -q http://169.254.169.254/latest/meta-data/ami-manifest-path )
ami-a50ae9cc: ubuntu-images-testing-us/ubuntu-karmic-daily-amd64-server-20091027.manifest.xml
$ dpkg-query --show ec2-init
ec2-init 0.4.999-0ubuntu7
$ df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 414G 199M 393G 1% /mnt

Scott Moser (smoser) wrote :

Verified on both i686 and x86_64 on
$ uname -m
i686
$ printf "%s\n" $(wget -O - -q http://169.254.169.254/latest/meta-datainstance-type)
c1.medium
$ grep mnt /etc/fstab
/dev/sda2 /mnt ext2 defaults 0 0
$ df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 2465592 52 2340292 1% /mnt
$ dpkg-query --show ec2-init
ec2-init 0.4.999-0ubuntu7

$ uname -m
x86_64
$ printf "%s\n" $(wget -O - -q http://169.254.169.254/latest/meta-datainstance-type)
c1.medium
$ grep mnt /etc/fstab
/dev/sda2 /mnt ext2 defaults 0 0
$ df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 2464592 52 2339340 1% /mnt
$ dpkg-query --show ec2-init
ec2-init 0.4.999-0ubuntu7

$ uname -m
x86_64
$ printf "%s\n" $(wget -O - -q http://169.254.169.254/latest/meta-datainstance-type)
m1.small
$ grep mnt /etc/fstab
/dev/sdb /mnt ext3 defaults 0 0
$ df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 2080592 615612 1360124 32% /

$ uname -m
i686
$ printf "%s\n" $(wget -O - -q http://169.254.169.254/latest/meta-datainstance-type)
m1.small
$ grep mnt /etc/fstab
/dev/sda2 /mnt ext3 defaults 0 0
$ df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 2080592 571304 1404432 29% /

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers