According to Cathy Zhou <Cathy.Zhou@Oracle.COM>:
"iscsistart is not designed to be working together with iscsid. When an
interface gets the dhcp offer successfully, the iscsiroot script is run
which starts the iscsistart service to establish the iSCSI session. With
the existence of iscsid, the iscsistart service's attempt to setup its
own mgmt ipc fails. Instead, the request to login to the iscsi target
is handled by the mgmt ipc of iscsid. After iscsistart finishes its
login attempt, it eventually sends a stop_event_loop request to stop
the mgmt process. As the result, it terminates iscsid."
So, iscsid is kicked out again.
Additionally iscsistart-flocked is used to make sure iscsistart is not
run in parallel.
parse-cmdline sets up an initial initiator-name to let iscsid start.
iscsid is started before doing any iscsistart business.
iscsistart is done with systemd-run asynchrone to do things in
paralllel. Also restarted for every new interface which shows up.
If rd.iscsi.waitnet (default) is set, iscsistart is done only
after all interfaces are up.
If not all interfaces are up and rd.iscsi.testroute (default) is set,
the route to a iscsi target IP is checked and skipped, if there is none.
If all things fail, we issue a "dummy" interface iscsiroot to retry
everything in the initqueue/timeout.
The bad initqueue parameter passing is already addressed by git commit:
commit bb8c16d121
and
commit 486a8f33e2
However this appraoch is slightly different:
"$netroot" instead of "'$netroot'", etc.
initqueue will process the arguments, assuming the first non-option
argument to be the program to be executed. Putting the entire
commandline into this argument confuses both, initqueue and the
program in question.
References: bnc#879038
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Thomas Renninger <trenn@suse.de>
When iSCSI firmware booting is selected we should not rely on
'netroot' or 'iscsiroot' variables to be set.
References: bnc#873448
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Previously if "$rootok" = 1, parsing of netroot command line arguments
was skipped. For multiple netroot arguments, all parse scripts have to
run.
Previously only the first netroot argument was taken into account for
the parsing scripts. Now every netroot argument is processed.
This introduces detailed cmdline parsing, warning or aborting if the
cmdline does not contain arguments according to the spec.
Makeing sure the parsers don't just call getarg for netroot et al,
allows their reuse inside netroot to analyse dhcp root-path as well.
Hence we can get rid of the current netroot hooks. The hook itself stays
in order to add further modules which should run before netroot handlers
are called.
This has one drawback: nfsroot needs some more logic to handle nfs
specific data inside dhcp root-path.
The parsers have been writting according to current discussions about
cmdline arguments. This lead to the "discovery" that some test-cases
violate the spec. These tests have not been removed, but change to
"must fail".
Harald Hoyer