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. > 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.
