Re: INQUIRY result too short (5), using 36
Matthew Schumacher wrote: > Matthew Schumacher wrote: > >> 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 > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: INQUIRY result too short (5), using 36
Matthew Schumacher wrote: > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: INQUIRY result too short (5), using 36
Mike Christie wrote:
> 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:
r...@server:~# killall iscsid; iscsid
r...@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
r...@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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: INQUIRY result too short (5), using 36
Matthew Schumacher wrote: > 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
