[02:10] <blackboxsw> minimal: waldi jchittum thx for discussion on the resize2fs breakage ubuntu saw on recent Lunar image updates GCP and Azure. it turns out 5.15 and 5.19 kernels were missing an upstream kernel patch which was reordering when checksums are being updated in the kernel, the upgrade to e2fsproges 1.47.0 exposed this issue with trying to re-run resize2fs  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2003816. fixes in flight
[02:10] -ubottu:#cloud-init- Launchpad bug 2003816 in cloud-init (Ubuntu Jammy) "Regression in ext4 during online resize" [Undecided, New]
[02:11] <blackboxsw> and holmanb too :)
[02:12] <blackboxsw> not sure if we closed out status here of the debugging effort/triage/fix that canonical folks put into it.
[02:12] <blackboxsw> jchittum: we're dropping a bit in our roadmap for better warning awareness for cloud-init so folks don't have to egrep 'Traceback/WARNING' /var/log/cloud-init.log that should help
[02:13] <blackboxsw> *should help making warnings more conspicuous from testing
[10:48] <caribou> Hello, I have a user-oriented question : if a netplan (i.e. network v2) config is added to cloud-init's user-data, should it get merged into /etc/netplan/50-cloud-init.yaml ?
[10:54] <SDes91> Hi all, I am creating an image for raspberry pi 4 and have the respective cloud-init file in the partitions. I am using packer to make the image file and using ansible to provision the image using chroot before hand. I was curious whether there is a way to trigger cloud-init in the chroot stage so that the image is already ready when I put the
[10:54] <SDes91> image on the sd card and boot up the pi. In classic case, cloud-init will only configure itself when it detects it is first boot.
[10:57] <meena> caribou: I'm not sure User-data can have network configuration at all
[10:59] <meena> SDes91: what's cloud-init doing in this scenario that packer / Ansible can't, or that you feel is wasted work on the first boot?
[11:00] <SDes91> well certain things like user creation. I have `user-data` file which creates for me users. that I will use to add to the docker group etc. I am not sure if one can create users in chroot.
[11:01] <meena> sure you can
[11:01] <meena> but you can also use Ansible to do it
[11:03] <SDes91> I have been facing some errors when it comes to apt when I try to provision the image in chroot via ansible. so I backtraced and used simple bash scripts instead at the moment.
[11:04] <meena> yeah, so, with apt in chroot, you want to configure it such that it doesn't autostart services
[11:04] <meena> otherwise it gets nasty to clean up
[11:05] <meena> chroot is a pure Filesystem namespace, it *contains* nothing else. processes escape into the global namespace and it's hard to keep them apart from the system's processes 
[11:14] <SDes91> I see. Would you happen to know within ansible apt module if there is a parameter that will not autostart services? I generally do `DEBIAN_FRONTEND=noninteractive` with shell scripts but I don't think that helps
[11:15] <SDes91> Ah maybe policy-rc.d might help
[11:17] <meena> yeah that one should be easy
[11:22] <SDes91> Also a related question to the network renderers for cloud-init. I am creating QEMU images for x86_64 ubuntu images and have placed the `network: version: 2 renderer: NetworkManager` into the respective /etc/netplan directory when emulating via qemu packer. The final image looks great but I cannot get network interfaces to show up in the virtual
[11:22] <SDes91> image (on Hyper-V after converting the qemu image).
[18:14] <blackboxsw> caribou: right network config can't be specified in user-data as user-data can't get processed  until after initial network config is consumed written from either the datasource metadata, the  filesystem @ /etc/cloud/cloud.cfg.d/* or kernel cmdline https://cloudinit.readthedocs.io/en/latest/reference/network-config.html#default-behaviour
[18:26] <blackboxsw> SDes91: just providing a supplemental /etc/netplan/10-perfer-networkmanager.yaml with ` network: version: 2 renderer: NetworkManager`  may not be enough because ubuntu images order cloud-init.service After=systemd-networkd-wait-online.service, but not After=NetworkManager-wait-online.service. Most ubuntu serve rimages aren't shipped with NetworkManager.service. So cloud-init.service starts up beore NetworkManager brings up nics.
[18:29] <blackboxsw> SDes91, if we are talking about manipulating custom Ubuntu desktop images with NetworkManager installed, then you'd likely need some sort of systemd Drop-in for cloud-init.service unit definition to allow two things, Adding an `After=NetworkManager.service` to the [Unit] defintion and dropping 'Before=sysinit.target`so that cloud-init can be ordered after NetworkManager.service (which is ordered After=dbus.servce sysinit.target)
[18:31] <blackboxsw> SDes91, I'm touching this same systemd NetworkManager ordering space currently in ubuntu's livecd-rootfs https://code.launchpad.net/~chad.smith/livecd-rootfs/+git/livecd-rootfs/+merge/439586 that will start getting reviews shortly