Bug 767432

Summary: configfs not being mounted ahead of targetcli
Product: [Fedora] Fedora Reporter: Andy Grover <agrover>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: gansalmon, itamar, johannbg, jonathan, kernel-maint, lpoetter, madhu.chinakonda, metherid, mschmidt, notting, plautrba, systemd-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 767857 768098 768552 (view as bug list) Environment:
Last Closed: 2011-12-16 13:56:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 767857    
Attachments:
Description Flags
targetcli service file none

Description Andy Grover 2011-12-14 01:15:09 UTC
Created attachment 546497 [details]
targetcli service file

My service (targetcli, service file attached) needs configfs loaded before it is started, but it doesn't appear to be. I can do "systemctl start sys-kernel-config.mount" once the system is up (and then targetcli is happy) but during boot when targetcli is run, configfs isn't mounted.

Another thing -- sys-kernel-config.mount appears *almost* identical to sys-kernel-debug.mount, which IS being properly mounted. sys-kernel-config is a Before for targetcli.service and sysinit.target, but isn't being started.

Please advise.

Comment 1 Michal Schmidt 2011-12-14 01:46:15 UTC
The difference is that debugfs is built-in in the Fedora kernel but configfs is a module. The mountpoint does not exist until the module is loaded.

See if deleting the line "ConditionPathExists=/sys/kernel/config" from sys-kernel-config.mount helps.

Comment 2 Andy Grover 2011-12-14 04:17:26 UTC
That didn't have an effect, but adding /usr/lib/modules-load.d/targetcli.conf containing "configfs" did.

So I can do that, but shouldn't systemd-units really add something to modules-load.d, since it owns the unit that needs the module loaded?

(but then configfs.ko will be loaded even if sys-kernel-config.mount isn't active. Do mount units need a LoadModule or ExecMountPre option??)

Comment 3 Michal Schmidt 2011-12-14 12:45:44 UTC
I don't like userspace having to be aware of what's configured as a module and what's built-in.

One option would be to have the kernel provide the empty /sys/kernel/config mountpoint even without the module loaded (whenever CONFIG_CONFIGFS_FS=m or y).
With the mountpoint available the mount would succeed (the module providing the filesystem implementation would be loaded automatically).

Or just set CONFIG_CONFIGFS_FS=y and move on.

Kay, what do you think?

Comment 4 Michal Schmidt 2011-12-14 13:06:16 UTC
<kay> i don't think that having it as a module makes much sense
<kay> when there are non-exotic users for it
<kay> configfs was supposed to be the counterpart of sysfs
<kay> like a sysfs with commit support
<kay> so we can declare it as 'core', i guess
<kay> all that sounds like fiddling we should avoid and just compile it in
<kay> i think that was what we decided last time we changed some stuff
<kay> if it's exotic, let the package drop a force-load instruction
<kay> if it's common, let's compile it in and forget

Reassigning to kernel to consider setting CONFIG_CONFIGFS_FS=y

Comment 5 Dave Jones 2011-12-15 01:19:14 UTC
done. will be in next build. (3.2.0-0.rc5.git2.3)

Comment 6 Josh Boyer 2011-12-16 13:56:25 UTC
This is fixed in today's rawhide.