Daniel, I was aware of DataSourceAzure.py and cc_mounts.py and the fact that built-in config for Azure requires declaration of "sdb" (and not "ephemeral0"). The before mentioned fact is only an inconvenience for users that would like to declare custom mount points and make the mistake to use an in incorrect reference to the ephemeral disk (i.e. not declaring "sdb"). The misdeclaration will only result in the ephemeral disk not being mounted, that should not be a real issue.
However, the above reveals a (minor) bug in cc_mounts.py. The cfg mnt array in the cc_mounts.py script is sanitized, in such a fashion that default mounts are only added if other entries do not have the same device name (see lines 285 - 307). A declaration of [ sdb, <mount point> ] or [ sdbX, <mount point> ] (in case of partitions) in custom cloud config settings will not result in an append of the ephemeral0 default mount (since the device name remains the same) and that is good. After all, when declaring [ sdb, <mount point> ] or [ sdbX, <mount point> ] (in case of partitions), cc_mounts.py will append device "/dev/sdb" or "/dev/sdbx" (in case of partitions) to the cfg mnt arry, instead of the default mount declarations for ephemeral0. This is really cumbersome, when using partitions and certainly when using swap (dedicated) partitions. The bug is (in essence) that the sanitizing in cc_mounts.py does not prevent that the standard alias "/dev/sdb", as specificied in DataSourceAzure.py, or any other declared aliases will be appended to the cfg mnt array, which should not occur, if these aliases are pointing to one and the same ephemeral disk. The (minor) bug can be easily resolved by sanitizing for aliases in cc_mounts.py. I was (also) aware that cc_mounts.py contains the declaration ["swap", "none", "swap", "sw", "0", "0"] in the default set of mounts and that DataSourceAzure.py does not have to contain any reference to swap or mount points thereof. However, the "accidental" declaration of [ swap, <mount point or "None"> ] reveals a bug, that occurs even when a declaration of the form [ sdb, <mount point> ] is provided in cloud-config settings. The bug is, in my humble opinion, (solely) related to the following lines of code in cc_mounts.py: for line in actlist: # write 'comment' in the fs_mntops, entry, claiming this line[3] = "%s,%s" % (line[3], comment) if line[2] == "swap": needswap = True if line[1].startswith("/"): dirs.append(line[1]) cc_lines.append('\t'.join(line)) with these lines of code stating that any device called swap (or /dev/swap, since that is the same in cloud-init) a) will mount, as a result of if line[1].startswith("/"): dirs.append(line[1]) if only if - the declaration is of form [ swap, <mount point> ] AND - the device called swap actually exists, for instance as a result of the existence of swap partitions AND - the swap partition is declared first in the disk_setup cloud-config settings, b) will not mount, as a result of (taking into account defvals = [None, None, "auto", "defaults,nobootwait", "0", "2"]) if line[2] == "swap": needswap = True if the declaration is of form [ swap, <"None"> ], with the missing fields hence being replaced by appropriate values from defvals, hence implying that line[2] == "swap" never applies, c) will not mount properly, if the declaration is of form [ swap, <"mount point or None">, swap ], d) will not mount at all, if the declaration is of form ["swap", "none", "swap", "sw", "0", "0"], due to sanitizing in cc_mounts.py, and one could therefore come to the obvious conclusion that the bug is related to the definition of defvals. However, the obvious conclusion is not appropriate in this case. In essence, one should not be able to declare [ swap, <"mount point or None"> ] (or similar) at all (!). Furthermore, a declaration for swap only makes sense when using swap partitions, but swap partitions are not desirable at all. Moreover, the cloud-init versions 0.7.6 and 0.7.7 already allow for the creation of swap files. In short, the bug can and should be resolved by sanitizing (i.e. ignoring) any declarations of the form [ swap, <mount point> ] and [ swap, <"None"> ] or similar, hence also implying that even the [ swap ] declaration has no function in case of sanitizing. In my humble opinion, the "swap" bug can and should be resolved quickly. Kind regards..... -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/1410835 Title: Azure ephemeral disk and custom mount points To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1410835/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs