iscsi failure during boot on errand static node

Asked by Walt Corey

references to readyNASn are, from /etc/hosts readyNAS1 readyNAS2

Starting maybe a month ago I started having iscsi errors and failures to mount. This roughly coincided with the update of 20.04.3. Trying to cut to the chase I issued the following commands:

root@cor8910:~# iscsiadm -m discovery -t sendtargets -p readynas2,1 iqn.2011-09.nas-8B-3E-60:thunderbird,1 iqn.2011-09.nas-8B-3E-60:vmguests

root@cor8910:~# iscsiadm -m discovery -t sendtargets -p readynas1,1

The above output is correct However when issuing iscsiadm -m node -o show I get 4 records BEGIN RECORD 2.0-874 = iqn.2011-09.nas-8B-3E-60:thunderbird . . . node.conn[0].address = node.conn[0].port = 3260

#end record #Begin record 2.0-874 = iqn.2011-09.nas-8B-3E-60:vmguests . . node.conn[0].address = readyNAS1 #END RECORD That one is BAD as connection addr is readyNAS2 not 1, and should be dotted decimal BEGIN RECORD 2.0-874 = iqn.2011-09.nas-8B-3E-60:vmguests . . . node.conn[0].address =< br/> node.conn[0].port = 3260

#END RECORD This one is correct but why is the address dotted decimal and why was previous hosts synomym? BEGIN RECORD 2.0-874 = ... node.conn[0].address = END RECORD BEGIN RECORD 2.0-874 = ... node.conn[0].address = readynas1 #end record Last one is fine as well. I cannot get rid of that bad node record Doc I have googled indicates a /var/lib/iscsi which ubuntu does not have.

root@cor8910:~# ls -al /etc/iscsi/nodes/ total 20

drw------- 4 root root 4096 Oct 9 15:31 drw------- 3 root root 4096 Oct 9 15:31 iqn.2011-09.nas-8B-3E-60:thunderbird

drw------- 4 root root 4096 Oct 9 15:31 iqn.2011-09.nas-8B-3E-60:vmguests

I think the problem may have been in defaults subfolder which I moved to a safer place. However, the thunderbird folder still does not get logged in and mounted via fstab. the others do. Once booted I can issue an iscsiadm to login all and manually mount the thunderbird lun where the Thunderbird profile is pointing to it.

I'd like to be able to correct whatever is wrong but in the absence of discovering what is wrong if I purged open-iscsi and re-installed it would that resolve the problem? How does the configuration know in the case of 'readyNAS2' Netgear's ultra 4 NAS unit to refer to it by dotted decimal where 'readyNAS1' Netgear's 214 NAS is picking up the host file synonym for it's address?

After having thought through the pros/cons I purged iscsiadm and re installed it. This actually worked fine, static targets were found and login proceeded speedily. However, upon reboot, post reinstall, the problem reoccurred and I discovered there is something in the startup that creates the static nodes incorrectly. According to man iscsiadm the only type of discovery is sendtarget, isns. NO STATIC, yet it appears to build and use and fail.

How can is configure such it will not build static symlinks in error?

Question information

English Edit question
Ubuntu open-iscsi Edit question
No assignee Edit question
Solved by:
Walt Corey
Last query:
Last reply:
Revision history for this message
Walt Corey (waltc) said (last edit ):

Update - I believe this looks more and more like a bug.
Here's what I narrowed this down to
#apt purge open-iscsi (after logging out of all connections and unmounting all relevant devices
#reboot - do a clean reboot
#apt install open-iscsi - iscsid.conf and initiatorname.iscsi get created under /etc/iscsi
#iscsiadm -m node discoverydb --type sendtargets --portal readynas1 --discover - all nodes on that portal immediately discovered
#iscsiadm -m node discoverydb --type sendtargets --portal readynas2 --discover - all nodes on that portal immediately discovered
#ll /etc/iscsi - subdirectories nodes and send_targets created and properly populated
#iscsiadm iimode node --loginall=all - all nodes immediately logged in. I do have to manually mount UUIDs to /media but response is immediate

This works solid!!!

It is when I reboot some process creates a /etc/iscsi/static directory and populates it wth incorrect symlinks that cause subsequent reboots to fail to connect prior to processing fstab such that remote directories are not mounted and present.

Revision history for this message
Walt Corey (waltc) said :

apparently open-iscsi is very sensitive to what commands are issued and what order they are issued in. The key to figuring this out is getting a 'virgin' environment to test in. I created a VM of the latest 20.04.3 iso and proceeded to configure open-iscsi. As I did not have a redefined /etc/hosts file in the VM there were no synonyms for dotted decimal addresses. I think this may well have been part of the problem. I tried the sequence of commands depicted above to no avail. It did not fail, it did not even try. I then happened on this URL. It's important to read it slowly and carefully and follow it meticulously. While this was written for 18.04 it worked perfectly in the VM. I reproduced those results in my 'production' desktop with identical results. Pay particular attention in the instruction sequence to "If you have connected to iSCSI target before changing node.startup to automatic, you need to connect to iSCSI target again after changing node.startup to automatic.".