[13:15] <norrland> Regarding FreeBSD on cloud. I'm working on providing FreeBSD in our cloud offering. Waiting for the growfs zfs related patch to be released and tested until I can ship the zfs template.
[15:40] <Mister_X> Hello
[15:41] <Mister_X> I'm using cloud-init with 2 custom config files. It runs one of them, but doesn't run the other (and the logs suggest it has read it but that's all).
[15:41] <Mister_X> I've validated the file and cloud-init tells me it's ok
[15:42] <minimal> what exactly do you mean by "2 custom config files"?
[15:42] <Mister_X> files that I've written myself
[15:42] <Mister_X> let me show you
[15:43] <minimal> you'll need to indicate which DataSource you're using (NoCloud?) and provide the configuration and/or logfile to illustrate the problem
[15:44] <Mister_X> http://paste.debian.net/1318886/
[15:45] <minimal> so you're using the "None" DataSource
[15:45] <minimal> so how are you providing the configuration?
[15:45] <Mister_X> yes
[15:45] <Mister_X> and that's the second file: http://paste.debian.net/1318887/
[15:46] <Mister_X> what do you mean providing the configuration? I just need it to run the second file
[15:46] <Mister_X> I'm using it with debian, and I'm not changing the default config
[15:46] <minimal> how do you expect cloud-init to know about the 2nd file?
[15:47] <Mister_X> I've put both of them in /etc/cloud/cloud.cfg.d
[15:47] <Mister_X> the issue is the second file isn't executed and I'm not sure what I'm doing wrong
[15:47] <minimal> indeed where is the 1st file also? generally setting the datasource_list is done in /etc/cloud/cloud.cfg or a file inside /etc/cloud/cloud.cfg.d/ directory
[15:47] <Mister_X> in the same directory
[15:48] <Mister_X> they're both in /etc/cloud/cloud.cfg.d
[15:48] <Mister_X> the first one is called 90_nods.cfg, and the second one 99_docker.cfg
[15:48] <Mister_X> (just in case, file permission seem good, they both have the same permissions)
[15:48] <minimal> the 2nd file appears to be user-data but generally (or at all?) user-data is not placed in /etc/cloud/cloud.cfg.d/
[15:49] <Mister_X> so, where should I put it?
[15:49] <minimal> configuration and user-data are 2 different things
[15:50] <minimal> you put the user-data wherever the DataSource you are using expects it
[15:50] <minimal> this differs between DataSources
[15:51] <minimal> hmm, the "None" does DO talk about putting user-data in config.cfg or cloud.cfg.d/*. I didn't know that, I've never used None
[15:51] <minimal> s/does/docs/
[15:51] <Mister_X> I'm kinda lost now. I'm running this on an Ubuntu 24.04 (host), and the guest is a debian 12.
[15:52] <Mister_X> cloud-init is on debian12
[15:52] <minimal> however they refer to specifying user-data there via "userdata_raw"
[15:52] <Mister_X> I'm even more lost
[15:52] <minimal> did you read the docs on the None DataSource? https://cloudinit.readthedocs.io/en/latest/reference/datasources/none.html
[15:53] <minimal> a file beginning "#cloud-config" is a user-data FILE not a cloud-init config file
[15:54] <Mister_X> I haven't seen that. I assumed that simply placing the file with runcmd in the directory would make it run it
[15:54] <minimal> as I said there is a difference between config files and user-data files
[15:54] <minimal> you're trying to use user-data files in the config directory
[15:55] <minimal> you can embed user-data inside a config file using "userdata_raw:"
[15:55] <Mister_X> I merely added the first one to make it stop trying to get metadata
[15:57] <minimal> the 1st file *without* the "#cloud-config" line is a valid config file
[15:58] <minimal> cloud-init always uses a DataSource, normally it tries to autodetect which one(s) are available. You can avoid this automatic select by specifying a specific DataSource, which is what you have done to use "None"
[15:59] <Mister_X> so, if I understand correctly the page you linked, my second file should be replaced with http://paste.debian.net/1318889/ ? Should it still be next to the None datasource?
[16:00] <Mister_X> (as in the first file)
[16:01] <minimal> or you could just have a single file by adding the "datasource_list: [ None ]" line to your new file instead
[16:02] <minimal> but do not put "#cloud-config" in any file in /etc/cloud/cloud.cfg or /etc/cloud/cloud.cfg.d/*
[16:02] <Mister_X> I just need the second file to be run once, and then never again. My idea was to delete it at the end. Unless there is a better way to do this
[16:03] <Mister_X> ok, thanks
[16:03] <Mister_X> (I need to keep the first one)
[16:04] <minimal> well normally meta-data includes an instance-id and as long as this doesn't change then things shouldn't be run more than once
[16:04] <minimal> why do you need to keep the 1st file?
[16:05] <Mister_X> so that it doesn't keep trying to get the metadata (and keep retrying for a long time) which is delaying boot
[16:06] <minimal> so I think you want to add "instance-id: <random value>" to the "metadata:" section of your 2nd file
[16:06] <minimal> "so that it doesn't keep trying to get the metadata" - why doesn't putting the datasources_list entry into the 2nd file INSTEAD not resolve this?
[16:09] <Mister_X> it feels like it's better to keep things separate, as I'm doing 2 different things: stop getting metadata, and running a few commands
[16:09] <Mister_X> So, here is the resulting 2nd file: http://paste.debian.net/1318890/
[16:13] <minimal> I guess that instance-id value is valid, I can't find any docs on its format, normally it is a UUID
[16:13] <minimal> did you remove the "#cloud-config" line from the 1st file?
[16:14] <Mister_X> yes. However, validating the second file tells me it's missing the #cloud-config at the top
[16:16] <minimal> what exact command are you using to validate?
[16:17] <Mister_X> cloud-init schema --config-file ${filename}
[16:17] <minimal> that only supports validating either cloud-config (i.e. user-data) network-config files
[16:18] <minimal> files in /etc/cloud/ are NOT cloud-config or network-config files
[16:18] <minimal> "cloud-init schema" currently does not support validating configuration files
[16:19] <Mister_X> since you're saying user data shouldn't be in /etc/cloud. Where should it ideally be?
[16:19] <Mister_X> I mean, where does cloud-init expects it?
[16:19] <minimal> that depends on the particular DataSource
[16:20] <minimal> the same for meta-data and network-config also
[16:21] <Mister_X> in the case of None, it expects it as a raw string in a file in /etc/cloud/cloud.cfg.d?
[16:21] <minimal> isn't that what the docs for None say?
[16:21] <Mister_X> yes, I just wanted to confirm I understand correctly
[16:21] <Mister_X> I'm completely new to cloud-init
[16:22] <minimal> what are you running the VM with cloud-init on?
[16:22] <minimal> i.e. using libvirt/virtd? qemu command-line? ProxMox? some other hypervisor?
[16:23] <Mister_X> libvirt
[16:23] <Mister_X> I'm using an ubuntu 24.04 for now
[16:23] <Mister_X> with libvirt
[16:23] <minimal> normally I'd expect you would use the NoCloud DataSource rather than None
[16:23] <Mister_X> I'm using a debian preseed to configure the VM, and cloud-init to pull docker stuff
[16:23] <minimal> and I believe libvirt supports NoCloud
[16:24] <Mister_X> NoCloud, if I understand correctly expects a web server, doesn't it?
[16:24] <minimal> no
[16:24] <minimal> typically it expects a ISO or filesystem containing YAML files for meta-data, user-data, and optionally network-config
[16:25] <minimal> https://blog.oddbit.com/post/2015-03-10-booting-cloud-images-with-libv/
[16:27] <Mister_X> I'm using virt-install at this time
[16:27] <Mister_X> to install the system with a preseed. In the example, they're importing an existing cloud image
[16:28] <Mister_X> that will be useful when I'll try the cloud images
[16:28] <minimal> https://sumit-ghosh.com/posts/create-vm-using-libvirt-cloud-images-cloud-init/
[16:29] <minimal> normally you use cloud-init with a pre-existing image (i.e. that has cloud-init already installed)
[16:32] <minimal> so why don't you use the stack Debian cloud-images and provide a NoCloud ISO containing your runcmd as part of the user-data?
[16:32] <minimal> s/stack/standard/
[16:36] <Mister_X> I had started using a preseed, and needed cloud-init to get docker stuff
[16:37] <Mister_X> I've tried running docker in the preseed but it's too limited. I could get everything mounted (cgroups, procfs, but it still failed due to networking issues and I couldn't find a solution
[16:37] <Mister_X> so I decided to use cloud-init to do that part
[16:37] <Mister_X> once the system rebooted
[16:38] <Mister_X> thanks for the resources btw
[16:55] <minimal> isn't cloud-init a bit of overkill for that? you could just create a shell script to be run on first boot via systemd to do that
[17:32] <Mister_X> seems like it. It sounded like a good idea until I ran into issues.
[17:32] <Mister_X> Even with the modified file as I showed you, it's not running it
[17:33] <Mister_X> and there is nothing in the log file that say why
[17:38] <minimal> Mister_X: perhaps if you provided a logfile (via a pastebin or equivalent) that might help diagnose things
[17:51] <Mister_X> http://paste.debian.net/1318900/ (cloud-init.log) and http://paste.debian.net/1318901/ (cloud-init-output.log)
[17:57] <minimal> Mister_X: did you see the WARNING in the logfile?
[17:59] <minimal> ah, I see it also appeared on console (from cloud-init-output.log) also
[18:00] <Mister_X> So I guess instead of putting None in the datasource in the first file, I could put nothing
[18:01] <Mister_X> but that still doesn't explain why the second file isn't run despite being read
[18:01] <minimal> I'm not sure. That output does saw to file a bug...
[18:01] <minimal> also you logfile seems incomplete - this is from cloud-init running automatically during boot?
[18:01] <Mister_X> yes
[18:02] <Mister_X> it's complete, it's the whole thing
[18:02] <Mister_X> unless cloud-init truncated the file
[18:02] <Mister_X> but I gave the full files
[18:04] <minimal> it only shows "init-local" and "init" running, I'd expect to also see "modules:config" and "modules:final"
[18:05] <minimal> are there "cloud_config_modules:" and "cloud_final_modules:" lines in either /etc/cloud/cloud.cfg or some file in /etc/cloud/cloud.cfg.d/*
[18:06] <Mister_X> Let me paste that file and the list of files inside that directory
[18:07] <Mister_X> http://paste.debian.net/1318905/
[18:08] <minimal> ok, they're there as expected. So all I can assume is that some of the cloud-init systemd services have not been enabled...
[18:09] <Mister_X> http://paste.debian.net/1318906/
[18:09] <Mister_X> if the service hasn't been enabled, then how did it start at boot?
[18:09] <minimal> I said services, plural
[18:09] <minimal> there are multiple services
[18:11] <minimal> so I guessing that the cloud-config.service and cloud-final.service have not been enabled
[18:14] <Mister_X> they are: http://paste.debian.net/1318907/
[18:14] <minimal> then I'd expect to see their output in cloud-init.log
[18:15] <Mister_X> is there any way to debug why that didn't happen?
[18:15] <minimal> cloud-config.server is what would handle the "runcmd" in your user-data so as that service isn't apparently being run (correctly) then that explains why your runcmd commands don't execute
[18:16] <Mister_X> would you like a copy of the preseed file and virt-install command so you can reproduce?
[18:16] <minimal> nope, I don't use libvirt here
[18:17] <minimal> check the cloud-config.service perhaps?
[18:18] <Mister_X> http://paste.debian.net/1318908/
[18:19] <Mister_X> should I file a bug report?
[18:21] <minimal> well you should 1st work out why the service doesn't appear to run cloud-init - it would be a cloud-init bug if cloud-init was being run but having problems
[18:21] <minimal> check the systemd journal etc to see why systemd does not appear to run the cloud-init "config" and "final" stages
[18:23] <Mister_X> how would I do that? I checked journalctl, and there are no logs for either of them
[18:24] <Mister_X> I grepped the logs for the whole journalctl to find cloud stuff, and there is nothing
[18:24] <minimal> that's systemd diagnosis/debugging, not specific to cloud-init
[18:24] <Mister_X> do you have any pointed to the docs about that part?
[18:24] <minimal> systemd docs/manpages? lol
[18:27] <Mister_X> I knew that, but I was wondering if you knew already where to look
[18:27] <minimal> I don't use systemd as my usual init system...
[18:30] <minimal> basically if the cloud-config.server runs cloud-init ok then I'd expect to see more lines at the end of the cloud-init.log you provided, beginning with "util.py[DEBUG]: Cloud-init v. 22.4.2 running 'modules:config' at ..."
[18:30] <minimal> s/server/service/
[18:32] <minimal> so it could be an issue with the cloud-config.service, or on one of the other things it depends on/runs after such as network-online.target and cloud-config. or snapd.seeded.servicetarget
[18:33] <minimal> s/cloud-config. /cloud-config.target/