INQUIRY result too short (5), using 36
Matthew Schumacher
that loads up the modules, logs in, and mounts root on iscsi and all is
well until after the machine is running and I want to connect to another
iscsi target. This causes strange behavior:
1. I can kill iscsid and everything keeps working. I've not seen this
before. In the past I needed to have iscsid running in order to do
anything since root is on iscsi. Anyone know why this is?
2. If try to login to a target right after boot I get:
"iscsiadm: initiator reported error (13 - daemon access denied)"
however, after I restart iscsid I get, "Login to [iface: default,
target: mail, portal: x.x.x.x,3260]: successful" which looks good except
I don't get my scsi disks setup in /dev. Looking at dmesg shows:
scsi2 : iSCSI Initiator over TCP/IP
scsi scan: INQUIRY result too short (5), using 36
This was working fine in slackware 12.1 so the only major difference is
the kernel which is now 2.6.27.7.
Anyone know what is up with this and how to fix it? Is git head stable
enough to try it?
schu
Mike Christie
> I'm setting up open-iscsi on slackware 12.2. I built a initrd image
> that loads up the modules, logs in, and mounts root on iscsi and all is
> well until after the machine is running and I want to connect to another
> iscsi target. This causes strange behavior:
>
> 1. I can kill iscsid and everything keeps working. I've not seen this
> before. In the past I needed to have iscsid running in order to do
> anything since root is on iscsi. Anyone know why this is?
>
You need iscsid to log in, log out, and for error handling (like if you
pull a cable or reboot a target).
You can actually kill iscsid after you have logged in, and you can still
run IO like mount a FS or do run some DB. iscsid is not used for any of
those operations. However, if there was a network problem we would not
be able to relogin and recover from the problem until you restarted
iscsid (if iscsid was on the disk you need to recover then you are
screwed). And if you want to logout of the target, then you would need
to restart iscsid, before logging out.
> 2. If try to login to a target right after boot I get:
> "iscsiadm: initiator reported error (13 - daemon access denied)"
> however, after I restart iscsid I get, "Login to [iface: default,
Do you get the access error when trying to log in from the initramfs,
then do you restart iscsid from there too or do you restart it from
somwhere else?
> target: mail, portal: x.x.x.x,3260]: successful" which looks good except
> I don't get my scsi disks setup in /dev. Looking at dmesg shows:
>
> scsi2 : iSCSI Initiator over TCP/IP
> scsi scan: INQUIRY result too short (5), using 36
>
>
> This was working fine in slackware 12.1 so the only major difference is
> the kernel which is now 2.6.27.7.
The iscsi initiator does not do the scanning. It asks the scsi layer to.
The scsi layer (this where the message about being too short is from)
handle this, so it might be due to a change in upstream kernel.
Or, the initiator could be completely screwed up and could be messing up
packets.
>
> Anyone know what is up with this and how to fix it? Is git head stable
> enough to try it?
>
It is right now.
Matthew Schumacher
> You need iscsid to log in, log out, and for error handling (like if you
> pull a cable or reboot a target).
>
> You can actually kill iscsid after you have logged in, and you can still
> run IO like mount a FS or do run some DB. iscsid is not used for any of
> those operations. However, if there was a network problem we would not
> be able to relogin and recover from the problem until you restarted
> iscsid (if iscsid was on the disk you need to recover then you are
> screwed). And if you want to logout of the target, then you would need
> to restart iscsid, before logging out.
That makes perfect sense, but before when I was testing the second I
killed iscsid and didn't immediately restart it (before the scsi
timeout) I would loose my disk and my machine would panic.
I'll just forget about the old behavior since it could be something I
was doing and move on...
>> 2. If try to login to a target right after boot I get:
>> "iscsiadm: initiator reported error (13 - daemon access denied)"
>> however, after I restart iscsid I get, "Login to [iface: default,
>
> Do you get the access error when trying to log in from the initramfs,
> then do you restart iscsid from there too or do you restart it from
> somwhere else?
I login from initram, then start the machine like this:
/sbin/iscsiadm -m node -T ${ISCSI_TARGET} -p ${ISCSI_PORTAL} -l
echo 0x0100 > /proc/sys/kernel/real-root-dev
mount -o ro -t $ROOTFS $ROOTDEV /mnt
exec switch_root /mnt /sbin/init
I left out a bunch of error checking and other details like umounting
/proc, but you get the idea.
Once the machine comes up I need to connect to other iscsi targets so I
restart iscsid then try to connect:
root@server:~# killall iscsid; iscsid
root@server:~# iscsiadm -m node -T target -p x.x.x.x:3260 -l
Logging in to [iface: default, target: mail, portal: x.x.x.x,3260]
Login to [iface: default, target: mail, portal: x.x.x.x,3260]: successful
root@server:~# dmesg | tail | grep scsi
scsi2 : iSCSI Initiator over TCP/IP
scsi scan: INQUIRY result too short (5), using 36
So for whatever reason I don't have any problems in initram but I can't
do anything else once the machine is started.
The interesting thing here is that my laptop which also runs slackware
12.2 can't connect at all because of the same error.
I'm starting to suspect kernel 2.6.27.7 as the problem.
> The iscsi initiator does not do the scanning. It asks the scsi layer to.
> The scsi layer (this where the message about being too short is from)
> handle this, so it might be due to a change in upstream kernel.
I'll try a few different kernels. I've already got one compiled so I'll
work that angle today.
> It is right now.
I may try the latest git, but it looks like it downloaded the entire
kernel. My git kungfu isn't very good. I'll have to read up about it.
Thanks Mike, I'll try another kernel and report back.
schu
Matthew Schumacher
> Thanks Mike, I'll try another kernel and report back.
If I use kernels 2.6.27.7, 2.6.27.34, or 2.6.28.10 (what I had on hand)
I get the very same error message after iscsi connects:
scsi2 : iSCSI Initiator over TCP/IP
scsi scan: INQUIRY result too short (5), using 36
Why it works in my initram fs is beyond me.
One thing that is interesting is what /sys/bus/scsi/devices shows.
I see a host entry for iscsi, but no targets or devices. It looks like
everything comes up except the scsi layer.
schu
Matthew Schumacher
Ok, I'm a complete retard. It's very embarrassing to admit publicly,
but I failed to bind a lun to the target on the iscsi server side so
that is why it didn't find one. Sounds like I need to slow down and
only work one project at a time.
Sorry for the waisted time, hopefully this will help someone in the future.
schu