12 hours ago, SimonF said:

Did a test on may 6.9.2 machine worked ok, must be an issue with support for my alderlake CPU or something else as cannot delete any, Will have to look into that.

According to the method https://github.com/open-iscsi/rtslib-fb/tree/master/rtslib

def _gen_attached_luns(self):
        '''
        Fast scan of luns attached to a storage object. This is an order of
        magnitude faster than using root.luns and matching path on them.
        '''
        isdir = os.path.isdir
        islink = os.path.islink
        listdir = os.listdir
        realpath = os.path.realpath
        path = self.path
        from .root import RTSRoot
        from .target import LUN, TPG, Target
        from .fabric import target_names_excludes

        for base, fm in ((fm.path, fm) for fm in RTSRoot().fabric_modules if fm.exists):
            for tgt_dir in listdir(base):
                if tgt_dir not in target_names_excludes:
                    tpgts_base = "%s/%s" % (base, tgt_dir)
                    for tpgt_dir in listdir(tpgts_base):
                        luns_base = "%s/%s/lun" % (tpgts_base, tpgt_dir)
                        if isdir(luns_base):
                            for lun_dir in listdir(luns_base):
                                links_base = "%s/%s" % (luns_base, lun_dir)
                                for lun_file in listdir(links_base):
                                    link = "%s/%s" % (links_base, lun_file)
                                    if islink(link) and realpath(link) == path:
                                        val = (tpgt_dir + "_" + lun_dir)
                                        val = val.split('_')
                                        target = Target(fm, tgt_dir)
                                        yield LUN(TPG(target, val[1]), val[3])

 

it scans subfolders under the /iscsi/ folder to delete luns. Everything is treated as a folder except the:

excludes_list = [
    # version_attributes
    "lio_version", "version",
    # discovery_auth_attributes
    "discovery_auth",
    # cpus_allowed_list_attributes
    "cpus_allowed_list",
]

where this cpus_allowed_list is excluded. So it shouldn't still try to access it as a folder. the reason is, in the targetcli you are using, this cpus_allowed_list is not in the excludes_lsit. 

 

By checking the latest commit for the fabric module

https://github.com/open-iscsi/rtslib-fb/commit/8d2543c4da62e962661011fea5b19252b9660822

I see

 

Quote

handle target kernel module new attribute cpus_allowed_list

target has been added cpus_allowed_list attribute in sysfs. Therefore, the rtslib should handle the new attribute: 1. add cpus_allowed_list item in target_names_excludes 2. add cpus_allowed_list feature in ISCSIFabricModule.

 

So this might indicate that the targetcli is out dated in Unraid 6.10.3 for some systems that has cpus_allowed_list.

 

Thank you

 

Edit: targetcli 2.1.54 is already the newest version for and no newer package has been built. We need to rebuild the targetcli to use the latest rtslib-fb.

Edited July 25, 20223 yr by zxhaxdr

23 hours ago, zxhaxdr said:

I have found the problem.

 

In,

$("#ft1 input[type='checkbox']").change(function() {
  var matches = document.querySelectorAll("." + this.className);
  for (var i=0, len=matches.length|0; i<len; i=i+1|0) {
    matches[i].checked = this.checked ? true : false;
  }
  $("#removeFileIO").attr("disabled", false);
 });
 

method querySelectorAll() throws exception

Uncaught DOMException: Failed to execute 'querySelectorAll' on 'Document': '.000test' is not a valid selector.
    at HTMLInputElement.<anonymous> (<anonymous>:3:26)

 

See the fileIO name is 000test and it seems it desen't like digits in the front. Other name formats are fine, e.g., test or test_test.

 

So I think we need to regulate the class name by adding a prefix or something.

Cheers

This is fixed now + targetcli is also fixed in 2022.07.25

Edited July 25, 20223 yr by SimonF

Hello there, i installed 6.11.0-rc4 today and it totally broke the ISCSI plugins. i reverted to rc3 and it worked again just fine.

2 hours ago, domrockt said:

Hello there, i installed 6.11.0-rc4 today and it totally broke the ISCSI plugins. i reverted to rc3 and it worked again just fine.

A little bit more information would be nice...

What is broken? Maybe also include some screenshots from what isn't working.

2 hours ago, ich777 said:

A little bit more information would be nice...

What is broken? Maybe also include some screenshots from what isn't working.

 

i wrote it between Door and Hinge this Morning, i install r4 right now and make the shoots.

the status page is bugged out or does not find and activate my settings.

 

 

installing... r4 now

 

done..

 

i had no problems upgrading from any version upwards. 

 

 

and after the downgrade to r3

 

Edited September 6, 20223 yr by domrockt

40 minutes ago, domrockt said:

the status page is bugged out

But does it actually work in terms of iSCSI? Is only the status page broken?

22 minutes ago, ich777 said:

But does it actually work in terms of iSCSI? Is only the status page broken?

No all iscsi related Connections are not discoverable. 
 

the Settings Seem to be there because a simple downgrade can again make use of them. 

On 9/6/2022 at 1:16 PM, domrockt said:

No all iscsi related Connections are not discoverable. 
 

the Settings Seem to be there because a simple downgrade can again make use of them. 

This should be fixed. Thanks @ich777

Edited September 8, 20223 yr by SimonF

15 hours ago, SimonF said:

This should be fixed. Thanks @ich777

is the fix released? @ich777

11 minutes ago, domrockt said:

is the fix released? @ich777

Yes, it is maybe necessary to reboot once for you so that this fix applies since the plugin has to grab a new plugin package, or simply uninstall it, reboot and then grab a fresh copy from the CA App.

Yes works fine, just delete the Plugin and install it again, all settings are still there and works like charm.

 

that was a fix fix  thanks 

Also had to reinstall the plugin after 6.11.0 stable

On 9/29/2022 at 6:17 AM, isvein said:

Also had to reinstall the plugin after 6.11.0 stable

did you have to reconfigure iscsi? or just uninstall and reinstall the plugin does the job? 

2 hours ago, Xxharry said:

did you have to reconfigure iscsi? or just uninstall and reinstall the plugin does the job? 

You don‘t have to reconfigure it, just remove it and install it again.

On 9/28/2022 at 10:17 PM, isvein said:

Also had to reinstall the plugin after 6.11.0 stable

I did not have to do anything, strange

5 minutes ago, maxstevens2 said:

I did not have to do anything, strange

I updated the package  to fkix 6.11 install

I'm experiencing some issues after upgrading to 6.11.1 from 6.9.
First of all my iscsi drive didn't show up, so as suggested here i removed and re-installed the iscsi target plugin.
That made my mapped drive show up again, but i started having unexpected shutdowns on unraid. Mostly unclean shutdowns completely out of the blue.
So i've set up logging to see what may be going on, only to find my syslogs littered with these:

Oct 12 16:47:19 Server996 kernel: Unable to locate Target IQN: iqn.2003-01.org.linux-iscsi.server996.x8664:sn.a5ccc3708536 in Storage Node
Oct 12 16:47:19 Server996 kernel: iSCSI Login negotiation failed.

One of those like every 5 seconds. And when looking at the IQN number, i saw that it's not the current IQN.
So for some reason, there is a reference to an old IQN that unraid is trying to connect to.
Any idea on where that reference may be, and most importantly, how i get rid of it?

PS. i'm not sure these issues are the actual cause of my unclean shutdowns, but they're about 95% of my syslog file so they need to be addressed either way.

30 minutes ago, 0wn996 said:

I'm experiencing some issues after upgrading to 6.11.1 from 6.9.
First of all my iscsi drive didn't show up, so as suggested here i removed and re-installed the iscsi target plugin.
That made my mapped drive show up again, but i started having unexpected shutdowns on unraid. Mostly unclean shutdowns completely out of the blue.
So i've set up logging to see what may be going on, only to find my syslogs littered with these:

Oct 12 16:47:19 Server996 kernel: Unable to locate Target IQN: iqn.2003-01.org.linux-iscsi.server996.x8664:sn.a5ccc3708536 in Storage Node
Oct 12 16:47:19 Server996 kernel: iSCSI Login negotiation failed.

One of those like every 5 seconds. And when looking at the IQN number, i saw that it's not the current IQN.
So for some reason, there is a reference to an old IQN that unraid is trying to connect to.
Any idea on where that reference may be, and most importantly, how i get rid of it?

PS. i'm not sure these issues are the actual cause of my unclean shutdowns, but they're about 95% of my syslog file so they need to be addressed either way.

Does the ign show on the config page?

15 minutes ago, SimonF said:

Does the ign show on the config page?

Nope, the config page just contains the current iqn. I noticed just now that these old ones were still present on the windows machine i use to access the iscsi. Those messages were the windows machine trying to reach a non-existent iscsi target. Removing the old iqn on windows did the trick. 

 

Now let's see what that does for my unexpected shutdowns. Fingers crossed. 

Little follow-up on my unexpected lockups.
They seem to be unrelated to iSCSI. When upgrading, for some reason a new IQN got created, and windows still looking for the old one gave me those errors in my logs. Fixing that did not end my unexpected shutdowns though.

The lockups i'm more and more sure were related to me running ddr4 at 3600mhz, while apparently the memory controller in my ryzen 3900X supports up to 3200mhz. Worked without any issues for a year, but for some reason it seems to have become an issue now. Lowered ram speeds and no lockups so far.

Hello, brother, I created iSCSI, after using it for a period of time, I found that the capacity is not enough, how to expand this capacity?

I'm getting a similar error as above, but uninstalling and reinstalling isn't helping this time.

 

 Looks like libffi.so.7 is no longer included with the latest Unraid 6.11.2 base install.

 

Looks like the script here tries to create a symlink to it https://github.com/SimonFair/unraid.iSCSI/blob/27d5a6eaa575b0643fa90cabbecab370fbc1ed57/iSCSIgui.plg

 

Any way to get this to work again? A similar symlink to 8 just generates an error about needing 7

 

Edited November 6, 20223 yr by gingerdude
More details

1 hour ago, gingerdude said:

I'm getting a similar error as above, but uninstalling and reinstalling isn't helping this time.

 

 Looks like libffi.so.7 is no longer included with the latest Unraid 6.11.2 base install.

 

Looks like the script here tries to create a symlink to it https://github.com/SimonFair/unraid.iSCSI/blob/27d5a6eaa575b0643fa90cabbecab370fbc1ed57/iSCSIgui.plg

 

Any way to get this to work again? A similar symlink to 8 just generates an error about needing 7

 

Thanks for the report will look into it

Just fyi (I don't use it for important data yet, so not a huge deal).

It worked fine when upgrating to 6.11.1

Today I updated to 6.11.2 and it does not work anymore. De- and re-installed the plugin, but did not change the behaviour.

 

Both Status and Diags look the same = empty

Devices, FileIO and Initiators look good, as far as I can tell, but my PC can't connect to it anymore.

 

P.S. Expanding / shrinking and changeing write-back for existing fileio would be awesome, if possible at all

 

/edit: add the traceback -> looks like he can't import ImportError: libffi.so.7

 

Quote

targetcli
Traceback (most recent call last):
  File "/usr/bin/targetcli", line 4, in <module>
    __import__('pkg_resources').run_script('targetcli-fb==2.1.54', 'targetcli')
  File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 665, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 1470, in run_script
    exec(script_code, namespace, namespace)
  File "/usr/lib/python3.9/site-packages/targetcli_fb-2.1.54-py3.9.egg/EGG-INFO/scripts/targetcli", line 24, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "/usr/lib/python3.9/site-packages/targetcli_fb-2.1.54-py3.9.egg/targetcli/__init__.py", line 18, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "/usr/lib/python3.9/site-packages/targetcli_fb-2.1.54-py3.9.egg/targetcli/ui_root.py", line 30, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "/usr/lib/python3.9/site-packages/rtslib_fb-2.1.75-py3.9.egg/rtslib_fb/__init__.py", line 24, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "/usr/lib/python3.9/site-packages/rtslib_fb-2.1.75-py3.9.egg/rtslib_fb/root.py", line 28, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "/usr/lib/python3.9/site-packages/rtslib_fb-2.1.75-py3.9.egg/rtslib_fb/node.py", line 23, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "/usr/lib/python3.9/site-packages/rtslib_fb-2.1.75-py3.9.egg/rtslib_fb/utils.py", line 30, in <module>
  File "/usr/lib/python3.9/site-packages/pyudev-0.24.0-py3.9.egg/pyudev/__init__.py", line 45, in <module>
    from pyudev.core import Context, Enumerator
  File "/usr/lib/python3.9/site-packages/pyudev-0.24.0-py3.9.egg/pyudev/core.py", line 27, in <module>
    from pyudev._ctypeslib.libudev import ERROR_CHECKERS, SIGNATURES
  File "/usr/lib/python3.9/site-packages/pyudev-0.24.0-py3.9.egg/pyudev/_ctypeslib/__init__.py", line 26, in <module>
    from . import libc, libudev
  File "/usr/lib/python3.9/site-packages/pyudev-0.24.0-py3.9.egg/pyudev/_ctypeslib/libc.py", line 27, in <module>
    from ctypes import c_int
  File "/usr/lib/python3.9/ctypes/__init__.py", line 8, in <module>
    from _ctypes import Union, Structure, Array
ImportError: libffi.so.7: cannot open shared object file: No such file or directory

 

Edited November 6, 20223 yr by dreadu
added traceback

Same here
No luck on reinstall after 6.11.2