On Tue, Feb 23, 2021 at 07:39:17AM -0500, Ashton Fagg wrote: > Claudio Jeker <[email protected]> writes: > > > I'm not sure. vscsi(4) is ready the moment the kernel starts init. So it > > should not result in any problem for iscsid. What made you think this is > > the issue? > > Yeah, so in /var/log/daemon, you see this: > > Feb 20 18:59:28 elara iscsid[52173]: startup > Feb 20 18:59:28 elara iscsid[52173]: fatal in iscsid: vscsi_open: Device busy > > It appears it just dies there. iscsid never actually does anything > beyond that, looking at the log. > > Hence my thinking it can't talk to /dev/vscsi0 when it wants to.
Isn't that the 2nd iscsid that is started? IIRC your pictures showed that once you exited single user mode that another iscsid was started (but maybe I just interpreted the images wrong). > > My assumption is that the initial exchange to get the iscsi session going > > with the target just takes a bit longer than the rc script takes to do the > > fsck. Because of this I think a sleep may be a quick fix. > > I will try the sleep as well. > > > A proper fix would be to block iscsictl until the configured session is > > up. The tricky bit is that at some point a timeout needs to trigger in > > case the target is unavailable. -- :wq Claudio
