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. | 13:15 |
---|---|---|
Mister_X | Hello | 15:40 |
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:41 |
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:42 |
minimal | you'll need to indicate which DataSource you're using (NoCloud?) and provide the configuration and/or logfile to illustrate the problem | 15:43 |
Mister_X | http://paste.debian.net/1318886/ | 15:44 |
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:45 |
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:46 |
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:47 |
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:48 |
Mister_X | so, where should I put it? | 15:49 |
minimal | configuration and user-data are 2 different things | 15:49 |
minimal | you put the user-data wherever the DataSource you are using expects it | 15:50 |
minimal | this differs between DataSources | 15:50 |
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:51 |
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:52 |
minimal | a file beginning "#cloud-config" is a user-data FILE not a cloud-init config file | 15:53 |
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:54 |
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:55 |
minimal | the 1st file *without* the "#cloud-config" line is a valid config file | 15:57 |
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:58 |
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? | 15:59 |
Mister_X | (as in the first file) | 16:00 |
minimal | or you could just have a single file by adding the "datasource_list: [ None ]" line to your new file instead | 16:01 |
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:02 |
Mister_X | ok, thanks | 16:03 |
Mister_X | (I need to keep the first one) | 16:03 |
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:04 |
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:05 |
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:06 |
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:09 |
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:13 |
Mister_X | yes. However, validating the second file tells me it's missing the #cloud-config at the top | 16:14 |
minimal | what exact command are you using to validate? | 16:16 |
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:17 |
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:18 |
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:19 |
minimal | the same for meta-data and network-config also | 16:20 |
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:21 |
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:22 |
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:23 |
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:24 |
minimal | https://blog.oddbit.com/post/2015-03-10-booting-cloud-images-with-libv/ | 16:25 |
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:27 |
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:28 |
minimal | normally you use cloud-init with a pre-existing image (i.e. that has cloud-init already installed) | 16:29 |
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:32 |
Mister_X | I had started using a preseed, and needed cloud-init to get docker stuff | 16:36 |
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:37 |
Mister_X | thanks for the resources btw | 16:38 |
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 | 16:55 |
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:32 |
Mister_X | and there is nothing in the log file that say why | 17:33 |
minimal | Mister_X: perhaps if you provided a logfile (via a pastebin or equivalent) that might help diagnose things | 17:38 |
Mister_X | http://paste.debian.net/1318900/ (cloud-init.log) and http://paste.debian.net/1318901/ (cloud-init-output.log) | 17:51 |
minimal | Mister_X: did you see the WARNING in the logfile? | 17:57 |
minimal | ah, I see it also appeared on console (from cloud-init-output.log) also | 17:59 |
Mister_X | So I guess instead of putting None in the datasource in the first file, I could put nothing | 18:00 |
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:01 |
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:02 |
minimal | it only shows "init-local" and "init" running, I'd expect to also see "modules:config" and "modules:final" | 18:04 |
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:05 |
Mister_X | Let me paste that file and the list of files inside that directory | 18:06 |
Mister_X | http://paste.debian.net/1318905/ | 18:07 |
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:08 |
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:09 |
minimal | so I guessing that the cloud-config.service and cloud-final.service have not been enabled | 18:11 |
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:14 |
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:15 |
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:16 |
minimal | check the cloud-config.service perhaps? | 18:17 |
Mister_X | http://paste.debian.net/1318908/ | 18:18 |
Mister_X | should I file a bug report? | 18:19 |
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:21 |
Mister_X | how would I do that? I checked journalctl, and there are no logs for either of them | 18:23 |
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:24 |
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:27 |
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:30 |
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:32 |
minimal | s/cloud-config. /cloud-config.target/ | 18:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!