[dwsuse]

This pull request makes the nvmf module work with nvme-cli 3, and keeps it working with nvme-cli 2.

nvme-cli 3 changed what the module relies on:

• nbft show -H: nvme-cli 3.2 dropped -H as the short name of --hfi, because it collides with a global option. -H now selects that deprecated global option and only works because nbft show without a section option shows every section. Once the global option is removed, nvme nbft show -H fails, the NBFT is skipped, and the boot interfaces get no network configuration. All nvme calls now use the long option names, which exist since nvme-cli 2.5.
• nvme-fabrics.conf: nvme-cli 3 configures the connections in /etc/nvme/nvme-fabrics.conf and its drop-ins in nvme-fabrics.conf.d/, and reads discovery.conf/config.json only as long as there is no nvme-fabrics.conf. The module neither installs these files nor looks for them, and once nvme-fabrics.conf is in the initrd, the rd.nvmf.discover= connections, which go to discovery.conf, are ignored. The module now installs and checks them, and with nvme-cli 3 it writes each rd.nvmf.discover= connection as a [Discovery Controller] section of a drop-in. With nvme-cli 2 it still writes discovery.conf.

More fixes found while testing:

• /etc/nvme in a non-hostonly initrd: only a hostonly initrd has /etc/nvme, so rd.nvmf.hostnqn=, rd.nvmf.hostid= and (with nvme-cli 2) rd.nvmf.discover= were not written. The initrd connected with a generated host NQN, which a target with an access list refuses.

• The NetApp udev rule: nvme-cli 2.7 renamed 71-nvmf-iopolicy-netapp.rules to 71-nvmf-netapp.rules, so the rule was no longer in the initrd. It is installed under both names now.

• rd.nvmf.nonbft after the initqueue timeout: with rd.nvmf.nonbft the NBFT is not parsed, but the timeout fallback runs a plain nvme connect-all, which (nvme-cli 2.5 and later) connects the NBFT's subsystems too. With a network up anyway (DHCP), the system booted from the NBFT's root despite rd.nvmf.nonbft. The fallback now passes --no-nbft when rd.nvmf.nonbft is set.

• systemd-networkd and the ip= of the hooks: systemd-network-generator reads the kernel command line only, so the ip=/vlan= this module writes to /etc/cmdline.d for an NBFT HFI never reached systemd-networkd. A static HFI only worked where DHCP happened to give the same address. networkd-config.sh now runs the generator again with dracut's command line.

• network-legacy and ip= by MAC address: the interface's state files use the sysfs form of the address, while parse-ip-opts kept the BOOTIF form, so the wait hooks never saw such an interface come up.

• nvme-cli < 2.5 support dropped (Benjamin Drung's commit from chore(nvmf): drop supporting nvmi-cli < 2.5 #2759, with his authorship): the --nbft check of nvme connect-all --help used sed -n '...q1;$q0', which busybox's sed rejects, so with busybox the module acted as if nvme-cli were older than 2.5. No distribution that ships a current dracut has an older nvme-cli (table in chore(nvmf): drop supporting nvmi-cli < 2.5 #2759). The check is also gone from the rd.nvmf.nonbft timeout handling above.

Related nvme-cli fixes (not needed for this PR): connect-all --nbft connects as the NBFT's host NQN again, and the conversion of a discovery.conf with --host-traddr=none (as this module writes it for nvme-cli 2) no longer produces an nvme-fabrics.conf that fails to parse: linux-nvme/nvme-cli#4384

Testing

Booted a QEMU guest whose root is an ext4 file system on an NVMe/TCP namespace (Linux nvmet target), with initrds built on openSUSE Tumbleweed (dracut 112, kernel 7.3.1, systemd + systemd-networkd, static ip=), with this module dropped in:

nvme-cli	target from	hostonly	result
2.11	rd.nvmf.discover=	no	boots (before: fails, no /etc/nvme)
2.11	discovery.conf	yes	boots
3.1 (Tumbleweed package)	rd.nvmf.discover=	no / yes	boots
3.1 (Tumbleweed package)	nvme-fabrics.conf	yes	boots (before: fails, file not installed)
3.1 (Tumbleweed package)	discovery.conf	yes	boots
3 (with nvme-cli#4384)	rd.nvmf.discover=, nvme-fabrics.conf	no / yes	boots

shfmt and shellcheck (also -s busybox) are clean.

NBFT boot

QEMU's firmware writes no NBFT, but QEMU hands any ACPI table to the guest (-acpitable file=). The test setup now generates an NBFT (layout of the NVM Express Boot Specification 1.4, as libnvme parses it; checked with nvme nbft show): its HFI is the guest's NIC, its SSNS the root subsystem. The guest then boots with no ip= and no rd.nvmf.* target on the kernel command line: dracut sets up nbft0 from the HFI and nvme connect-all --nbft connects the root. This covers the OS side of an NBFT boot, not firmware booting from NVMe/TCP. A second subsystem on the target (no root on it) serves the cases with more than one subsystem. After switch-root the root's /init lists the NVMe controllers it finds, and each case checks whether the guest boots and which subsystems have controllers.

Same setup as above, nvme-cli 3.2+ (git 43b0ee22d), this branch at 9ae0cf7:

case	kernel command line / NBFT	expected	result
rd.nvmf.discover=	root subsystem	boots, root connected	pass
rd.nvmf.discover= ×2	root and second subsystem	boots, both connected	pass
NBFT	SSNS: root	boots, root connected	pass
NBFT, non-bootable entry	SSNS: root, second subsystem with the Non-bootable Entry Flag	boots, both connected	pass
NBFT, unavailable namespace	SSNS: root, a missing target with UNFLAG = unavailable	boots, root connected	pass
NBFT, missing subsystem	SSNS: root, a missing target, no flag	boots, root connected (SSNS 2: no controller found in the log)	pass
NBFT, discovery descriptor only	no SSNS, discovery descriptor of the root's port	boots, root found through discovery	pass
NBFT + rd.nvmf.nonbft	SSNS: root, no other source	no root, boot fails	pass with the last commit; before it, the timeout fallback booted from the NBFT

The nvme-fabrics.conf (hostonly) and discovery.conf (hostonly) cases of the table above were repeated with the same nvme-cli on b63b9f1 (the branch before the last commit, which only changes the timeout fallback) and pass as well.

Boot matrix (2026-11-13)

Rebased on main 04e04cf. nvme-lab boot scenarios (QEMU guests with an NVMe/TCP root through this module: rd.nvmf.discover=, nvme-fabrics.conf, NBFT with static and DHCP HFIs, VLAN, tap networks without DHCP, multipath, refused paths, network-legacy, NetworkManager), with nvme-cli master, 3.2, 2.16, 2.13 and 2.8: 136 scenarios, 134 pass, 2 expected failures (3.2 connects an NBFT as the system's host NQN, fixed in master; 2.8 ignores NBFT discovery descriptors), no failures.

Checklist

• I have tested it locally
• I have reviewed and updated any documentation if relevant (no change needed: the man pages describe the parameters, not the files)
• I am providing new code and test(s) for it (the test suite has no NVMe-oF test yet; the boot test above was done with a separate setup)

[devkontrol]

CC @mwilck @aafeijoo-suse @tbzatek

[Copilot]

🟢 Approval recommended

No active review issues are reported for the NVMe-oF compatibility update.

No open issues 🎉

What changed in this PR

Updates dracut’s NVMe-oF module to support nvme-cli 3 while preserving nvme-cli 2 compatibility.

Changes:

• Uses long nvme option names and adds installation, detection, and cleanup of nvme-fabrics.conf and its drop-ins.
• Writes command-line discovery settings in the supported format and creates /etc/nvme for non-hostonly initrds.
• Supports both legacy and renamed NetApp udev rules.

File	Description
modules.d/​74nvmf/​parse-nvmf-boot-connections.sh	Updates NBFT options, handles both discovery formats, and ensures the configuration directory exists.
modules.d/​74nvmf/​nvmf-autoconnect.sh	Recognizes fabrics configuration files and drop-ins when selecting autoconnection.
modules.d/​74nvmf/​module-setup.sh	Detects and installs fabrics configuration, updates nvme options, and installs both NetApp rule names.

_{Review effort: Balanced}

[mwilck]

One question, otherwise LGTM.

[mwilck]

What if both files exist, e.g. one in /usr/lib/udev/rules.d and one in /etc/udev/rules.d? This would cause duplicate work in udev rules. Does upstream (iow, nvme-cli itself) make sure that this can't happen? If yes, a comment might be in order.

[dwsuse]

Not sure what you ask here, because I am sure you know that udevd only executes only the first match. nvme-cli is not used in the rule either. It's

# Set appropriate iopolicy for NetApp ONTAP and NetApp E-Series
ACTION=="add", SUBSYSTEM=="nvme-subsystem", ATTR{subsystype}=="nvm", ATTR{model}=="NetApp ONTAP Controller", ATTR{iopolicy}="queue-depth"
ACTION=="add", SUBSYSTEM=="nvme-subsystem", ATTR{subsystype}=="nvm", ATTR{model}=="NetApp E-Series", ATTR{iopolicy}="round-robin"

# Set ctrl_loss_tmo to -1 for NetApp ONTAP NVMe/TCP
ACTION!="remove", SUBSYSTEM=="nvme", KERNEL=="nvme*", ATTR{transport}=="tcp", ATTR{model}=="NetApp ONTAP Controller", ATTR{ctrl_loss_tmo}="-1"

I'ts about setting some of the sysfs entries.

[mwilck]

udevd only executes only the first match

That holds only for rules with the same file name in different directories, not for different file names.

What I meant with "nvme-cli itself" was that some tooling (perhaps in the package update logic) would notice that both files are present and delete or disable the old one. Sorry for being unclear.

[dwsuse]

Honestly, I'm not sure why this rule is part of dracut in the first place. It was added in 2f03d69 ("95nvmf: add module for NVMe-oF"), and the rule itself only landed in nvme-cli three weeks later as 6eafcf96f315 ("nvmf-autoconnect: add udev rules to set iopolicy for certain NetApp devices"), without any explanation.

@hreinecke, do you happen to remember why you added this rule here?

This change only makes the module work with both nvme-cli 2 and nvme-cli 3 again. Upstream nvme-cli ships just one version of the rule, and distro packages normally remove the old file when they install the new one. So I don't think having both files around is a real problem in practice.

FWIW, the real root re-applies these settings after switch_root anyway, because systemd-udev-trigger.service runs:

udevadm trigger --type=all --action=add

Without the rule, the initrd runs with the default iopolicy (numa) and the default ctrl_loss_tmo (600s). A path would have to stay down for 10 minutes during the initrd before the missing -1 mattered.

nvme-cli also ships the same kind of rules for HPE Alletra and VAST Data, and those aren't included here either. That raises the question: do we want this rule in the initrd at all? And if we do, shouldn't we handle it generically for all vendors?

What do you think is the right way forward?

[mwilck]

Honestly, I'm not sure why this rule is part of dracut in the first place.

Good point. I don't see why it'd be necessary, either.

So I don't think having both files around is a real problem in practice.

True. Duplicate rules would possibly result if a user had modified the old rule, copying it to /etc/udev/rules.d. I tend to dislike this kind of bitrot, but we can't avoid it in all possible circumstances.

I thought you could use something like the INI trick to decide which file you want to install. But maybe I am overthinking this.

[dwsuse]

fwiw, all udev rules can be dropped in future with nvme-cli >= 3.3. and the pre-OS PR #2825

[mwilck]

OK, thanks.

[mwilck]

This is correct from a consistency point of view.

But I am unsure if it's the Right Thing™ to do. Timeout handling means that all else has failed. No root file system has been found anywhere. This is a last-resort action before dropping to the emergency prompt, which is always a pain to work with. IMO it makes sense to try anything that might provide a usable root file system at this stage.

Most of the time there will be a root=UUID=... parameter, thus the likelihood of booting a wrong or malicious root file system from NBFT despite rd.nvmf.nonbft given is very low.

I may be overlooking something of course. Opinions?

[dwsuse]

But if the user chooses 'nonbft', why shouldn't it honor it? I would follow the principle of least surprise.

edit: and yes, this stands out in the test scenarios I currently run

[mwilck]

Well I suppose in that situation all bets are off. It's ok.

[dwsuse]

I updated the branch (force-push, 9ae0cf7 → 8611d16):

• Two fixes outside the nvmf module were added at the end. Both came up while testing NBFT boots on a network without DHCP:
  • fix(systemd-networkd): give the generator what the hooks added: systemd-network-generator reads ip=/vlan= from the kernel command line only, and it runs before the cmdline hooks. The ip= and vlan= that this module writes to /etc/cmdline.d for an NBFT HFI (and those of the iBFT) never reached systemd-networkd. So an NBFT boot with a static HFI only worked where a DHCP server happened to hand out the same address, as QEMU's user network does. With a tap device and no DHCP, untagged and over a VLAN, the boot failed with every nvme-cli version. It passes now.
  • fix(network-legacy): wait for an interface named by its MAC address: for an ip= that names the interface by its MAC address, parse-ip-opts kept the address in the BOOTIF form (52-54-00-...), but ifup writes its state files under the sysfs form (52:54:00:...). So the wait hook, all_ifaces_up() and all_ifaces_setup() never saw the interface come up. The nvmf module in this PR doesn't name the HFI by its MAC address. The fix is for any ip= that does: iscsiroot's all_ifaces_setup(), and initrds without systemd. With systemd and a network root, the wait also ends when the root device appears, which hides the bug.
• fix(nvmf): honor rd.nvmf.nonbft when the initqueue times out (9ae0cf7 → 17a913c) only lost a Co-Authored-By trailer. The code is unchanged.

If you'd rather review the two network fixes separately, I can move them to their own PR.

Testing of 8611d16, with the boot setup described above (nvme-lab): the initrd boots an NVMe/TCP root through this module with nvme-cli 2.8, 2.13, 2.16, 3.2 and master. The cases cover rd.nvmf.discover=, discovery.conf/nvme-fabrics.conf (hostonly or not), NBFT with systemd-networkd, network-legacy and NetworkManager, an NBFT HFI on a tap device without DHCP (untagged and VLAN 10), multipath, and path faults. 160 pass, and the 2 known per-release failures stay. On 9ae0cf7, the two tap cases failed on every nvme-cli version.

[dwsuse]

I updated the branch (force-push, 8611d16 → 23534d8):

• Rebased on main.
• Added Benjamin's commit from chore(nvmf): drop supporting nvmi-cli < 2.5 #2759 at the end (chore(nvmf): drop supporting nvme-cli < 2.5, his authorship), as agreed there. It drops the sed check for --nbft, which busybox's sed can't run. I also dropped the same check from the rd.nvmf.nonbft timeout handling of this PR.

The boot matrix (nvme-cli master, 3.2, 2.16, 2.13, 2.8) passes: 134 pass, 2 expected failures, no failures. The description has the details.