The underlying justification here is that currently, we are wasting (possibly scarce) entropy at each boot to generate a UUID whose global uniqueness provides no particular value to us because it doesn't persist across reboots (therefore you can't usefully refer to it from elsewhere anyway).
We have two ways to generate a UUID with libuuid: one is to use the system mac address plus the current time, the other is to use a true RNG. The first method presents a chicken-and-egg problem for netplan, because the libuuid implementation only looks at mac addresses of "up" interfaces, which we don't have at the time netplan runs at boot. So we fall back to an RNG, which means each time netplan generates NM config, it gets a different identifier for the connection config. Using serial ids (00000000-0000-0000-0000-000000000001, 00000000-0000-0000-0000-000000000002, ...) may not be optimal because things that *do* generate references to these connections on the system will potentially be referring to different connections with the same ID across reboot. Another option is for netplan to do its own implementation of guaranteed-not-to-collide and *idempotent* UUIDs, so that the same config repeatably produces the same identifier. Suggestion for input to the algorithm: - machine UUID (if available early enough on first boot), or mac address of corresponding network device - mtime of the netplan config file - name of the device (==netplan yaml key) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1727031 Title: use dummy UUIDs for NM; since those would change every boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1727031/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
