[15:51] Hi all. If you don't mind have a question regarding cloud-init + AWS + vendor data. I am trying to add custom configuration to the new Amazon Linux 2023 AMI that uses cloud-init 22.2. The case is absolutely the same as in the bug https://bugs.launchpad.net/cloud-init/+bug/1913461 that should have been fixed in version 22.4, but AWS doesn't have [15:51] that version and I guess won't have it for a while because Amazon linux 2023 uses python3.9. [15:51] In short the case is the following: [15:51] 1. We create custom image based on Amazon Linux 2023 [15:51] -ubottu:#cloud-init- Launchpad bug 1913461 in cloud-init "Need jinja templating in config files" [Wishlist, Fix Released] [15:51] 2. We can't use user-data to the customization, because that will be done by users of the AMI [15:51] 3. So, the best way to add these customization is to use /etc/cloud/cloud.cfg.d/ config file, BUT in the version of cloud-init that we have we can't use jijna placeholders for the Datasource to get meta-data [15:51] 4. At the same time we can't upgrade cloud-init to the latest version [15:51] I want to clarify the possibility to use vendor data in the AWS environment. Is there any way or example how to supply vendor data to AWS instance? Maybe there is a way to put them locally? [15:51] Thanks, [15:56] DP21: unfortunately, vendor data can only be provided by the vendor, which in this case is EC2. It would get fetched directly from their metadata service and not something that can be simulated locally [15:57] if you're creating a custom image, is there a reason you can't upgrade cloud-init within that image? 22.4 works on python 3.9 [16:27] docs Bug? https://github.com/canonical/cloud-init/issues/4229 [16:27] -ubottu:#cloud-init- Issue 4229 in canonical/cloud-init "Broken link to the hacking document" [Open] [16:28] falcojr thanks for the reply. That was my guess. As for the upgrade of cloud-init: [16:28] 1. I am not sure what customizations has AWS added to their build of cloud-init (if any) and what issue that can cause in future [16:28] 2. I was surprised not to found RPM for that particular version of cloud-init. For example at https://rpmfind.net/linux/rpm2html/search.php?query=cloud-init it looks like Fedora (base of Amazon Linux 2023) have skipped versions 22.3 and 22.4. [16:28] But yeah, maybe to build custom rpm is the way [16:29] hi all, I have cloud-init with: mounts: [ [ /dev/sda2, /mnt ], [ /dev/sda1, /mnt/efi ] ], and cloud-init creates the proper fstab our of that config, and then calls `mount -a`. alas, mount -a fails since the /mnt/efi mount point does not exist. [16:30] one solution would be to call for ex. `systemctl start mnt-efi.mount` (for each new mount, instead of mount -a) since that also makes sure the target mountpoint exists [16:31] should I propose a PR on github? [16:31] or is there a better solution [16:31] … the usage of systemctl, would of course be conditional on systemd [16:32] damjan: why does /mnt/efi i not exist? [16:33] minimal: both sda2 and sda1 are empty FSs just created by fs_setup: [16:33] minimal: that doesn't indicate though why a mount of /mnt/efi fails however... [16:34] can you pastebin (or similar) your user-data? [16:34] minimal: `mount -a` doesn't know to create the mount point /mnt/efi [16:34] minimal: sure, https://github.com/gdamjan/archvm-auto-install/blob/main/imds/user-data [16:39] I've never had that sort of problem before with disk_setup/fs_setup/mount [16:44] damjan: let me spin up a VM with similar config that I have used [16:46] ah I see what happens. /mnt/efi is created, BUT then /dev/sda2 is mounted over /mnt so now that's hidden [16:46] damjan: yeah I saw about to suggest that lol [16:47] does /dev/sda2 appear before /dev/sda1 in the /etc/fstab? [16:47] yes [16:47] so I'd expect it to mounted first [16:47] it is [16:48] but the code is a bit weird. I think it creates the targets dir before it tries to mount anything [16:48] oh, right, I thought you meant "mount -a" was doing them in wrong order [16:49] here's the log file https://paste.rs/TTyT7 [16:49] rather it is that cc_mounts is creating /mnt/efi dir before /mnt is mounted? yeah I don't think it is smart enough to cater for that [16:55] damjan: this seems to create each mountpoint dir if it doesn't exist: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_mounts.py#L575 [16:56] however it is before any "mount -a": https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_mounts.py#L582 [16:57] and https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_mounts.py#L606 [16:58] yeah [17:00] do you have an idea what the best approach would be in solving the issue? [17:21] damjan: do the mounts via runcmd instead? (including "rmdir /mnt/efi" before mounting /mnt and "mkdir /mnt/efi" after mounting /mnt) [17:23] yeah I can do that :) [17:59] hm, perhaps cloud-init can use the X-mount.mkdir option [18:04] and forgo its own `mkdir`s [18:04] damjan: that would probably not be supported by BSD and also some Linux distros like Alpine that use Busybox mount [18:06] hey wait, I can add that as the 4th param to mounts: [18:06] minimal: indeed [18:08] I'm going to add a note to the cc_mounts docs about the mount-inside-another-mount issue [18:09] you can mention the `X-mount.mkdir option` for util-linux distros [18:12] ok [18:59] ps. I did test it, and it works, https://github.com/gdamjan/archvm-auto-install/blob/main/imds/user-data#L26 [19:10] alas, I might switch to a script that does explicit sfdisk, it gives me more control on the partitioning [19:16] damjan: for GPT partitions cc_disk_setup is (from memory) using sgdisk not sfdisk [19:17] but it only gives me option for partition size in percentages [19:18] not disputing that, just pointing out that sfdisk is used by it for MBR/BIOS and sgdisk for GPT [19:19] does anything still use MBR? [19:21] meena: BIOS-only systems, also people who want to create non-boot MBR partitioned disks (i.e. less than 2TB) for whatever reason [19:22] I can create a VM with a 2nd disk of 1TB and then decide whether I want it MBR/BIOS or GPT partitioned, either is perfectly valid to do [19:25] sfdisk can do gpt these days, so it's fine [19:42] falcojr Once again thanks for the answer. I built rpm for Amazon Linux 2023 of version 22.4 and can confirm that jinja templates work for cfg files. Also just for the history rpm build on Amazon Linux 2023 fails because fix for the "udev/rules.d" path inside setup.py for Redhat doesn't work properly. AmazonLinux 2023 doesn't have file [19:42] "/etc/redhat-release" that is used to determinate Redhat family for that particular fix. Below is part of setup.py code [19:42] ``` [19:42] if not platform.system().endswith("BSD"): [19:42] RULES_PATH = LIB [19:42] if os.path.isfile("/etc/redhat-release"): [19:42] RULES_PATH = "/usr/lib" [19:42] data_files.extend( [19:42] [ [19:42] ( [19:42] ETC + "/NetworkManager/dispatcher.d/", [19:42] ["tools/hook-network-manager"], [19:42] ), [19:42] (ETC + "/dhcp/dhclient-exit-hooks.d/", ["tools/hook-dhclient"]), [19:42] (RULES_PATH + "/udev/rules.d", [f for f in glob("udev/*.rules")]), [19:42] ( [19:42] ETC + "/systemd/system/sshd-keygen@.service.d/", [19:42] ["systemd/disable-sshd-keygen-if-cloud-init-active.conf"], [19:43] DP21: for multi-line pastes, please use a pastebin service [19:43] paste.ubuntu.com is one [19:43] got it [19:49] minimal: I'm too poor / broke to have ever seen a 2 TB disk [20:19] meena: not even a virtual one? lol [20:46] right, easy `qemu-img create -f qcow2 arch-vm.img 20T` :D [20:48] minimal: nope [20:49] damjan: will i be able to actually fill that on my laptop with 400? G disk space? [20:50] virtually fill it, yupe ;-)