Bug 1298234 - systemd-nspawn container fails to boot for the first time when --link-journal=try-guest is used
systemd-nspawn container fails to boot for the first time when --link-journal...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: systemd-maint
Depends On:
  Show dependency treegraph
Reported: 2016-01-13 10:04 EST by Frantisek Sumsal
Modified: 2017-08-03 03:51 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Frantisek Sumsal 2016-01-13 10:04:38 EST
Description of problem:
First nspawn container boot fails when --link-journal=try-guest is specified as an argument of systemd-nspawn (which is used in systemd-nspawn@.service file).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. # mkdir -p /var/lib/machines/testvm
2. # yum -y --installroot="/var/lib/machines/testvm" groupinstall "Minimal install"
3. # systemd-nspawn --link-journal=try-guest -bM testvm

Actual results:
# systemd-nspawn --link-journal=try-guest -bM testvm
Spawning container testvm on /var/lib/machines/testvm.
Press ^] three times within 1s to kill container.
Container testvm failed with error code 1.

Expected results:
Container should boot successfully.

Additional info:
Same process works on Fedora 23:

# mkdir -p /var/lib/machines/testvm
# dnf -y --installroot="/var/lib/machines/testvm" --releasever 23 groupinstall "Minimal install"
# systemd-nspawn --link-journal=try-guest -bM testvm
Spawning container testvm on /var/lib/machines/testvm.
Press ^] three times within 1s to kill container.
systemd 222 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to Fedora 23 (Twenty Three)!
Comment 2 M. Scherer 2016-04-21 16:46:46 EDT
So I can reproduce this one, and I can also say this is fixed in Fedora 23.

I suspect this work on the first time due to 8054d749c4ad69503b5b2735864f8e72a1b73e62
Comment 3 M. Scherer 2016-04-21 19:10:01 EDT
So I did took a closer look, because it did bother me a lot, but gdb seems to interfere with systemd nspawn, as my error point to "open_console", and I think that's because i run in gdb. I tried with gdbserver, but also didn't got far.
Comment 4 M. Scherer 2016-04-22 05:51:20 EDT
So the problem likely come from /etc/machine-id failing to be created in the container. 

After using strace properly, i see that it fail with "failed to parse machine-id".

This was likely fixed by e01ff70a77e78.
Comment 5 M. Scherer 2016-04-22 06:29:13 EDT
Ok so the fix/workaround is to run  systemd-machine-id-setup --root, or systemd-firstboot --root.
Comment 6 Michal Sekletar 2016-04-22 08:43:07 EDT
We call systemd-machine-id-setup from systemd %post during rpm installation. Hence /etc/machine-id should be present in the container after yum has finished installing packages.
Comment 7 M. Scherer 2016-04-22 09:04:00 EDT
yeah, but it is silently ignoring all errors. 

systemd-machine-id-setup >/dev/null 2>&1 || :

I just tried again on a centos 7, and the machine-id file is empty.
Comment 8 Michal Sekletar 2016-04-22 10:25:46 EDT
I've backported 8054d749c4ad69503b5b2735864f8e72a1b73e62. Feel free to grab test packages.


Note You need to log in before you can comment on or make changes to this bug.