nixos/iscsi-root-initiator: support systemd stage 1 - #545932
Open
sochotnicky wants to merge 1 commit into
Open
Conversation
The scripted initrd is no longer the default and is slated for removal in 26.11, but boot.iscsi-initiator asserted against systemd stage 1, leaving no supported way to boot from iSCSI root. Add a systemd stage 1 code path that runs iscsid and the target login as real units ordered on the dependency graph (network-online.target -> iscsid -> iscsi-login -> initrd-root-device.target -> sysroot.mount), rather than a one-shot script in preLVMCommands. This also removes the race the scripted path has between iSCSI login and DHCP, since networkd ordering is a real dependency instead of an enumerate-at-an-instant loop. Initrd networking itself is left to boot.initrd.network.enable and networkd, configured from the `ip=` kernel parameter or the networking.* options, so the module only owns the iSCSI session. Bridged setups can be expressed with the normal networkd options outside this module. The scripted path is unchanged and no module options were added, removed or renamed. Add a nixos test covering the systemd stage 1 case: one node exports a LUN, another installs onto it, and a third boots from it with a systemd initrd. Assisted-by: Claude Opus 5 (High)
nixpkgs-ci
Bot
added
10.rebuild-linux: 1-10
sochotnicky
marked this pull request as ready for review
July 26, 2026 21:54
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The scripted initrd is no longer the default and is slated for removal in 26.11 (#287308),
but boot.iscsi-initiator asserted against systemd stage 1, leaving no supported
way to boot from iSCSI root.
Add a systemd stage 1 code path that runs iscsid and the target login as real
units ordered on the dependency graph (network-online.target -> iscsid ->
iscsi-login -> initrd-root-device.target -> sysroot.mount), rather than a
one-shot script in preLVMCommands. This also removes the race the scripted path
has between iSCSI login and DHCP, since networkd ordering is a real dependency
instead of an enumerate-at-an-instant loop.
Initrd networking itself is left to boot.initrd.network.enable and networkd,
configured from the
ip=kernel parameter or the networking.* options, so themodule only owns the iSCSI session.
Worth noting - if dhcp is used both initrd and stage2 boot need to use the same mac to get same IP (or bad things happen ™️) i.e.
dhcpV4Config.ClientIdentifier = "mac";on given device makes sure they don't generate different client IDs. Not sure how to best communicate - we could add an assertion/warning.The scripted path is unchanged and no module options were added, removed or
renamed. Add a nixos test covering the systemd stage 1 case: one node exports a
LUN, another installs onto it, and a third boots from it with a systemd initrd.
Note that there's already #263417 but it's been almost 3 years. Approach is similar, I didn't touch multipath since I have don't use it and it's harder for me to validate.
TODO:
networkConfig.KeepConfiguration = "yes";requirement in stage2 so things don't get disrupted?Assisted-by: Claude Opus 5 (High)
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.