cloud-init's cc_mounts module has outdated assumptions
holmanb opened this issue · comments
Bug report
Various issues:
Cannot handle disk labels
Disk labels are commonly used today since the /dev/sdX name is not deterministic and the /dev/disk/by-uuid/ffffffff-ffff-ffff-ffff-ffffffffffff is long (and likely also kernel-specific). Cloud-init assumes that the first field must be a disk, which is not true.
Cannot handle devices created after cc_mounts runs
This is the documented and expected behavior, but it doesn't work well in under parallelized int systems where devices may appear later in boot.
Presumably this device checking was done as a safety pre-flight check for users which provide invalid fstab entries, to prevent users from creating fstab entries that would cause the system to not boot.
A workaround has been proposed, and is blocked currently due to CLA/legal reasons. This workaround simply adds a timeout for devices to appear. While this may work around the issue temporarily, the solution is non-deterministic and inherently broken.
Cloud-init should handle a more dynamic early userspace environment gracefully.
Cannot handle multi-device mounts
On some multi-device filesystems, a single device may exist in the first column of an fstab entry, with other devices represented as options (btrfs). When a single device is sufficient (mirroring, raid), and that device is available but not the device in the fstab field, cloud-init's behavior is incorrect since it may prevent such a line from being added.
This is really the same issue as the last section, but a different manifestation of the issue.
Link for context on the azure special sauce