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

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.

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

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

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

Thanks.

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.

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.

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

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

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