Comment 16 for bug 1374166

Ben,

The patch lp-1422919-azure-g5_ephemeral.patch does not help, when introducing this patch (alone) in cloud-init.

There seems to be some basic problem with the basic config settings, in the sense that /dev/sdb is always starting as NTFS.

The standard result of the tests are summarized as: checking disks with parted -l does indicate ext4 settings for all disks (even an attached /dev/sdc) after creation, checking disks with fdisk -l indicates that (only) /dev/sdb is a HPFS/NTFS/exFAT device.

Note that at creation time, cloud-init (0.7.5-0ubuntu1.3) is not patched.

A reboot and/or restart of the VM does not make any difference, the standard result remains.

A shut-down/start sequence for the VM, with cloud-init patched (0.7.5-0ubuntu1.3 with lp-1422919-azure-g5_ephemeral.patch), does yield different results:

a) a check with parted -l indicates /dev/sdb being ntfs, (and)
b) a check with fdisk -l indicates (again) that (only) /dev/sdb is a HPFS/NTFS/exFAT device,

and the following varying factors do not have effect:

- disk mount locations (persistently correct across all test situations)
- using aliases (ephemeral0 and devicename ephemeral0.x) for /dev/sdb or using no aliases (/dev/sdb and devicename /dev/sdb1)
- using /dev/sdb table_type: gpt at creation time (not supported by 0.7.5-0ubuntu1.3, but that does not seem to matter)
- the /dev/sdb overwrite at disk_setup (this can be False or True)

Again note that the /dev/sdc disk is a constant factor, passing "parted -l" and "fdisk -l" checks every time.

Also note that exceptions on the standard result are caused by defining a swap partition (fs type 82) on the first part of the disk.

Any definition in the form of layout: [[100,83]] does not help.

In short, cloud-config setting do not change the erratic behavior with respect to /dev/sdb AND the current patch does not either.

In fact, /dev/sdc is well-behaved (as one expects), with the only difference (in old and new cloud-init code) that /dev/sdc is not hindered by standard config settings (in the python scripts).

In fact (again), the erratic /dev/sdb does not change with settings, in a shutdown/start sequence issue still remains (i.e. /dev/sdb returns to ntfs state), while after VM creation a check with fdisk -l indicates that /dev/sdb is a HPFS/NTFS/exFAT device .

All the above suggests that there is one major issue with EITHER standard config settings for /dev/sdb (as present in python code) OR the disk_setup stanza for /dev/sdb.

It would be my guess that the disk_setup stanza (for dev/sdb) is the culprit (since overruling the disk_setup stanza for /dev/sdb does not have any effect AND specific, unsupported terms like "gpt" are ignored fully).

By the way, all the above is a preliminary conclusion, I will have a peek into the code, when I have time.

Your feedback is welcome!

Kind regards.....