An upstream maintainer suggested that Debian should not use iscsistart
for booting from an iSCSI volume but instead include iscsid and iscsiadm
in the initrd. The same is already done in SUSE.

Please, consider such a change for Debian Bookworm.
-------- Forwarded Message --------
Subject: 	Re: [open-iscsi/open-iscsi] iscsistart fails with 15 - session
exists with ipv6 (#241)
Date: 	Fri, 12 Feb 2021 15:29:41 -0800
From: 	Lee Duncan <notifications@github.com>
Reply-To: 	open-iscsi/open-iscsi
<reply+AAU6VYFPNKPBNNQNGX2JUOF6GLYGLEVBNHHC445E74@reply.github.com>
To: 	open-iscsi/open-iscsi <open-iscsi@noreply.github.com>
CC: 	Heinrich Schuchardt <xypron.glpk@gmx.de>, Mention
<mention@noreply.github.com>



    @gonzoleeman <https://github.com/gonzoleeman>

        Let me emphasize again: iscsistart is not great. Using
        iscsiadm/iscsid is still the recommended way to use open-iscsi.

    Debian uses iscsistart when booting from iSCSI. Is this the wrong
    way to do it?

    Cf.

https://salsa.debian.org/linux-blocks-team/open-iscsi/-/blob/master/debian/extra/initramfs.hook

<https://salsa.debian.org/linux-blocks-team/open-iscsi/-/blob/master/debian/extra/initramfs.hook>

The proper way to use open-iscsi is to (1) start the daemon, then (2)
use iscsiadm to talk to the daemon.

There are a couple of problems with the iscsistart approach: first, it
has no error handling. All the error handling is built into iscsid.
Sure, some of it might have gotten copied to iscsistart, but not most of
it. For example, once iscsistart exits, there is *no* error handling at
all. The second problem is that iscsistart is not maintained, since it's
not used as much. It also has other issues, like not setting up the
session correctly, so that trying to log out of that session fails on
the first attempt.

I'm fairly sure this approach was taken because it's more complex to
start them daemon then use iscsiadm. But it's not a lot more complex.
That's the approach we take at SUSE. To be fair, there are shortcomings
even when using iscsid/iscsiadm. In our case, when we switch from
virtual root to the real root disc, we stop then restart the iscsid
daemon. So even in our case there is a window when no error handling can
occur.

But iscsistart is still part of the open-iscsi distribution, so until
and unless somebody removes it, it's supported, even if I like to
discourage it's use. (I also discourage use of iscsi NOPs, if that
matters, so this isn't the only windmill I tilt at.)

I hope that answers your question. If you wanted to convert debian to
using iscsid/iscsiadm, I'd be glad to help!

Control: tag -1 +help

Yes. But usually, you don't need the iscsid daemon in initrd. Because
most usual cases, users would be mapping data LUNs only.

Only in exceptional cases, where you have root on iSCSI, you need to
establish the connections early. And to do that we used iscsistart,
which would establish only a single connection, effectively making it
prone to hangs if that single connection went down.

But the time from when iscsistart establishes the connection and
fetched the root LUN, to the time when real init starts and the actual
iscsid daemon is run, is not a very large time. That has been the
assumption so far and the integration was built accordingly.

The other reason I can recollect is that you could have a very large
number of LUNs mapped to your initiator along with your root LUN. If
you push everything to be processed in initrd:

1. The boot would be much slower, depending on how many LUNs are mapped
2. I don't know how the initiator would behave if some of the LUNs,
from some of the targets, are temporarily unavailable.

These days, I only work on storage as a hobby. So this feature should
be better and early co-ordinated, by users and derivatives that want to
see it follow the path. And we could definitely leverage on what Suse
has already done.

* Ritesh Raj Sarraf <rrs@debian.org> [210215 15:49]:

[..]
"root on iSCSI" is not actaully of interest to me.

Chris

I cannot access this bug, so I will reply to all here ...

In general, you do not set up initrd to boot into all iSCSI targets,
only the ones with "startup" set to "onboot". Then, later, as part of
the system coming up, once the real root is established and networking
is up, do you log into all "automatic" targets using open-iscsi.

So the idea isn't to log into all targets at initrd time, just the same
ones you log into now (i.e. "onboot" targets, needed to boot) using
iscsid/iscsiadm instead of iscsistart. Note that SUSE only supports the
root and /usr partitions being remote at boot time. If you have
something like /opt you want to mount, it has to be done later (in our
systems).

I hope this clarification helps.

<snip />

By CCing 982842@bugs.debian.org the bug report is updated.

My current configuration is:

iscsid.conf:40:
# node.startup = automatic

nodes/iqn.2000-01.de.xypron:pine-a64-lts/192.168.0.1,3260,1/default:4:
node.startup = manual

nodes/iqn.2000-01.de.xypron:pine-a64-lts/192.168.0.1,3260,1/default:52:
node.conn[0].startup = manual

File /etc/iscsi/iscsi.initramfs specifies the root device.

HWADDR="01:02:03:04:05:06"
ISCSI_TARGET_NAME="iqn.2000-01.de.xypron:pine-a64-lts"
ISCSI_TARGET_IP="192.168.0.1"
ISCSI_TARGET_PORT="3260"
ISCSI_TARGET_GROUP="1"
ISCSI_USERNAME="user"
ISCSI_PASSWORD="password"

Where would "onboot" fit into the image?
What makes a target an "onboot" target?
Do you simply mean the one specified in /etc/iscsi/iscsi.initramfs?

Best regards

Heinrich