Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for booting from iSCSI offload with bnx2i (bsc#1228086) (059) #395

Merged
merged 3 commits into from
Jan 20, 2025

Conversation

aafeijoo-suse
Copy link
Collaborator

Backport of dracut-ng/dracut-ng#1121 for Factory

mwilck and others added 3 commits January 20, 2025 09:26
The bnx2i iSCSI transport doesn't require networking to be set up in order to
bring up iSCSI connections. Quite to the contrary, trying to bring up the
network may actually disturb the iSCSI connection. This holds in particular
for bnx2i device with NPAR (network partitioning) support, where a given
network interface can be used for both iSCSI and regular networking. Setting
certain network parameters like MTU on the network side can fatally disrupt
an existing iSCSI connection. Even if this does not happen, trying to bring
up the regular network interfaces is pointless because iSCSI won't be enabled
over regular TCP/IP anyway. Trying to bring up the network interfaces and
possibly failing delays booting unecessarily and may cause timeout, without
benefit.

Detect the bnx2i offload module at setup time and communicate it to
parse-iscsiroot.sh using a new parameter, "rd.iscsi.transport". It's currently
only effective for bnx2i. It might be useful for other transports as well,
but we haven't been able to test the other transports as thoroughly as bnx2i.

Signed-off-by: Martin Wilck <[email protected]>
(cherry picked from commit dracut-ng/dracut-ng@cc2c48a)

bsc#1228086
When booting from iSCSI, we don't need to wait for retries until all network
interfaces are up. We can just attempt to activate iSCSI on those interfaces
that are currently up (in the offload case like bnx2i, we can even try without
any network interfaces). If the root fs is found, we can go on booting;
otherwise, the iscsiroot script will be called again later anyway.

Signed-off-by: Martin Wilck <[email protected]>
(cherry picked from commit dracut-ng/dracut-ng@f30cf46)

bsc#1228086
Copy link
Collaborator

@tblume tblume left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

@aafeijoo-suse aafeijoo-suse merged commit 7559201 into openSUSE:SUSE/059 Jan 20, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants