On Mon, Jan 15, 2024 at 05:19:24PM +0100, Steffen Maier wrote:
Hi Coiby,
Hi Steffen,
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.
Thank for the explanation! The dracut PR says "Those module sets partly
competed with each other and partly contradicted each other such as
activating too many devices for a memory-limited kdump environment" so I
thought there are use cases where memory consumption for kdump needs to
be reduced.
And the word hostonly has different meaning for me. I thought all active
znet devices will be enabled. Actually only persistent configurations
will be imported into the kdump initrd according to my test.
So considering "we typically do not have as many network devices" and only
persistent device is enabled, my guess is the 95znet module won't cause
excess memory consumption. But it's still an issue, we can make 95znet
support the --hostonly-nics argument. Currently when building a kdump
image, dracut is called with an empty --hostonly-nics argument. So
95znet can enable no znet device when --hostonly-nics is empty.
>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.
99kdumpbase supports dumping to an nfs or ssh fs. For both cases, it
needs to make sure the required network devices can be activated
successfully. Ideally 99kdumpbase should be upstreamed and delegate as
the work to dependent modules (95znet in this case) as much as possible!
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).
Thank you for your efforts of extensively testing the fully integrated
consolidation!
In conclusion, I don't see a problem with this patch set and will merge
it. Thank you for clearing up my confusion!
--
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
--
_______________________________________________
kexec mailing list -- kexec(a)lists.fedoraproject.org
To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Best regards,
Coiby