/srv/irclogs.ubuntu.com/2023/01/06/#cloud-init.txt

falcojrblackboxsw: since you authored #1607, do you have strong opinions on https://bugs.launchpad.net/cloud-init/+bug/1999680 ?16:52
-ubottu:#cloud-init- Launchpad bug 1999680 in cloud-init "Fix remove machine-id" [Undecided, New]16:52
falcojrtruncating the machine-id sounds reasonable to me, but I'm not sure if there are specific use cases that require us to remove the id16:53
blackboxswfalcojr: thanks for the ping I was going through that now trying to figure out why on our LXD images things are working fine .17:02
blackboxswBionic++17:02
blackboxswI just want to find out why it may *not* be working on this other image.17:03
falcojrblackboxsw: I can see it on a bionic vm. Launch ubuntu:bionic --vm , rm /etc/machine-id, reboot18:43
blackboxswstrange as it does work on containers 20:19
blackboxswI'm seeing /etc/machine-id created prior to journal being started up. maybe by dbus: /etc/init.d/dbus via a call to dbus-uuidgen --ensure. But that only resets /var/lib/dbus/machine-id. it doesn't 'publish' the new value up to /etc/machine-id of it's own accord. something else is doing that.... like systemd-machine-id-setup, but I don't see that invoked by any systemd service outside of systemd-machine-id-commit.service20:26
blackboxswon both container and kvm, a trunated /etc/machine-id 'works' and gets regenerated as a new uuid. So, sure I think that is fine for us to do. I'm going to continue poking at the reason why bionic kvm images for lxc  don't t regenerate uuids but bionic containers still do. the timing of the generation of /etc/machine-id is before journald is started on containers, so I'm wondering if lxd is invoking something 20:41
blackboxswI'll also test on other platfroms/clouds20:41
meenablackboxsw: i wonder how 11:56 <meena> oh ho! https://freshbsd.org/freebsd/src/commit/62a149bf621947fb7475c64b1ff04fe19fe16b29 — will affect FreeBSD in the future21:09
meenaMFC one week, that was two weeks ago21:10
blackboxswthanks a lot of the link on that meena and watching out for the conversation. Right, if we opted to allow for a truncated /etc/machine-id file, it'd break BSD which would leave that empty file in tact. 21:14
blackboxsworiginal context on the 'bug' in ubuntu from 8 years ago https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766 21:15
-ubottu:#cloud-init- Launchpad bug 1508766 in systemd (Ubuntu) "/etc/machine-id not created if missing" [Low, Won't Fix]21:15
holmanbblackboxsw: falcojr: truncating makes it not a "first boot" on newer systemd versions21:15
holmanbfrom machine-id(5): 3. If /etc/machine-id exists and is empty, a boot is not considered the first boot.21:16
blackboxswnot considered a first boot (which would likely invoke systemd-firstboot in older cases).21:16
holmanbwhich is a behavior I don't think we want21:16
blackboxsw*older ubuntu series* cases21:17
blackboxswgenerally the cloud-init clean --machine-id is intended for folks trying to generate golden images which should perfrom all system setup from scratch as if it were a "greenfield" (or first time)" vm launch21:18
holmanbsince that would cause units with ConditionFirstBoot=yes to not be run21:18
holmanbthat's what I'm saying - truncating instead of deleting would make --machine-id change to not run those ConditionFirstBoot=yes units on newer systemd versions21:19
falcojrso sounds like our newer bug should be invalid/won't fix and somebody hitting that bug can just manually clear the machine id21:20
holmanbfalcojr: I'd give a +1 to that approach21:21
blackboxswyes a workaround would be for someone to `sudo truncate /etc/machine-id --size 0`. but this has to be peformed by some systemd unit that is not active in bionic kvm images but 'is' active in container images on bionic21:21
holmanbblackboxsw: I don't think that a systemd unit should be required for golden image creation.21:22
blackboxswso I was fruitlessly trying to dig into what is actually triggering the re-generation of /etc/machine-id on boot, as it looks to be either dbus or systemd-machine-id-commit (yet the latter seems inert because it is only invoked with /etc/machine-id is a mount point)21:22
holmanbmaybe I misunderstand 21:22
blackboxswno a systemd unit shouldn't be required for the golden image creation, but I'd like to be able to explain in that won't fix bug why lxc container bionic images properly re-generate the /etc/machine-id across reboot, but bionic kvm images  do not. 21:24
blackboxswso that we can explain to the bug filer what symptom is affecting their environment21:24
holmanbI see21:24
falcojrblackboxsw: that feels beyond our scope21:25
blackboxswfair, though this does affect VMs of both bionic (systemd 237) and focal (systemd 245) it looks like, It doesn't affect jammy vms on (sytsemd 249)21:40
blackboxswso we'll need to be aware that this workaround of trucating is necessary on older systemd versions.21:41
blackboxswholmanb: and right. I confirmed behavior from systemd as far as expectations of 'first boot' https://github.com/systemd/systemd/blob/main/src/core/main.c#L2096-L211321:49
blackboxswso from this terraform case, it is a 'dirty boot' if folks are truncating to 0 length and expecting machine-id to be regenerated21:50
blackboxswwhereas v245 or less systemd doesn't support the "uninitiailized" value for machine-id but treats absence of the file as the same (first boot) schenario https://github.com/systemd/systemd/blob/v245/src/core/main.c#L1873-L188221:54
blackboxswand random https://systemd.io/BUILDING_IMAGES/ suggests the same 22:14
blackboxswanyhow too much time spent on this. I think removing is intended for golden image creation. If someone has an environment that will be reusing those images without a full/first boot, then they likely will either have to `sudo truncate /etc/machine-id --size 0` or `sudo systemd-machine-id-setup` to generate a new uuid on the image just before booting22:16

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!