Hi Coiby,
On 1/15/24 07:57, Coiby Xu wrote:
On Thu, Nov 09, 2023 at 04:50:39PM +0100, Steffen Maier wrote:
> This is a preparation for consolidating s390 network device config with
>
https://github.com/dracutdevs/dracut/pull/2534
Does it mean the dracut PR depends on this patch?
I double checked and I don't think the dracut PR depends on the kdump code
changes here. They are independent.
Only
https://github.com/steffen-maier/s390utils/pull/1 depends on this
particular code change here. And s390utils/pull/1 also depends on:
https://github.com/dracutdevs/dracut/pull/2534, and
https://github.com/storaged-project/blivet/pull/1162, which is paired together
with
https://github.com/rhinstaller/anaconda/pull/5250.
When looking at the dracut PR, I notice there are some code of
95znet
dracut module seeming to duplicate what this patch is doing because this
kdump dracut module depends on the 95znet module,
if [[ $hostonly ]]; then
local _tempfile
_tempfile=$(mktemp --tmpdir dracut-zdev.XXXXXX)
{
chzdev qeth --export - --configured --persistent --quiet --type
chzdev lcs --export - --configured --persistent --quiet --type
chzdev ctc --export - --configured --persistent --quiet --type
} 2> /dev/null > "$_tempfile"
ddebug < "$_tempfile"
chzdev --import "$_tempfile" --persistent --base
"/etc=$initdir/etc" \
--yes --no-root-update --force 2>&1 | ddebug
lszdev --configured --persistent --info \
--base "/etc=$initdir/etc" 2>&1 | ddebug
rm -f "$_tempfile"
...
Does the above code will make all hostonly devices' configuration
persistent?
If hostonly mode is set (the case for kdump; kdump even uses strict hostonly
mode), then all znet persistent configurations from zdev on the root-fs are
exported and imported into the generated kdump initrd. So the answer is yes.
Above code is a compromise the avoid regressions in environments using / having
used
https://github.com/dracutdevs/dracut/blob/4980bad34775da715a2639b736cba5e...
and potentially having established an implicit dependency on its old behavior:
mostly copying the config of all (channel-attached) s390 network devices from
root-fs into initrd (I neglect the check with has_carrier() for simplicity)
[cf. the description of commits ("feat(znet): use zdev for consolidated device
configuration") and ("feat(qeth_rules): remove qeth handling consolidated in
95znet") in the dracut PR].
Strictly speaking, 95qeth_rules and its consolidated successor 95znet from the
dracut PR should only include persistent s390 network device config into any
initrd (rootfs or kdump) for just those devices actually required to mount the
root-fs or kdump target. To allow such code change in the future, the
99kdumpbase change here is coded to be independent of 95znet, so it does not
depend on 95znet, which I think is also for a slightly different use case --
see below.
But then again, we typically do not have as many network devices as we have
disk devices, so it's OK to configure the same set of network devices in early
initrd as we configure after the initrd switch root step.
If the answer is yes, the code in the 95znet dracut module
seems to interfere with what this patch is doing.
My understanding is that dracut's 95znet handles network device(s) required to
mount the root-fs or kdump target. Where the kdump target is on a
network-attached block device (such as iSCSI) or on a network file system (such
as NFS).
Please correct me if I got it wrong: 99kdumpbase handles network device(s)
required for a kdump target which is neither a block device nor a network file
system but a remote host over ssh. I'm not aware that the latter case would be
handled by core dracut and I suppose that's one of the reasons for having
99kdumpbase.
The set of devices handled by 95znet and 99kdumpbase could be different without
overlap. They could also overlap or even be the same. That's not a problem,
because the way chzdev is called by both dracut modules (after my consolidation
changes) it merges "duplicate" configurations of the same device. Hence, the
initrd finally only contains exactly one persistent config per device. So we
prevent any dangerous or interfering duplicate configs, which could cause trouble.
FWIW, I have also extensively tested the fully integrated device config
consolidation including the changes to: s390-tools (upstream), s390utils
(downstream), kexec-tools, dracut, anaconda, and blivet. For both the root-fs
mount prep case ("regular" initrd) as well as the kdump case (to block devices
(dasd and zfcp) and to ssh remote host).
--
Mit freundlichen Gruessen / Kind regards
Steffen Maier
Linux on IBM Z and LinuxONE
https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschaeftsfuehrung: David Faller
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294