On trusty systems (at least), walinuxagent ships the udev rules to produce the devices that cloud-init expects to find. So that isn't the source of this bug.
Instead, the problem is that the Azure data source defaults to using /dev/sdb for ephemeral0 ('disk_aliases': {'ephemeral0': '/dev/sdb'} at [0]). Iff we detect a _fabric-formatted_ (i.e. NTFS) ephemeral disk, then the data source updates this default to instead point at that ephemeral disk (which will, correctly, be /dev/disk/azure/...). This happens fine on every first boot, but on subsequent boots, we don't find a fabric-formatted ephemeral disk (because we reformatted it on first boot), so we don't update the default, so we end up rewriting the mounts to point at /dev/sdb.
(I'll give fixing this some thought, and then comment again with suggestions.)
On trusty systems (at least), walinuxagent ships the udev rules to produce the devices that cloud-init expects to find. So that isn't the source of this bug.
Instead, the problem is that the Azure data source defaults to using /dev/sdb for ephemeral0 ('disk_aliases': {'ephemeral0': '/dev/sdb'} at [0]). Iff we detect a _fabric-formatted_ (i.e. NTFS) ephemeral disk, then the data source updates this default to instead point at that ephemeral disk (which will, correctly, be /dev/disk/ azure/. ..). This happens fine on every first boot, but on subsequent boots, we don't find a fabric-formatted ephemeral disk (because we reformatted it on first boot), so we don't update the default, so we end up rewriting the mounts to point at /dev/sdb.
(I'll give fixing this some thought, and then comment again with suggestions.)
[0] https:/ /git.launchpad. net/cloud- init/tree/ cloudinit/ sources/ DataSourceAzure .py#n57