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)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: systemd-maint
qe-baseos-daemons
:
Depends On:
Blocks:
  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:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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):
systemd-219-19.el7.x86_64

How reproducible:
always

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
 +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
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.

http://people.redhat.com/~msekleta/bz1298234/

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