TLDR: generally for individuals looking to create custom Ubuntu Server golden images, we suggest they start from a stock Ubuntu Server cloud image instead[1] of the subiquity-based Ubuntu Server Live installer images[2].
[1] Ubuntu Server cloud images for 20.04:https://cloud-images.ubuntu.com/releases/focal/release/ [2] Ubuntu Server Live installer(subiquity) images: https://releases.ubuntu.com/20.04/ Sorry for the delay here in response. I wanted to get this bug all the right artifacts given the way that subiquity installer uses cloud-init currently on focal 20.04 to make sure we understand the "why". The primary reason you are not seeing your NoCloud config is because subiquity cloud.cfg.d. artifacts in this case are preventing cloud-init from even detecting DataSourceNoCloud: Check any of: - DataSourceNone detected in /run/cloud-init/status.json - sudo cloud-id # returns none instead of nocloud - sudo cloud-init query v1.platform # none instead of NoCloud Your desire looks to be that you want NoCloud datasource detected instead of "None". The failures you are seeing are expected at the moment though I agree they are not optimal for your use-case. Both cloud-init and subiquity teams are working to iteratively improve this use-case for reuse of golden images for subiquity-installed images. Both cloud-init and subiquity teams are working to improve support for use-cases with subiquity-based installer ISO images to make sure this path is better handled in the future. That said, here's a workaround and some reasoning behind the behavior at the moment. -- workaroud to create golden image on subiquity-installed Ubuntu Server ISOs -- I expect you can "clean up" subiquity artifacts and re-enable cloud-init if you wish to use that manually installed server image as a golden image for cloining: 1. Clean up any cloud-init artifacts to ensure next image boot will be a seen as a greenfield(fresh) cloud-init install sudo cloud-init clean --logs # best-practice to always use on all cloud-init-based golden images 2. Clean up subiquity install config artifacts which had disabled cloud- init in this image: sudo rm -f /etc/netplan/00-installer-config.yaml /etc/cloud/cloud.cfg.d/curtin-preserve-sources.cfg /etc/cloud/cloud.cfg.d/99-installer.cfg /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg The next boot of the machine will have an active cloud-init that should detect the proper datasource config. -- background -- Subiquity uses curtin and cloud-init as tools to accomplish a one-shot install of server images using the cloud-init's DatasourceNone configuration (note "None" not "NoCloud"). There is a tension between the subiquity install use-case and cloud-init which generally tries to inspect whether it needs to re-run across reboots of a system to adapt in the event that instance metadata configuration changes across boot. This is where the rub comes. I believe we want cloud-init to be in a disabled state after a manual Ubuntu Server Live installer(subiquity) because typical human-driven installer configuration is generally for a one-time/unique server deployment, not so much at scale. I'd expect scaled deployments generally to use a more automated or config-driven/script-driven process to create a golden image based on stock Ubuntu server cloud images. -- subiquity install artifacts -- Those using the subiquity Server live installer images (and eventually for Desktop images too) should expect to see some installer configuration artifacts left around by the install process. This is to aid both in future bug triage for subiquity, as well as to ensure cloud-init no longer tries to re-run on those images due to being in disabled state. If you plan to re-use a golden image created from a subiquity-install, expect that you will currently need to remove some of the subiquity install files in order to re-use a fully active cloud-init during image clone or replication. subiquity's installer emits the following cloud-init and networking config artifacts the filesystem of a subiquity-based 20.04 Server Live installed system: 1. /etc/netplan/00_installer.cfg * Subiquity bypasses cloud-init's network rendering since it has network-config input directly via subiquity installer dialog. 2. /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg # because subiquity writes it's own network config direct to /etc/netplan in #1 above 3. /etc/cloud/cloud.cfg.d/99-installer.cfg # Provides subiquity's full NoCloud configuration which includes cloud-config user-data. 4. /etc/cloud/cloud.cfg.d/curtin-preserve-sources.cg # Minor APT-related user-data produced by initial installer choices I think the artifacts #2 and #3 are the biggest issue at play for re-use of subiquity installed images as a golden image: - Any NoCloud metadata you provide is ignored because #3 delivers an override for datasource_list: [None] which means cloud-init will never try to detect NoCloud datasource as viable on this system - Any networking configuration you might provide via config or datasource will get ignored because of #2 which says cloud-init will not render networking Hope that context helps. Please do let us know if the workaround works on your system or any other problems that exist here as we'll endeavour to improve those rough edges. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1958377 Title: cloud-init does not apply network configuration from NoCloud resource To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1958377/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
