I am working on setting up a wifi only enabled automated install from a usb stick with the user-data and meta-data provided by the NoCloud datasource to cloud-init. I’ve observed a few issues. First lesson, if you modify any of the information in /etc/os-release or /etc/lsb-release, then you may possibly break cloud-init when it checks for devices with the cidata label. It’s best to take a look at those files in a non modified running system and make sure if you do modify them, they don’t have any unquoted funny white spaces. Second lesson, cloud-init doesn’t do nearly enough path sanitation. If you give the kernel seedfrom a value that doesn’t end with a os.sep value, then cloud-init just blindly will join this with the filenames, resulting in a failure. Why cloud-init decided to go with a seedfrom value of a directory for NoCloud, I have no clue? Who cares about verbosity on something that no-one other than us poor lonely sys admins will read anyway? Thirdly, I couldn’t get cloud-init to detect a separately mounted vfat volume with the cidata label. I had to resort to methods similar to the script from covertsh and others that puts the user-data and meta-data in a modified unsquashed filesystem. Unfortunately, even when I did that, and cloud-init seemingly loaded my datasource (as evidenced by logging the mydata variable from the _get_data func in /lib/python3/dist-packages/cloudinit/sources/ DataSourceNoCloud.py) when subiquity starts to run, for some unknown reason, the seedfrom value which was only moments earlier recognized, is rejected, and the installer craps out and puts me back in the live installer. I have no hypothesis as of now why that happens. Why and exactly when cloud-init needs to modify files in /var/lib/cloudinit and in /run/cloudinit is beyond me. But, presumably, knowing when these paths are written to would go a long way in easing my pain.
As a side note, I ran the live server installer and manually added the ubuntu-desktop package with --no-install-recommends, and I get what I want, just without wifi. Of course, adding the wpa_supplicant package and its dependents missing from the live server iso works fine, that is, I get internet connectivity but only through this extra unfortunate manual step.
What you might ask do I want to achieve? Well, what I want to achieve for my small office is a lan accessible service that provides custom isos for download. Employees can simply write to usb and plug in to get their base system. No, I don’t want netboot, because I actually do want these usb sticks, not provisioning directly to the eventual host machine.