[08:22] hello all [08:23] i have a probelm about cloud-init [08:24] the init-local and init are success, but the config and final are not excuted [08:25] i need our group help === hjensas|afk is now known as hjensas === bswinnerton7 is now known as bswinnerton [14:27] spotted a behaviour with the Ec2 data source which could be argued whether or not its a bug - basically if you boot a c-i enabled image on KVM/Qemu where the Ec2 DataSource happens to be enabled then a dmi-related warning appears in the cloud-init.log but also on the console during boot. Basically with KVM/QEMU /sys/class/dmi/id/systemuuid doesn't exist and if you don't have "dmidecode" installed then the Warning is triggered [14:28] only the Ec2 DataSource triggers this [14:29] s/systemuuid/system_uuid/ [14:53] minimal: that sounds expected ... Ec2 configures instance system UUID to start with 'ec2' ... and cloud-init needs to read that to identify it's booting on Ec2 [14:54] there are exactly two ways of reading system_uuid that I know of, sysfs and dmidecode [14:55] Azure and a few other datasources also use DMI fields, not system_uuid, but machine or some other value that the hosting provider sets... [14:55] w.r.t your booting under KVM and no sys/class/dmi do you have a custom kernel it may not have enabled the sysfs dmi attributes [15:17] rharper: yes, the issue is that if dmidecode is installed there is no warning but if dmidecode is not installed there is a warning, despite the fact that system-uuid does not exist in both cases. [15:18] its not missing /sys/class/dmi on KVM, its specifically missing /sys/class/dmi/id/system-uuid [15:20] other providers like Azure do check system-uuid but do so after other checks (which then "abort") and so don't hit this issue [15:37] minimal: so the system-uuid read out of sysfs is from /sys/class/dmi/id/product_uuid which, may not be set by default in qemu ,, you can construct the command line qemu-system-x86-64 -smbios type=1,uuid=$UUID ... this will show up in table Type 1 as the UUID field, which should map to the /sys/class/dmi/id/product_uuid value in the guest sysfs [15:44] falcojr: You manually added the Vultr changelog lines in each release branch, I assume? [15:44] falcojr: In case you didn't see, by the way, I've requested changes on the hirsute branch. [15:45] Odd_Bloke: yes, I manually added the changes [15:47] falcojr: And you saw cherry-pick conflicts too, I assume, in the .po[t]? timestamps? [15:48] yes, I thought(?) I resolved those [15:49] falcojr: Yep, I'm ensuring I can replicate what you produced as part of my review. [16:22] falcojr: I'm wondering if we want to fix this in impish as ubuntu2 and then use that as the "base" version in the SRU? [16:25] Odd_Bloke: what do you mean by base version? Like how would fixing it there as a new version impact the rest of the SRU? [16:26] falcojr: As in, fix it in impish, then s/ubuntu1/ubuntu2/ in the SRU branches. [16:26] (I'm working on the impish fix right now.) [16:28] why would the SRU branches take ubuntu2 if they never had ubuntu1? [16:28] s/they never had/we never released [16:29] Semantically, we're expressing that we're backporting the ubuntu2 version in the devel release. [16:30] speaking of the .po files, I wanted to check why the translations have been lost across releases [16:30] "21.2-3-g899bfaa9-0ubuntu2~20.10.1" is saying "this is the first backport of 21.2-3-g899bfaa9-0ubuntu2 to 20.10" [16:31] falcojr: https://github.com/canonical/cloud-init/pull/900 [16:33] approved [16:33] https://github.com/canonical/cloud-init/commit/bdfb4dabaea72adef196b99eda770a72c2e8decd [16:33] this is the commit that dropped the translations at some point [16:34] so we have a populated debian/po directory in the ubuntu/xenial branch, an empty one in ubuntu/bionic, and now an almost-empty one in ubuntu/devel [16:35] well now I see why Scott did it: the templates were only about the removed grub package [16:35] so I think it's all good