=== hsmiths1 is now known as hsmiths
=== chris14_ is now known as chris14
=== polymorp- is now known as polymorphic
=== lexandrop_ is now known as lexandrop
=== not_phunyguy is now known as phunyguy
=== Comnenus_ is now known as Comnenus
=== JanC_ is now known as JanC
[09:22] <lnxtx[m]> <samy1028> "I have a copy of a good boot..." <- link doesn't work
[09:24] <lnxtx[m]> <samy1028> "Any thoughts?" <- remove "quiet splash" options from the kernel line; add "nomodeset" option
[09:24] <lnxtx[m]> and try again
=== thegodsq- is now known as thegodsquirrel
=== dbungert1 is now known as dbungert
=== kenoba8 is now known as kenoba
=== JanC is now known as Guest6136
=== JanC_ is now known as JanC
[16:03] <effendy[m]> Does anyone know anything about cloudinit changing its behaviour with the newer cloudimage? SSH server starts before the cloudinit settings are being applied/before the virtual machine is finally rebooted in order for cloudinit to really apply the settings. This has been happening since 20230602 (https://cloud-images.ubuntu.com/jammy/20230602/)
[17:46] <sbeattie> blackboxsw: ^
=== sdeziel_ is now known as sdeziel
=== joepferguson_ is now known as joepferguson
[20:49] <blackboxsw> hrm effendy[m], we don't expect anything to have hit jammy from cloud-init's side this month that would have changed this. If possible can you file a bug including tarfile from `cloud-init collect-logs`describing the issue. 
[20:58] <blackboxsw> ultimately  we'd care about seeing journalctl logs vs /var/log/cloud-init.log to compare timing of openssh vs cloud-init to triage behavior. ... and cloud-init collect-logs tars up these files for us
[20:59] <blackboxsw> effendy[m]: the fact that you mention before the machine is rebooted makes me think you are using a live server or live desktop installer image maybe?
[21:04] <blackboxsw> typically cloud-init settings provided under the `autoinstall:user_data`or `autoinstall:identity` keys in `#cloud-config` are only applied to the target system in live installer ISOs. Typically top-level cloud-config keys outside the `autoinstall` scope apply to the running (ephemeral/installer) environment before reboot.
[21:04] <blackboxsw> So if you have complex needs in early installer time prior to reboot, you may be providing both `autoinstall:indentity` config as well as `ssh_import_id` or something. seeing your user-data an d intent would help understand the problem you have.
[21:21] <effendy[m]> Hi blackboxsw . I'm using exactly the ova image in the installer which I import in vsphere. These are only servers. I'm not making any changes to autoinstall (I did use that before switching to ova templates).
[21:21] <effendy[m]> I meant to say, I'm using the ova images in the link above.
[21:22] <effendy[m]> The difference between 20230524 and  20230602 is very clear. In the first one, the virtual machine doesn't boot completely – I just see services loading and similar things. Then it restarts and it boots fully and the SSH server is also available.
[21:24] <effendy[m]> The cloud-init config file I'm using is quite simple and just ensures some authentication for Packer, which eventually connects to the VM over SSH to install stuff through ansible. So I wouldn't say there's anything complex going on in the early stages.
[21:27] <effendy[m]> And just to be clear again: the virtual machines reboots in both versions. What is being started is just different in this intermediary phase. I'm providing the cloud-init through vApp (vSphere), available only for ova templates (at least as far as I know).
[21:27] <effendy[m]> Then I guess I should fine a bug on launchpad (?)
[21:27] <effendy[m]> file*
=== JanC is now known as Guest340
=== JanC_ is now known as JanC
[21:37] <blackboxsw> effendy[m]: if possible upstream cloud-init is in github so https://github.com/canonical/cloud-init/issues
[21:39] <effendy[m]> Sure, I'll try to do it tomorrow. Thanks.
[21:41] <blackboxsw> effendy[m]: if possible please check cloud-init version in both 20230524 vs 20230602 images (I'll do the same my side in the meantime) we didn't publish any different version of cloud-init.during this timeframe so I'm expecting oit
[21:41] <blackboxsw> I'm expecting it is something different than cloud-init
[21:42] <effendy[m]> Yeah, I did check it, then I deleted the file where I wrote it :D (I'll check again), but it did seem to be the same version, indeed.
[21:42] <effendy[m]> I deleted the file with of the cloudinit version of the newer image, 'cause I only had that etc. :)
=== Serge is now known as hallyn