/mnt not mounted, swap not used, disk is xvde

Bug #784937 reported by Scott Moser on 2011-05-19
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
Medium
Scott Moser
Oneiric
Medium
Scott Moser
linux (Ubuntu)
High
Stefan Bader
Oneiric
High
Stefan Bader

Bug Description

Binary package hint: cloud-init

in current oneiric instances:
$ cat /etc/fstab
  /dev/sda2 /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
  /dev/sda3 none swap sw,comment=cloudconfig 0 0
$ cat /proc/partitions
major minor #blocks name

 202 65 10485760 xvde1
 202 66 156352512 xvde2
 202 67 917504 xvde3

/mnt doesn't get mounted and swap doesn't get used.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu8
ProcVersionSignature: User Name 2.6.39-2.7-virtual 2.6.39-rc7
Uname: Linux 2.6.39-2-virtual i686
Architecture: i386
Date: Thu May 19 01:20:27 2011
Ec2AMI: ami-10d72979
Ec2AMIManifest: ubuntu-images-testing-us/ubuntu-oneiric-daily-i386-server-20110518.manifest.xml
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: m1.small
Ec2Kernel: aki-407d9529
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

Scott Moser (smoser) wrote :
Scott Moser (smoser) on 2011-05-19
Changed in cloud-init (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Scott Moser (smoser) wrote :

Just some more data, collected from oneiric builds of 20110601 (Ubuntu 2.6.39-3.10-virtual 2.6.39)

i386-t1.micro:
 block-device-mapping: {'ami': '/dev/sda1', 'ephemeral0': '/dev/sdb', 'root': '/dev/sda1'}
 /proc/partitions: xvde1

i386-m1.small-ebs:
 block-device-mapping: {'ami': '/dev/sda1', 'ephemeral0': '/dev/sda2', 'root': '/dev/sda1', 'swap': 'sda3'}
 /proc/partitions: xvde1 xvde2 xvde3

i386-m1.small-instance:
 block-device-mapping: {'ami': 'sda1', 'ephemeral0': 'sda2', 'root': '/dev/sda1', 'swap': 'sda3'}
 /proc/partitions: xvde1 xvde2 xvde3

amd64-m1.large-ebs:
 block-device-mapping: {'ami': '/dev/sda1', 'ephemeral0': '/dev/sdb', 'root': '/dev/sda1'}
 /proc/partitions: xvde1 xvdf

amd64-m1.large-instance:
 block-device-mapping: {'ami': 'sda1', 'ephemeral0': 'sdb', 'ephemeral1': 'sdc', 'root': '/dev/sda1'}
 /proc/partitions: xvde1 xvdf xvdg

So, it looks like basically the kernel is starting its enumerating with xvde.

Scott Moser (smoser) wrote :
tags: added: iso-testing
Scott Moser (smoser) wrote :

Below are logs of the iso testing for alpha-1 oneiric. As you can see, they span types and regions. Note, we saw *zero* occurrences of the bug on ebs root instances. I suspect that ebs root is significantly slower disk than instance store.

ap-northeast-1 amd64 m1.large instance: http://tinyurl.com/65gxrow
ap-northeast-1 amd64 m1.large instance: http://tinyurl.com/66be68r
ap-northeast-1 amd64 m1.large instance: http://tinyurl.com/69lq5et
ap-northeast-1 amd64 m1.xlarge instance: http://tinyurl.com/6xjgbm4
ap-northeast-1 i386 m1.small instance: http://tinyurl.com/673tt7t
ap-northeast-1 i386 m1.small instance: http://tinyurl.com/697ac9p
ap-northeast-1 i386 m1.small instance: http://tinyurl.com/6dpcmze
ap-southeast-1 amd64 m1.large instance: http://tinyurl.com/3b5yl32
ap-southeast-1 amd64 m1.large instance: http://tinyurl.com/44lxegj
eu-west-1 amd64 m1.large instance: http://tinyurl.com/3ere8dv
eu-west-1 amd64 m1.large instance: http://tinyurl.com/3lenkbz
eu-west-1 amd64 m1.large instance: http://tinyurl.com/3zff6ba
eu-west-1 amd64 m1.xlarge instance: http://tinyurl.com/3skf2cu
eu-west-1 i386 m1.small instance: http://tinyurl.com/5sluemm
eu-west-1 i386 m1.small instance: http://tinyurl.com/62gk5o5
eu-west-1 i386 m1.small instance: http://tinyurl.com/63usrlr
us-east-1 amd64 m1.large instance: http://tinyurl.com/3toj7yr
us-east-1 amd64 m1.large instance: http://tinyurl.com/3toj7yr
us-east-1 amd64 m1.large instance: http://tinyurl.com/6fz3orh
us-east-1 amd64 m1.large instance: http://tinyurl.com/6ld2tat
us-east-1 amd64 m1.xlarge instance: http://tinyurl.com/3sfbrqx
us-east-1 i386 m1.small instance: http://tinyurl.com/44kq8hv
us-east-1 i386 m1.small instance: http://tinyurl.com/4x7wdtp
us-west-1 amd64 m1.large instance: http://tinyurl.com/3noeq8c

Dave Walker (davewalker) on 2011-07-06
tags: added: server-o-ors
Scott Moser (smoser) wrote :

comment 4 above was not meant for this bug, but rather for bug 791868

Dave Walker (davewalker) on 2011-07-07
tags: added: server-o-rs
removed: server-o-ors
Dave Walker (davewalker) wrote :

@smoser, can you comment on the current status of this bug? What do we need to do to progress?

Thanks.

Scott Moser (smoser) wrote :

We *can* work around this in cloud-init, but I'd rather not.
We currently have some code that decides that if there is no 'sda', and there is 'xvda', then "ephemeral0" should be xvda. We *could* extend that to have the same logic for xvde, but thats even more hacky.

I would rather have the kernel start enumerating at xvda rather than xvde.

Changed in linux (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Stefan Bader (smb) wrote :

I am currently discussing this upstream. My impression is that this may be an intended change to get a sane way of naming the xvd devices when the configuration may mix hd and sd naming. So there is a 4 device offset done in the enumeration of xvd devices for disks named sd? in the configuration. That means hda-hdd become xvda-xvdd and sda, sdb, ... become xvde, xvdf, ...

Before that hda could become xvda and sda as well. Not really sure how it would work when having both.

Stefan Bader (smb) wrote :

Just as some additional background information while there is upstream discussion going on. I am not sure how it will end as yesterday responses rather made hope for getting things back and today there is others rather wanting to preserve the current status.

The main argument is HVM as you can have the IDE disks provided as hd* devices on an emulated controller and at the same time via xvd*. So they want to preserve the first 4 device names for that.

http://xenbits.xen.org/gitweb/?p=xen-unstable.git;a=blob;f=docs/misc/vbd-interface.txt;h=d97c458f14faf81f746d23f0eafb4afe0ca3fa69;hb=HEAD

Changed in linux (Ubuntu Oneiric):
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
Dave Walker (davewalker) on 2011-07-15
tags: added: server-o-ro
removed: server-o-rs
Changed in cloud-init (Ubuntu Oneiric):
assignee: nobody → Scott Moser (smoser)
Stefan Bader (smb) on 2011-07-18
Changed in linux (Ubuntu Oneiric):
assignee: Canonical Kernel Team (canonical-kernel-team) → Stefan Bader (stefan-bader-canonical)
Changed in linux (Ubuntu Oneiric):
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 3.0.0-9.12

---------------
linux (3.0.0-9.12) oneiric; urgency=low

  [ Andy Whitcroft ]

  * [Config] standardise CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
  * [Config] move ECRYPT_FS back to =y for all architectures
    - LP: #827197
  * record the compiler in the ABI and check for inconsistant builds

  [ Leann Ogasawara ]

  * Revert "SAUCE: OMAP: DSS2: enable hsclk in dsi_pll_init for OMAP36XX"
  * Revert "SAUCE: OMAP: DSS2: check for both cpu type and revision, rather
    than just revision"
  * Revert "SAUCE: ARM: OMAP: Add macros for comparing silicon revision"
  * rebase to v3.0.2
  * rebase to v3.0.3
  * Temporarily ignore module check
  * [Config] Set CONFIG_DM_MIRROR=m on amd64, i386, and arm
  * [Config] Set CONFIG_DM_MULTIPATH=m on amd64, i386, and arm
  * [Config] Set CONFIG_DM_SNAPSHOT=m on amd64, i386, and arm
  * [Config] Enable CONFIG_EDAC_AMD8111=m on powerpc
  * [Config] Enable CONFIG_EDAC_AMD8131=m on powerpc
  * [Config] Enable CONFIG_EDAC_CPC925=m on powerpc
  * [Config] Enable CONFIG_EDAC_PASEMI=m on powerpc
  * [Config] Set CONFIG_EFI_VARS=m on amd64 and i386

  [ Stefan Bader ]

  * [Upstream] xen-blkfront: Drop name and minor adjustments for emulated
    scsi devices
    - LP: #784937
  * [Config] Force perf to use libiberty for demangling
    - LP: #783660

  [ Stefano Stabellini ]

  * [Upstream] xen: Do not enable PV IPIs when vector callback not present
    - LP: #791850

  [ Tim Gardner ]

  * [Config] updateconfigs after rebase to 3.0.2

  [ Upstream Kernel Changes ]

  * Not all systems expose a firmware or platform mechanism for changing
    the backlight intensity on i915, so add native driver support.
    - LP: #568611
  * rebase to v3.0.2
  * rebase to v3.0.3
 -- Leann Ogasawara <email address hidden> Mon, 15 Aug 2011 13:35:57 -0700

Changed in linux (Ubuntu Oneiric):
status: Fix Committed → Fix Released
Scott Moser (smoser) wrote :

whoohoo. Fixed Verified:

$ df | grep ^/
/dev/xvda1 8256952 716152 7121372 10% /
/dev/xvda2 153899044 192068 145889352 1% /mnt
$ cat /proc/partitions
major minor #blocks name

 202 1 8388608 xvda1
 202 2 156352512 xvda2
 202 3 917504 xvda3
$ uname -r
3.0.0-9-virtual
$ cat /etc/cloud/build.info
build_name: server
serial: 20110822
$ ec2metadata --instance-type
m1.small

Then, on amd64 m1.large:
$ df | grep ^/
/dev/xvda1 8256952 732596 7104928 10% /
/dev/xvdb 433455904 203016 411234584 1% /mnt
$ cat /proc/partitions
major minor #blocks name

 202 1 8388608 xvda1
 202 16 440366080 xvdb
$ uname -r
3.0.0-9-virtual
$ cat /etc/cloud/build.info
build_name: server
serial: 20110822
$ ec2metadata --instance-type
m1.large

Changed in cloud-init (Ubuntu Oneiric):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers