@seb128: yes. The two are related in that when /var/lib/dbus/machine-id is a symlink, the act of starting the system dbus instance can't (or wont, I guess) generate a machine-id (as the path in question is there, just the symlink target is missing).
And because of lp:1508697, systemd doesn't inself create /etc/machine-id when missing, which it should. This is an obscure issue in the end, but it's caused problems with the System76 imaging system. I've put a lot of effort into making sure things that should be unique between machines, things that are unique when you do a manual Ubuntu install, are actually unique when we image a system. I used to just delete /var/lib/dbus/machine-id when building our golden image tarballs and let dbus generate the machine-id with dbus- uuid upon first boot. Now I have to generate /etc/machine-id during imaging, before we boot into the installed OS. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1508697 Title: Wily: /var/lib/dbus/machine-id is symlink on desktop, file on server Status in dbus package in Ubuntu: New Bug description: If you do a Wily desktop install, /var/lib/dbus/machine-id is a symlink to /etc/machine-id. If you do a Wily server install, /var/lib/dbus/machine-id is a file containing the same value as /etc/machine-id. Minor issue, but still a weird inconsistency between Ubuntu desktop and server. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
