is failing. There is specific code in the init-script to handle this case, though.
Would you be able to run
`sudo bash -x /etc/init.d/o2cb start` and attach the log of that output here?
I guess there could be a race between something (I'm not sure what yet) mounting configfs during boot and the init script running check_filesystem and mount.
It looks like (at least) the init-scripts /etc/init.d/mountkernfs.sh and /etc/init.d/target do mount configfs.
I think we should update the o2cb init-script (upstream probably: https://oss.oracle.com/bugzilla/enter_bug.cgi) to handle mount returning 32 (I think that's the correct RC) since it's inherently racy (init is no longer single threaded).
@slesru, would you be willing to file that bug?
Then again, given that ocfs2-tools looks effectively dead upstream, we probably will need to fix it on our own.
It would appear that this check in /etc/init.d/o2cb:
check_filesystem "$FSNAME" "$MOUNTPOINT" && return 2
is failing. There is specific code in the init-script to handle this case, though.
Would you be able to run
`sudo bash -x /etc/init.d/o2cb start` and attach the log of that output here?
I guess there could be a race between something (I'm not sure what yet) mounting configfs during boot and the init script running check_filesystem and mount.
It looks like (at least) the init-scripts /etc/init. d/mountkernfs. sh and /etc/init.d/target do mount configfs.
I think we should update the o2cb init-script (upstream probably: https:/ /oss.oracle. com/bugzilla/ enter_bug. cgi) to handle mount returning 32 (I think that's the correct RC) since it's inherently racy (init is no longer single threaded).
@slesru, would you be willing to file that bug?
Then again, given that ocfs2-tools looks effectively dead upstream, we probably will need to fix it on our own.