[07:37] <caribou> blackboxsw: thanks for the precision
[09:39] <shind> is there a way to use "ca_cert" trusted but from an existing file instead of having an inline certificate?
[09:39] <shind> the scenario is to use "bootcmd" and call "aws secretsmanager get-secret-value", parse it, save it as a crt file and then install it using the ca_cert.
[09:39] <shind> i know i can just use the built-in linux command of updating the ca but i wanted to check it cloud_init supports reading from files
[10:40] <meena> sh…
[16:07] <surfzoid> hi
[16:07] <surfzoid> I'm trying to build a deb of my qt project on launchpad, locally on m RPI400 it compil perfect, but sound like launchpad don't manage well rpath : https://launchpadlibrarian.net/657995979/buildlog_ubuntu-kinetic-amd64.qtvsplayer_1.0.39-0~202303271523~ubuntu22.10.1_BUILDING.txt.gz i'm a pure noob with deb and launchpad, is there a easy workaround in the deb files?
[16:20] <minimal> surfzoid: that doesn't appear to have anything to do with cloud-init
[16:21] <surfzoid> minimal: i see i see it too late sorry
[18:46] <sbraz> hi, i just filed this bug downstream for fedora 37 but i thought maybe someone here had an idea of how to avoid this kind of problems with NICs taking a long time to come up → https://bugzilla.redhat.com/show_bug.cgi?id=2182173
[18:46] -ubottu:#cloud-init- bugzilla.redhat.com bug 2182173 in Fedora "cloud-init-local.service fails with 'Unable to find a system nic' with some Mellanox NICs" [Medium, New]
[18:47] <meena> sbraz: which Mellanox NICs? what DataSource?
[18:48] <sbraz> meena: connectx-4/5, NIC details are in the bug report, datasource is a configdrive
[18:50] <sbraz> meena: but i don't think the issue is specific to this nic model, it's more of a "how to ask cloud-init to start when the NICs are actually available" question, and i don't really know
[18:55] <minimal> seems like your change to re-add the udev-settle is the right way
[18:55] <sbraz> minimal: i just don't understand why i'm not hitting this issue with e.g. debian 11 which doesn't use udev settle
[18:55] <sbraz> gotta run, i'll read all this later/tomorrow, thanks for the feedback :)
[18:55] <minimal> (or equivalent that isn't deprecated)
[18:57] <minimal> sbraz: when comparing Fedora and Debian I assume they are both not using the same kernel version, same versions of other software - i.e. too many variables to properly compare
[19:10] <waldi> sbraz: AFAIK, fedora shuffles around when they run stages
[19:11] <waldi> early boot is not stable and cloud-init got some problems there anyway
[23:19] <sbraz> waldi: what do you mean exactly?
[23:19] <sbraz> minimal: that's the thing, i don't know that there is a non-deprecated equivalent
[23:42] <minimal> sbraz: I don't use systemd so can't suggest any alternative to udevadm settle
[23:43] <minimal> I'm guessing different MLX cards take different amounts of time to initialise (e.g. some of them are IB only, some support IB and ethernet). It's been a while since I've played with MLX kit
[23:44] <minimal> I just remember some cards using mlx4 driver and others using mlx5 lol
[23:54] <sbraz> minimal: it really is a matter of seconds, the connectx-3 using mlx4 is fine for instance; maybe i could try to move the driver to the initramfs to speed up its loading time, i'll check
[23:56] <minimal> sbraz: that might reduce the likelyhood of the race condition but it's unlikely to guaranteed its elimination
[23:57] <minimal> I was using MLX cards with cloud-init and don't remember this sort of problem....but that was 5+ years ago lol
[23:59] <sbraz> yeah the correct fix is to wait for nics to be ready, and that's it, no hack or anything