[07:18] <Moha> Hi; 1. I get different network names for network interfaces on different nodes, as in: [eno1, eno2, ...] on baremetals, [ens160, ens192, ...] and [enp6s18, enp6s19, ...] on virtual machines. How this names are generated? what does "o" stand for in `enoX`? Why Kernel is using 160,192,224,... in `ensX`interfaces and not simply ordered numbers? What about `enp6sX`?
[08:12] <ravage> Moha: https://wiki.debian.org/NetworkInterfaceNames
[09:37] <jdarnley> Is there a way to force systemd-networkd to configure an interface without putting it up in a manner similar to adding an address with iproute2 `ip`?
[09:37] <jdarnley> ens1f0np0        DOWN           192.168.38.44/24
[09:37] <jdarnley> ens1f1np1        DOWN           <blank>
[09:39] <jdarnley> The output of `ip -br a`  The top one is done with ip directly but the second one is a .network file with ActivationPolicy
[09:40] <jdarnley> Why is there a difference?  And can I make it more similar?
[10:05] <guesswhat[m]> Hello, question, how can I mount apt state folder to docker container and run python3-apt from container to get info about packages from host? Thanks
[11:56] <Moha> ravage: tnx
[14:06] <guesswhat[m]> anyone https://askubuntu.com/questions/1480426/run-apt-package-manager-from-container-with-host-data ?
[14:28] <falcojr> dbungert: I added a comment to #2022102: https://bugs.launchpad.net/subiquity/+bug/2022102/comments/6
[14:28] -ubottu:#ubuntu-server- Launchpad bug 2022102 in subiquity (Ubuntu Jammy) "subiquity fails to see autoinstall data conveyed by cloud-init 23.2" [Critical, Fix Committed]
[14:29] <falcojr> if the ephemeral and snapped versions of cloud-init don't always contain the same version, I think we still have issues
[15:20] <dbungert> falcojr: thanks for the ping.  The version of subiquity on the candidate channel I have verified as fixed.  We are prepping the RC this week and it will have this fix.  Snap promotion has to be done carefully or we offer an unintended version to existing Jammy installer users.
[15:25] <Odd_Bloke> Am I right in thinking that gcc SRUs land in -security so they can be used to build future -security packages?
[15:25] <rbasak> Odd_Bloke: yes: https://wiki.ubuntu.com/StableReleaseUpdates#Toolchain_Updates
[15:26] <Odd_Bloke> rbasak: Thanks!
[15:26] <rbasak> Odd_Bloke: np. Though I'm concerned that there's no tooling we have to actually enforce that.
[15:26] <rbasak> I wouldn't be surprised if accidents in this regard have happened or does happen in the future.
[15:26] <falcojr> dbungert: verified the two issues mentioned in the comment? I just installed subiquity candidate and I see 23.1.1. I don't think that's going to be compatible with the ds-identify in 23.2.*
[15:33] <dbungert> falcojr: that doesn't match what I saw.  As part of RC prep I will ensure this is resolved.
[15:36] <falcojr> dbungert: thanks!
[18:57] <dbungert> falcojr: so I came back around to testing this, was able to do a sample autoinstall with the 22.04.3 daily and subiquity from the candidate channel.  in that snap is version 23.2.1 of cloud-init.  May I ask what you did for your candidate test?
[18:59] <falcojr> dbungert: Sorry, I misunderstood then. I had done a "snap install subiquity --candidate --classic" and looked at the c-i version inside the snap
[18:59] <falcojr> what's the right way to get the current candidate?
[19:00] <dbungert> hmm, that should have produced the same result.  I think that's a valid method, just don't recommend leaving it installed on a system you care about.
[19:01] <falcojr> I could have done something wrong. Let me double check
[19:01] <dbungert> you can also "snap download" to just get the snap without the complications of having it installed
[19:03] <falcojr> it was in an lxd container just to check the version, so no harm done, but good to know
[19:03] <falcojr> yeah, now it's 23.2.1. I must have missed --candidate or something before. Sorry for the noise
[19:03] <dbungert> np, thanks for confirming.  And glad to hear you did it in a container, just didn't want to have it on a real system and forgotten!