Mounting device files prevents using systemd-nspawn in mock

Description

The systemd-nspawn functionality in mock is introduced in OVIRT-2031.

When using systemd-nspawn mock uses some kind of a layered FS that is created when it starts and removed when it exits. This is different from the way it works when using chroot where the directory that the chroot is configured in stays around until it is explicitly removed.

mock had an issue where if you tried to bind-mount something into the mock environment, you had to have the mount point ready for it. We worked around this in mock_runner by using the fact the chroot was persistent, going into it and setting up the mount points as needed before actually starting to use it to run the STDCI script.

Since the mock authors were aware of the issue when the implemented the systemd-nspawn functionality, they made mock pre-create mount point in the container as needed. However, they only supported directory mount points, so if we tried to bind-mount a socket we would get en error message failing to mount a socket file on a directory.

We reported this issue to the mock developers as issue #87

Activity

Show:

Barak Korren December 31, 2018 at 8:50 AM

With mock now upgraded on all nodes, we can regard this ticket as done.

Barak Korren June 12, 2018 at 7:34 AM
Edited

Added as a blocker, once mock is upgraded we can close this ticket since mock will now properly create mount points as needed.

Barak Korren June 11, 2018 at 1:29 PM

The fix was included in mock-1.4.10 which was already released to EPEL:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-28fdd00a4b

Barak Korren May 17, 2018 at 8:13 AM

Issue #87 has been resolved with PR #171.

We need to check:

  1. If we can now remove our mount point creation code from mock_runner.

  2. If this paves the way to using systemd-nspawn in mock_runner.

Fixed

Details

Assignee

Reporter

Components

Priority

Created May 17, 2018 at 8:10 AM
Updated August 29, 2019 at 2:12 PM
Resolved December 31, 2018 at 8:50 AM