Bug 927331

Summary: Can you add ConditionCapabilities=CAP_MKNOD to LVM Units so we can run them easier within a container
Product: [Fedora] Fedora Reporter: Daniel Walsh <dwalsh>
Component: lvm2Assignee: LVM and device-mapper development team <lvm-team>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: agk, bmarzins, bmr, dwysocha, heinzm, jonathan, lvm-team, msnitzer, prajnoha, prockai, systemd-maint, zkabelac
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-14 13:12:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Daniel Walsh 2013-03-25 16:54:14 UTC 
Secure containers are blocking the mknod, to prevent easy breakout.  The problem is we are having a difficult time preventing lvm unit files from firing off and generating some ugly messages about not being allowed to mknod.  If you added this flag to your unit file, systemd would not attempt to launch theme when mknod has been removed.
Comment 1 Peter Rajnoha 2013-05-14 13:12:02 UTC 
Well, normal unit files can be disabled if they are not intended for use. As for the problem with lvm2-activation-generator, this should be resolved now with bug #961052 - lvm2-2.02.98-9.fc19.

*** This bug has been marked as a duplicate of bug 961052 ***
Comment 2 Lennart Poettering 2013-05-15 18:16:00 UTC 
One of the goals here is to make Fedora/RHEL boot on bare metal, in a VM and in a container cleanly without any changes on disk, with the same image, and cleanly. That's why manually disabling services sucks, because then the image that boots in a container won't boot on bare metal anymore.