FS#40131 - [systemd] Duplicate machine-id
Attached to Project:
Arch Linux
Opened by Ruben Kerkhof (ruben) - Monday, 28 April 2014, 18:10 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 20 August 2014, 22:35 GMT
Opened by Ruben Kerkhof (ruben) - Monday, 28 April 2014, 18:10 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 20 August 2014, 22:35 GMT
|
Details
Description:
When creating a container with pacstrap, as described in https://wiki.archlinux.org/index.php/Arch_systemd_container, the container contains /etc/machine-id which is the same as /etc/machine-id on the host on which pacstrap is run. This prevents me from using the journal merging feature. This only happens on a KVM virtual machine. A workaround is to remove /etc/machine-id in the container and let systemd generate a new one. This doesn't currently work and just got fixed by upstream commit 984233ceb6dfeecd8b43864795a660a200e4ac78 Digging into this further, when pacstrap installs systemd, the systemd install script calls systemd-machine-id-setup (https://projects.archlinux.org/svntogit/packages.git/tree/trunk/systemd.install?h=packages/systemd&id=0768de1fb8007f267c567123ffa43ecfd86f1e05#n21) IMHO this call should be dropped, so that systemd can do the right thing and create /etc/machine-id on first boot, be it in a container or in a vm. Steps to reproduce: Run pacman on a kvm virtual machine to create a container: mkdir ~MyContainer sudo pacstrap -i -c -d ~/MyContainer base diff /etc/machine-id ~/MyContainer/etc/machine-id Observe that both files are the same. Kind regards, Ruben |
This task depends upon
Closed by Dave Reisner (falconindy)
Wednesday, 20 August 2014, 22:35 GMT
Reason for closing: Fixed
Additional comments about closing: Now using systemd-firstboot instead of s-m-i-s in systemd-216-1
Wednesday, 20 August 2014, 22:35 GMT
Reason for closing: Fixed
Additional comments about closing: Now using systemd-firstboot instead of s-m-i-s in systemd-216-1
But systemd *won't* create this on first boot, so I don't understand why you're proposing this.
Thanks for your fast response.
If I remove /etc/machine-id from my system, systemd certainly creates a new one.
Looking at the code, systemd calls machine_id_setup from main.c
See also this thread on systemd-devel: http://lists.freedesktop.org/archives/systemd-devel/2014-April/018934.html
Seems to me like there's a number of bugs in this code that upstream needs to deal with before we should be getting involved on the distro level.
So forget about my proposed solution, but the bug's still there.
What do you propose for case in which people use pacstrap to create a container? Document that they need to create /etc/machine-id themselves?
As for /etc/machine-id nog being regenerated, I can't reproduce what you're seeing (yet).
I just created a KVM virtual machine based on Arch 2014.04.1 (systemd-211), removed /etc/machine-id and after a reboot /etc/machine-id is there, with the uuid based on the KVM uuid.
I don't understand why this is a problem. systemd-machine-id-setup should be using the random generator to create the machine ID (as per the documentation). If this isn't the case, then talk to upstream.
when not on kvm or in a container.
"If run inside a KVM virtual machine and a UUID is passed via the -uuid option, this UUID is used to initialize the machine ID instead of a randomly generated one. The caller must ensure that the UUID passed is sufficiently unique and is different for every booted instanced of the VM."
Emphasis on "and a UUID is passed via the --uuid option". You also seem to have pointed out to upstream that this particular feature isn't working.
The -uuid option passed to qemu-kvm works just fine, it's the --uuid option passed to systemd-nspawn that doesn't work.