Step by Step guide how to use open-iscsi and Debian Etch

You need to install open-iscsi package for high performance, transport independent iSCSI implementation under Debian Linux.  You need Debian Linux  with kernel version 2.6.16, or later.

First of all, install open-iscsi

#aptitude install open-iscsi

and remove the broken init scripts (they are going to give you lots of headaches when rebooting, if you don’t do this.)

#update-rc.d -f open-iscsi remove

create a couple of symlinks to fix paths needed to automatically detect targets on reboot, and thus creating the sdX devices

#ln -s /etc/{iscsid.conf,initiatorname.iscsi} /etc/iscsi/

edit /etc/iscsi/iscsid.conf

#vi /etc/iscsi/iscsid.conf

and make sure that

node.startup = automatic

Save and exit the file

Restart open-iscsi

#/etc/init.d/open-iscsi restart

Now, let’s discover the iSCSI targets connected to the net:

#iscsiadm -m discovery -t sendtargets -p $SAN_IP_ADDRESS

Restart open-iscsi again, now you should see sdX appear in dmesg!

#/etc/init.d/open-iscsi restart

You can now partition and format the new disk(s) just as they were phisically attached disks… but beware, it’s not over yet, you’ll have to keep in mind and tweak a couple of things.

First, when you add the disk entry in your /etc/fstab, remember to use the -_netdev option, so for example:

/dev/sdb1 /mnt/logs ext3 defaults,auto,_netdev 0 0

This will make scripts like /etc/init.d/umountnfs.sh aware that they are remote network resources and… do nothing different because as I said Debian Etch is bugged as hell when dealing with iSCSI.

The default behaviour is, in fact, to kill the iscsid process and bring down the network interfaces before umounting the iSCSI disk, with effects ranging from kernel panics to “normal” lock-ups when rebooting the machine.

So, edit /etc/network/interfaces with your favourite editor and put something like this in the network interface you’re using to connect to the iSCSI SAN:

#post-up echo “Waiting for network to come up before starting iSCSI…” && sleep 5

#post-up /etc/init.d/open-iscsi start

#pre-down umount -a -O _netdev

#pre-down /etc/init.d/open-iscsi stop

moreover, edit /etc/default/rcS and put

ASYNCMOUNTNFS=no

to disable async mounting which in theory works better but in practice doesn’t work very well in Debian Etch when dealing with iSCSI.

The sleep is to assure that the interface is really up&running before trying to start open-iscsi, otherwise automounting on boot won’t work.

The other thing we have to tweak is the /etc/init.d/sendsigs script, which is used to kill all the running processes when rebooting/shutting down the server. This script is going to kill the iscsid daemon before umounting can happen, so making impossible to reboot your machine without physical access (and we all leave our machines in datacenters, don’t we?). So, here it is another simple hack to work around the problem:

#mv /etc/rc6.d/S20sendsigs /etc/rc6.d/S39sendsigs

#mv /etc/rc0.d/S20sendsigs /etc/rc0.d/S39sendsigs
(runlevel 0 is halt, runlevel 6 is reboot)

this way we tell init to execute sendsigs after umountnfs.sh, networking, ifupdown, thus solving our problem.

And that’s all now, you should be able to reboot your machine and have it to boot again, mounting your iSCSI volumes automatically.

Keep in mind that this howto is thought for servers in front of the SAN, so I’m supposing you’re not going to mount/umount things all the time, or bring up and down interfaces all the time. So for example do not complain if with a ifdown $IFACE you are bringing all the iSCSI infrastructure down.

Credit goes here

Sponsored Link

2 thoughts on “Step by Step guide how to use open-iscsi and Debian Etch

  1. after discovery and restart the drive did not show up for me.

    I had to do
    iscsiadm -m node -T sheeva:hd100 -p 127.0.0.1:3260 --login

  2. After all this time, who would think Debian-based systems still suffered the same problems with iSCSI!?! My company has been using Ubuntu 8.04.4 for a while with some iSCSI mounted volumes, and I always planned in some extra time for rebooting because of these dumb issues (even better was the failure to mount the volumes at boot, leading to a “maintenance prompt” with no network connection, beautiful).

    Thanks so much for your post, following above direction, all iSCSI issues have been resolved… at least until upgrading to 10.04…

Leave a comment

Your email address will not be published. Required fields are marked *