On 03/29/2017 03:31 PM, Harald Dunkel wrote: > I agree about mounting configfs in the init script, but please > note that /sys/kernel/config *is* mounted early at boot time. > Its just not available yet.
No, it isn't mounted early at boot time, at least not from sysvinit, due to a bug (see below). > Maybe the LSB header is bad, or the timeout in rtslib-fb-targetctl > has to be increased. So apparently something else mounts configfs in your case that is run in parallel to LIO. But the LSB headers of targetctl clearly indicate that it's a standard service that's run _way_ later than early-boot services, even after $remote_fs - so /etc/init.d/mountkernfs.sh will definitely have been run already at that point. The problem with mountkernfs.sh in sysvinit is that it will only mount configfs if /sys/kernel/config exists, which will only exist if the configfs module is loaded, which will only happen after mountkernfs.sh is started on sysvinit. (systemd in contrast loads modules before mounting things such as configfs nowadays; it also got that wrong in the past though.) This bug in sysvinit (or more accurately the initscripts package) is the bug I referenced: https://bugs.debian.org/840356 If in your case after boot configfs is mounted anyway, there's another service that does that for you. Could you grep for configfs in /etc/init.d? You'll probably fine something other than targetctl or mountkernfs.sh that will mount it at a later point in boot - but that's definitely not something I'd rely on. The proper way to fix this is to fix the initscripts package to load modules before mounting configfs. Since targetctl is not an early-boot service, ordering will automatically be correct then and your use case will work. However, that's something you'll have to take up with the sysvinit/initscripts maintainers, because it clearly is a bug in those packages. (Actually, this is the first time I've looked at the targetctl init script, and the loop in there waiting for configfs to be mounted really should NOT be there, that is just plain wrong. configfs availability should be done via ordering, not waiting in the packground for stuff to start - because that really is non-deterministic. And the ordering is actually correct already; the other package that mounts configfs in the init script is buggy in my eyes because it does something it should not, as well as sysvinit for not properly mounting configfs in the first place.) The only "workaround" would be to mount configfs ourselves in the targetctl init script, but to me this really not advisable, because if something else is already mounting configfs in the background, then the mount command could be issued twice - which shouldn't happen, and can cause some unexpected issues (appearing in /proc/mounts or /proc/self/mountinfo twice for the same mount point could break some scripts that don't expect that, for example. And since the mount command being issued twice depends on a race condition, this would be non-deterministic and very difficult to debug). Regards, Christian
