| abc33 | Hi all How can I set Timos configuration in user-data? | 10:19 |
|---|---|---|
| holmanb | abc33: Welcome o/ | 14:08 |
| 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. | 14:11 |
| 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 | 17:22 |
| 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] | 18:39 |
| 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:34 |
| 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:37 |
| 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:38 |
| 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:39 |
| mrf | thanks ! blackboxsw | 20:41 |
| blackboxsw | certainly | 20:41 |
| mrf | blackboxsw are u there? Im getting the same error : can you take a look? -> https://gyazo.com/77ed5468936d900b9447cc1f67a5aa68 | 21:01 |
| 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:06 |
| 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:07 |
| mrf | https://gyazo.com/c6102bcfe8d5d7e6f9f418d4beac300d | 21:08 |
| mrf | my cloud-init is quite simple i think so | 21:08 |
| blackboxsw | so, your clod-init contains "packages: [fail2ban...]" right? and the installer itself is also specifying a postinstall/install_fail2ban script? | 21:09 |
| 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:10 |
| mrf | https://gyazo.com/849f571be39d08d8f74a3f9ebe011ba7 | 21:12 |
| mrf | we just got a test password for this test | 21:12 |
| blackboxsw | mrf: good I was just going to warn you about the leak | 21:13 |
| mrf | yeah := | 21:13 |
| 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:14 |
| 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:15 |
| blackboxsw | mrf: looks like here https://github.com/canonical/subiquity/blob/main/subiquity/server/controllers/install.py#L227 | 21:16 |
| 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:17 |
| 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:18 |
| mrf | we're trying develop a custom pxe server for our company | 21:19 |
| blackboxsw | +1 that makes sense mrf | 21:19 |
| mrf | im getting the same error | 21:42 |
| mrf | without `package_upgrade: true` | 21:43 |
| mrf | mm found this in the log : ERROR subiquity.common.geoip:119 geoip lookup failed | 21:49 |
| mrf | ok , im retard ... this airgapped network doesnt have acces to internet | 21:51 |
| mrf | then is unable to download all | 21:51 |
| blackboxsw | mrf: heh, it always comes down to the physical layer :) that'd do it, blocking unable to get access to the internet | 21:53 |
| mrf | :P thanks for help blackboxsw | 21:54 |
| 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. | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!