[10:19] <abc33> Hi all How can I set Timos configuration in user-data?
[14:08] <holmanb> abc33: Welcome o/
[14:11] <holmanb> abc33: What is Timeos? I don't see any mention of it in a quick grep of the codebase, so I would imaging you're probably going to want to use runcmd/bootcmd if using builtin modules.
[17:22] <blackboxsw> falcojr: I think daily recipe builds broke on my recent changes for schema. https://launchpadlibrarian.net/603670335/buildlog_ubuntu-kinetic-amd64.cloud-init_22.2-3259-ga918e9e2-0ubuntu1+1968~trunk~ubuntu22.10.1_BUILDING.txt.gz
[17:22] <blackboxsw> falcojr: if you are not working it, I'll fix it. It's a unittest problem now that our versions schema doesn't use relative file paths
[18:39] <blackboxsw> https://github.com/canonical/cloud-init/pull/1486 put up for review for daily package build failures
[18:39] <ubottu> Pull 1486 in canonical/cloud-init "test_schema: no relative $ref URLs, replace $ref with local path" [Open]
[20:34] <mrf> Hi, im testing cloud-init for Ubuntu 22.04 LTS , the section "package: [fail2ban, unzip, htop]" didnt work. Checking official doc looks like its ok. Anyone got same issue?
[20:37] <blackboxsw> mrf: 'package:' is not a known key in the schema. https://cloudinit.readthedocs.io/en/latest/topics/modules.html#package-update-upgrade-install
[20:37] <blackboxsw> you need packages
[20:37] <blackboxsw> as you are missing an 's
[20:38] <blackboxsw> cloud-init schema is permissive and still allows for passing invalid/unknown keys as far as schema validation. Though we plan to tighten that to strict in the future to warn earlier about invalid/typo'd  schema
[20:38] <mrf> sorry misspelling typeing
[20:38] <blackboxsw> it happens to all of us
[20:39] <mrf> lets try again ... test 15 :P
[20:39] <blackboxsw> generally I'd like to be able to add a `--strict` parameter to `sudo cloud-init schema --annotate system` that would tell you about errors there in misspelled top-level keys. Any keys below a top-level key should have properly reported as an error in user-data though
[20:41] <mrf> thanks ! blackboxsw
[20:41] <blackboxsw> certainly
[21:01] <mrf> blackboxsw are u there? Im getting the same error : can you take a look? -> https://gyazo.com/77ed5468936d900b9447cc1f67a5aa68
[21:06] <blackboxsw> mrf looks like you are using the live-server installer from the logs you linked. I see exit code 100 in those logs. which generally (from APT) implies an APt error of sorts  such as APT lock being held by another process
[21:07] <blackboxsw> I wonder if something else is installing packages at the same time as curtin trying to install fail2ban package?
[21:07] <mrf> mmm
[21:08] <mrf> https://gyazo.com/c6102bcfe8d5d7e6f9f418d4beac300d
[21:08] <mrf> my cloud-init is quite simple i think so
[21:09] <blackboxsw> so, your clod-init contains "packages: [fail2ban...]" right? and the installer itself is also specifying a postinstall/install_fail2ban script?
[21:10] <blackboxsw> on the failed target machine, I'd like to see as much of `sudo cloud-init query userdata` as we can. Be wary if you have any passwords etc in that userdata
[21:12] <mrf> https://gyazo.com/849f571be39d08d8f74a3f9ebe011ba7
[21:12] <mrf> we just got a test password for this test
[21:13] <blackboxsw> mrf: good I was just going to warn you about the leak
[21:13] <mrf> yeah :=
[21:14] <blackboxsw> so cloud-init userdata you provided is installing the packages, and calling apt_update itself. So, I'm not sure why the subiquity installer environment is also trying to install_fail2ban too. It seems like this would be the exit 100 collision you are experiencing
[21:15] <blackboxsw> I'm looking through subiquity/live-server installer code now to see if I can grasp what is triggering that curtin-based system-install call
[21:16] <blackboxsw> mrf: looks like here https://github.com/canonical/subiquity/blob/main/subiquity/server/controllers/install.py#L227
[21:17] <blackboxsw> mrf: a shot in the dark, if you drop the `package_upgrade: true` from your userdata if you don't hit this problem
[21:18] <blackboxsw> if that is even possible given your install choices.  (I didn't catch whether you specified this userdata directly via autoinstall yaml or whether you manually went through the live-server installer dialogs
[21:18] <mrf> mmm let me check removing `package_upgrade: true`
[21:19] <mrf> we're trying develop a custom pxe server for our company
[21:19] <blackboxsw> +1 that makes sense mrf
[21:42] <mrf> im getting the same error
[21:43] <mrf> without `package_upgrade: true`
[21:49] <mrf> mm found this in the log : ERROR subiquity.common.geoip:119 geoip lookup failed
[21:51] <mrf> ok , im retard ... this airgapped network doesnt have acces to internet
[21:51] <mrf> then is unable to download all
[21:53] <blackboxsw> mrf: heh, it always comes down to the physical layer :) that'd do it, blocking unable to get access to the internet
[21:54] <mrf> :P  thanks for help blackboxsw
[21:55] <blackboxsw> glad we could debug a bit. I was worried about some timing collisions w/ live-installer invoking package installs at same time as cloud-init user-data being exec'd, but maybe not the case there.