Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#982842: open-iscsi: do not use iscsistart in the boot process
236 views
Skip to first unread message
Heinrich Schuchardt
Feb 15, 2021, 4:00:03 AM2/15/21
to
Package: open-iscsi
Version: 2.1.3-2
Severity: wishlist
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 <notifi...@github.com>
Reply-To: open-iscsi/open-iscsi
<reply+AAU6VYFPNKPBNNQNGX...@reply.github.com>
To: open-iscsi/open-iscsi <open-...@noreply.github.com>
CC: Heinrich Schuchardt <xypro...@gmx.de>, Mention
<men...@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!
Version: 2.1.3-2
Severity: wishlist
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 <notifi...@github.com>
Reply-To: open-iscsi/open-iscsi
<reply+AAU6VYFPNKPBNNQNGX...@reply.github.com>
To: open-iscsi/open-iscsi <open-...@noreply.github.com>
CC: Heinrich Schuchardt <xypro...@gmx.de>, Mention
<men...@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!
Ritesh Raj Sarraf
Feb 15, 2021, 10:00:04 AM2/15/21
to
Control: tag -1 +help
On Mon, 2021-02-15 at 09:46 +0100, Heinrich Schuchardt wrote:
> 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.
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 | http://people.debian.org/~rrs
Debian - The Universal Operating System
On Mon, 2021-02-15 at 09:46 +0100, Heinrich Schuchardt wrote:
> 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.
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 | http://people.debian.org/~rrs
Debian - The Universal Operating System
Chris Hofstaedtler
Feb 15, 2021, 10:20:04 AM2/15/21
to
* Ritesh Raj Sarraf <r...@debian.org> [210215 15:49]:
> 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.
Agreed. Note: while I can spend some time on open-iscsi for work,
"root on iSCSI" is not actaully of interest to me.
Chris
> On Mon, 2021-02-15 at 09:46 +0100, Heinrich Schuchardt wrote:
> > 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.
[..]
> > 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.
> 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.
"root on iSCSI" is not actaully of interest to me.
Chris
Heinrich Schuchardt
Feb 15, 2021, 12:40:03 PM2/15/21
to
On 15.02.21 18:02, Lee Duncan wrote:
> On 2/15/21 6:48 AM, Ritesh Raj Sarraf wrote:
<snip />
> I cannot access this bug, so I will reply to all here ...
By CCing 982...@bugs.debian.org the bug report is updated.
>
> 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.
>
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
> On 2/15/21 6:48 AM, Ritesh Raj Sarraf wrote:
<snip />
> I cannot access this bug, so I will reply to all here ...
By CCing 982...@bugs.debian.org the bug report is updated.
>
> 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.
>
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
0 new messages