Once upgraded from (unstable to unstable) 1.4.18 -> 1.4.19 I cannot mount targets using iscsiadm command. ietd.conf: Target iqn.2009-03.pl.mydomain:storage.disk.atom.md6 Lun 0 Path=/dev/md6,Type=fileio MaxConnections 2 Target iqn.2009-03.pl.mydomain:storage.disk.atom.md7 Lun 1 Path=/dev/md7,Type=fileio I boot remote systems using the command: iscsistart -i iqn.2009-03.pl.mydomain:dell.client -t iqn.2009-03.pl.mydomain:storage.disk.myhostname.md7 -g 1 -a 192.168.1.150 and get (there can be some typos, I'm rewriting from screen): iscsistart: transport class version 2.0-870. iscsi version 2.0-871 iscsistart: Logging into iqn.2009-03.pl.mydomain:storage.disk.myhost.md7 192.168.1.150:3260.1 iscsistart: version 2.0-871 iscsistart: conn 0 login refected: initiator error - target not found (02/03) iscsistart: initiator reported error (19 - encountered non-retryable iSCSI login failure) and later all of the consequences of not being able to switchroot etc etc. Previous unstable version worked OK (it was 1.4.18). Or was there any change which makes my config obsolete? Reproducible: Always Steps to Reproduce: 1. setup ietd server 2. setup a client 3. try to use iscsistart with above parameters. Actual Results: Actsual results already described above. Expected Results: It is expected that the target is mounted properly. I can assist in further testing in next few days.
Actually, I'm leaving it here for now, but as I've narrowed the reasons to iscsitarget itself / open-iscsi, I'll better post the question to iscsitarget developers on their list and put it back here.
Have you been able to figure this out? I am experiencing the same issue as described above. My target is Gentoo, but my isns server is CentOS. Dec 2 12:12:54 localhost iscsid: conn 0 login rejected: initiator error - target not found (02/03) Dec 2 12:12:57 localhost kernel: connection13:0: detected conn error (1011) Dec 2 12:12:57 localhost iscsid: Kernel reported iSCSI connection 13:0 error (1011) state (3) Dec 2 12:12:57 localhost iscsid: conn 0 login rejected: initiator error - target not found (02/03) Dec 2 12:13:00 localhost iscsid: connection13:0 is operational after recovery (1 attempts) Dec 2 12:13:00 localhost iscsid: conn 0 login rejected: initiator error - target not found (02/03)
(In reply to comment #2) > Have you been able to figure this out? I am experiencing the same issue as > described above. My target is Gentoo, but my isns server is CentOS. nope. At least not yet. I've downgraded and stuck with the older version of iscsitarget. I should have it tested until over weekend and then I'll clarify this report.
Following the iscsitarget-devel-hackers-list: On Monday 30 November 2009 00:23:39 Hengesbach, Jeff wrote: > Be sure to remove the old kernel modules. There have been a few folks > mentioning the very same issue recently. I did an upgrade to 1.4.19 > today without issue. During the upgrade process run "make uninstall" > from the 'old' source or dig into your /lib/modules/`uname -r` and > remove them manually. > > Thanks for the great work IET team! > > Jeff Hengesbach > Asahi Kasei Plastics North America, Inc. > Office: 517-223-2000 x5137 > Mobile: 517-294-1587 > Fax: 517-223-5192 > Http://www.AsahiKaseiPlastics.com > > 900 E. Van Riper Road > Fowlerville, MI 48836 > > > -----Original Message----- > > From: Janusz Syrytczyk [mailto:jsyrytczyk@uni.opole.pl] > > Sent: Sunday, November 29, 2009 5:36 PM > > To: iscsitarget-devel@lists.sourceforge.net > > Subject: [Iscsitarget-devel] Upgrade from 1.4.28 to 1.4.19 made my > > targetsunavailable. > > > > At the beginning, I would like to excuse me but I've put this in hurry > > on > > > Gentoo bugzilla; I expect the place wasn't really proper so I'm cross > > posting > > this here: > > > > Once upgraded from 1.4.18 -> 1.4.19 I cannot mount > > targets using iscsiadm command. > > > > ietd.conf: > > > > Target iqn.2009-03.pl.mydomain:storage.disk.atom.md6 > > Lun 0 Path=/dev/md6,Type=fileio > > MaxConnections 2 > > > > Target iqn.2009-03.pl.mydomain:storage.disk.atom.md7 > > Lun 1 Path=/dev/md7,Type=fileio > > > > I mount remote targets using the command: > > > > iscsistart -i iqn.2009-03.pl.mydomain:dell.client -t > > iqn.2009-03.pl.mydomain:storage.disk.myhostname.md7 -g 1 -a > > 192.168.1.150 > > > and get (there can be some typos, I'm rewriting from screen): > > > > iscsistart: transport class version 2.0-870. iscsi version 2.0-871 > > iscsistart: Logging into > > iqn.2009-03.pl.mydomain:storage.disk.myhost.md7 > > > 192.168.1.150:3260.1 > > iscsistart: version 2.0-871 > > iscsistart: conn 0 login refected: initiator error - target not found > > (02/03) > > iscsistart: initiator reported error (19 - encountered non-retryable > > iSCSI > > > login failure) > > > > and later all of the consequences of not being able to switchroot etc > > etc > > > Previous version worked OK (it was 1.4.18, but as the version was > > removed > > > from > > Portage I've downgraded to 0.4.17 and it also works fine). > > > > Was there any change which makes my config obsolete? am I doing wrong? > > let > > > me > > know, plaese :-) > > > > thanks, > > > > Janusz. > > ------------------------------------------------------------------------ > -- > > > ---- > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > 30- > > > Day > > trial. Simplify your report design, integration and deployment - and > > focus > > > on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Iscsitarget-devel mailing list > > Iscsitarget-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > that surprised me, but you were correct. I did clear iscitarget (remove ebuild files) and removed kernel module. Then simply emerged new iscistarget and here it goes, connection is operational. I'm not sure why it failed as it should go smoothly after usual upgrade made via Portage. What makes me feel unsatisfied is I cannot simulate the problem again; but I've made some changes to the system in the meantime, such as "make prepare" on current sources to make sure the module is being build against properly configured tree so I guess the system is not exactly the same. Anyway, solved, thanks. JS
