perf(drm): group dracut_instmods calls #26
Closed
Conversation
This file contains 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
From-dist-git-commit: a1ebaf27b616010bc672be9409ff42b8234b008d
Based on a commit 856e7ac. Currently upstream does not create releases. Reference PR: dracutdevs/dracut#2509 Unpacked archive: https://github.com/pvalena/dracut-fedora/tree/v60-srpm-unpacked
…R says so dracut may be installed without being actually used. This is very common in binary distros where a package may be pulled in through dependencies, even though the user does not need it in a particular setup. KERNEL_INSTALL_INITRD_GENERATOR is being added in systemd's kernel-install to select which of the possibly many initrd generation mechanisms will be used. For backwards compat, if it not set, continue as before. But if set to something else, skip our kernel-install plugins. (Cherry-picked commit f47bcdd7342ca0d46b889e712a1c7446e18434bc from PR#1825)
According to the synopsis, kernel-install can be called with an already-prepared initrd. In that case, no initrd should be generated by dracut. (Cherry-picked commit 0b72cf5c4eca0e0db76e3e210cfdc48e6b49bb74 from PR#1825)
- rebased from state acf404a
From-dist-git-commit: 4faeede00276da9101b9f279a9f1d1a188824021
The original dracut repository is no longer maintained, new initiative was started: https://github.com/dracut-ng/dracut-ng/
This is just internal to initrd, so we can already migrate the code to consolidated dasd device configuration with zdev https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/. The code change is transparent to users after dracut switch root. Signed-off-by: Steffen Maier <[email protected]>
This is just internal to initrd, so we can already migrate the code to consolidated zfcp device configuration with zdev https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/. The code change is transparent to users after dracut switch root. The generated persistent config of chzdev are pure udev rules so it has no dependency on other dracut modules such as zdev, or zfcp. Signed-off-by: Steffen Maier <[email protected]>
Depends on https://github.com/ibm-s390-linux/s390-tools commit 9b2fb1d4d2e2 ("zdev: add helper to convert from dasd_mod.dasd to zdev config"). This is just internal to initrd, so it's possible to migrate the code to consolidated dasd device configuration with zdev https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/. The code change is transparent to users after dracut switch root. The generated persistent config of chzdev are pure udev rules so it has no dependency on other dracut modules such as zdev, dasd, or dasd_mod. Instead now install the corresponding kernel device drivers here directly. Signed-off-by: Steffen Maier <[email protected]>
This is just internal to initrd, so we can already migrate the code to consolidated network device configuration with zdev https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/. The code change is transparent to users after dracut switch root. The generated persistent config of chzdev are pure udev rules so it has no dependency on the zdev dracut module. Keep the dependency on dracut module znet to at least pull in the required kernel device drivers. Since consolidated s390 network device configuration with zdev is used, it takes care of all s390-specific settings. None of the s390-specific ifcfg variables should be used anymore. NETTYPE, OPTIONS, PORTNAME, and CTCPROT can be removed entirely. SUBCHANNELS is kept because there are some dependency chains (probably around the key identifiying an interface which is not HWADDR): modules.d/35network-legacy/module-setup.sh parses (sources) each of /etc/sysconfig/network-scripts/ifcfg-* and if that contains SUBCHANNELS, create a symlink from the ifcfg file to /etc/sysconfig/network-scripts/ccw-${SUBCHANNELS}.conf modules.d/35network-legacy/ifup.sh installed as /sbin/ifup checks during team setup if a slave interface is an s390 channel-attached network interface and then parses (sources) /etc/sysconfig/network-scripts/ccw-${SUBCHANNELS}.conf from above, if that file exists Signed-off-by: Steffen Maier <[email protected]>
Signed-off-by: Steffen Maier <[email protected]>
These are handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@06a30ae ("zdev/dracut: add rd.zfcp cmdline option handling"). Even though this removes one implementation of parsing rd.zfcp in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.zfcp syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. This also fixes problems such as RHBZ 1552619/1745470. It was due to a duplicate configuration because the SUSE-specific module 95zfcp_rules does not have any distro-specific dependency and thus also ran in Red Hat distros. That also caused a kind of competition with 95zfcp regarding the same hook registration: inst_hook cmdline 30 "$moddir/parse-zfcp.sh" "luckily" 95zfcp wins since it runs lexicographically first and the first one registering the hook via inst_simple wins. Because commit c8aa1d9 ("95zfcp_rules: simplified rd.zfcp commandline for NPIV") extended the emitted rd.zfcp syntax for hostonly-cmdline in 95zfcp_rules, kdump initrds built with hostonly-cmdline parsed such rd.zfcp with 95zfcp, which did not understand the extended syntax yet and aborted early boot with a syntax error. It also seems that parse-zfcp.sh on its own is without effect because create_udev_rule() [similar to what zfcp_disk_configure had generated] does not handle the pre-requisite of setting an FCP device (vHBA) online first. So the rport match does not trigger unless something else happens to set an FCP device online [such as rules generated by zfcp_host_configure]. Related to commit d40c49a ("fix(zfcp_rules): remove collect based udev rule creators"). module-setup.sh having copied all udev rules from the root-fs into the initrd conflicted with s390-tools dracut module zdev-kdump, which intentionally only activates the dependencies of the kdump target. Signed-off-by: Steffen Maier <[email protected]>
Parsing of rd.zfcp is handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@06a30ae ("zdev/dracut: add rd.zfcp cmdline option handling"). Even though this removes the last implementation of parsing rd.zfcp in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.zfcp syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. For the time being, keep copying /etc/zfcp.conf. Retain the call of zfcp_cio_free so /etc/zfcp.conf gets processed even with the typical cio_ignore kernel boot parameter ignoring most devices. Also keep handling rd.zfcp.conf=0 so users can, at boot time, ignore /etc/zfcp.conf already copied into initrd. Preparation for consolidating persistent configuration with zdev. Signed-off-by: Steffen Maier <[email protected]>
These are handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@9927023 ("zdev/dracut: add rd.dasd cmdline option handling"). Even though this removes one implementation of parsing rd.dasd in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.dasd syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. module-setup.sh having copied all udev rules from the root-fs into the initrd conflicted with s390-tools dracut module zdev-kdump, which intentionally only activates the dependencies of the kdump target. Signed-off-by: Steffen Maier <[email protected]>
Parsing of rd.dasd is handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@9927023 ("zdev/dracut: add rd.dasd cmdline option handling"). Even though this removes one implementation of parsing rd.dasd in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.dasd syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. 95dasd/modules-setup.sh copies /etc/dasd.conf from root-fs into initrd. Retain the call of dasd_cio_free here so /etc/dasd.conf gets processed even with the typical cio_ignore kernel boot parameter ignoring most devices. Preparation for consolidating persistent configuration with zdev. Signed-off-by: Steffen Maier <[email protected]>
Parsing of rd.dasd is handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@9927023 ("zdev/dracut: add rd.dasd cmdline option handling"). Even though this removes the last implementation of parsing rd.dasd in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.dasd syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. For the time being, keep copying /etc/dasd.conf. The corresponding call to dasd_cio_free is in 95dasd_mod/parse-dasd-mod.sh and indirectly triggers processing of /etc/dasd.conf even with the typical cio_ignore kernel boot parameter ignoring most devices. Preparation for consolidating persistent configuration with zdev. Signed-off-by: Steffen Maier <[email protected]>
Remove any distribution-specifics from s390 channel-attached network device configuration. Similar to 95qeth_rules, copy the existing persistent network configuration into the initrd. This needs to go via chzdev import so chzdev updates (adds to) the cio_ignore persistent config inside the initrd, because other dracut modules such as zdev from s390-tools also import persistent (non-network) config into initrd and the set union of devices needs to end up in the cio_ignore persistent config inside the initrd. Additional debugging output can be generated with e.g. dracut option "--stdlog 5" (or short -L5). It shows the chzdev export result, the output of chzdev imports, and an overview of the resulting persistent config within the initrd. Typically combined with "--debug" to get a shell trace from building an initrd (Note: --debug does not increase the log levels). Note that nm-initrd-generator also parses rd.znet and rd.znet_ifname to fill in s390 options of a NetworkManager connection definition. Signed-off-by: Steffen Maier <[email protected]>
As of the preceding commit ("feat(znet): use zdev for consolidated device
configuration"), rd.znet is no longer specific to RHEL/Fedora.
Signed-off-by: Steffen Maier <[email protected]>
Dracut module 95znet handles a superset of qeth_rules as of the preceding
commit ("feat(znet): use zdev for consolidated device configuration").
The instmods list in installkernel() seemed to have been incomplete because
qeth needs one or both of qeth_l2 and qeth_l3 but qeth intentionally does
not depend on them so depmod cannot resolve that.
In contrast to the old dracut module 95znet, 95qeth_rules also did not seem
to have parsing for the upstream dracut cmdline options "rd.znet=" and
"rd.znet_ifname=".
Signed-off-by: Steffen Maier <[email protected]>
Otherwise the last rd.znet_ifname statement overwrites the persistent network interface settings of previous such statements. Signed-off-by: Steffen Maier <[email protected]>
Signed-off-by: Steffen Maier <[email protected]>
Since consolidated s390 network device configuration with zdev is used,
it takes care of all s390-specific settings.
None of the s390-specific ifcfg variables should be used anymore.
NETTYPE and OPTIONS can be removed entirely.
SUBCHANNELS is kept because there are some dependency chains
(probably around the interface identifiying key, which is not HWADDR):
modules.d/35network-legacy/module-setup.sh
parses (sources) each of /etc/sysconfig/network-scripts/ifcfg-*
and if that contains SUBCHANNELS, creates a symlink from the ifcfg file to
/etc/sysconfig/network-scripts/ccw-${SUBCHANNELS}.conf
modules.d/35network-legacy/ifup.sh installed as /sbin/ifup
checks during team setup if a slave interface is an s390 channel-attached
network interface and then parses (sources)
/etc/sysconfig/network-scripts/ccw-${SUBCHANNELS}.conf
from above, if that file exists
Signed-off-by: Steffen Maier <[email protected]>
Since systemd/systemd@ffc1ec73, /usr is mounted as read-only in the initramfs by default. Fixes #2588 Co-authored-by: Antonio Alvarez Feijoo <[email protected]>
…y included Some required libraries that used to be statically included are in the process to be opened via `dlopen()`. References: - systemd/systemd#31131 - systemd/systemd#31550 - systemd/systemd#32019 Closes #2642
When creating initramfs for universal boot image such as an installer, we can't include any machine-specific IDs. Let's move the check for /etc/nvme/hostnqn and /etc/nvme/hostid files presence to the hostonly section to avoid unsatisfied requirements. Signed-off-by: Tomas Bzatek <[email protected]> Resolves: #2266331
Module to install hwdb.bin. Further extensions might make only selected part of hwdb installable to save space. The module is not included by default. Including the module adds 2MB of compressed data (on Fedora, the file has 12MB). Installing hwdb.bin is needed in case of custom HW like a keyboard/mouse, or various interfaces. Original PR: dracutdevs/dracut#1681
as there's no reason to keep a copy; there shouldn't be any modifications. In case there are args stored in a separate file (Fedora and alike), it needs to be supplied too, but without the option to change the user.
This module loops over many bus devices, and calls `dracut_instmods` for each
one. E.g., on a Lenovo Thinkpad laptop:
```
> for i in /sys/bus/{pci/devices,platform/devices,virtio/devices,soc/devices/soc?,vmbus/devices}/*/modalias; do [[ -e $i ]] && [[ -n $(< "$i") ]] && echo $i; done | wc -l
79
```
Every call to `dracut_instmods` spawns a `dracut-install` process, which in the
previous example means calling `dracut-install` 79 times using the same
arguments.
If any call to `dracut-install` fails, dracut continues its execution (even the
errors are not shown, because it's called with `--silent`). Therefore, let's
take the contents of all the `modalias` files into an array and call
`dracut-install` only once, adding also the `-o` argument, so if any of the
modules cannot be installed, `dracut-install` does not stop.
(Cherry picked from commit 80f2caf)
Resolves: rhbz#2172269
Conan-Kudo
approved these changes
May 20, 2024
|
Is there anything to do to get this merged? The failing CI checks are unrelated to the change as far as I can tell. This 'performance' issue is resulting in broken systems because the initramfs may take more 10 minutes and people are either assuming it is hanging and power cycle their systems. |
|
Ping about this again. This is a serious ongoing source of pain for users. |
|
to bring the point along why users think their update is hanging: |
|
Hello, sorry, I must've somehow missed this. I will check my notifications. This is part of rebase to dracut-102, right? |
|
Yes, dracut-102 has the patch. In addition, dracut-ng/dracut-ng#328 (trivial patch) dracut-ng/dracut-ng#408 (relatively simple) further improve things, though this change which is already in 102 is the biggest win/major issue. |
|
@pvalena do you plan to push dracut-102 soon to Fedora 40? If not please consider to add this change to dracut-101 in Fedora 40. The performance regression on Apple silicon (probably all arm64) systems is severe. We seem to get with every kernel update at least one person who assumed the machine hang and power cycle which leaves the kernel un-bootable due to the missing initramfs image. |
Yes, that's the plan: https://src.fedoraproject.org/rpms/dracut/pull-request/60 |
|
Merged; building. Please file another PR if you want additional fixes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This module loops over many bus devices, and calls
dracut_instmodsfor each one. E.g., on a Lenovo Thinkpad laptop:Every call to
dracut_instmodsspawns adracut-installprocess, which in the previous example means callingdracut-install79 times using the same arguments.If any call to
dracut-installfails, dracut continues its execution (even the errors are not shown, because it's called with--silent). Therefore, let's take the contents of all themodaliasfiles into an array and calldracut-installonly once, adding also the-oargument, so if any of the modules cannot be installed,dracut-installdoes not stop.(Cherry picked from commit 80f2caf)
Resolves: rhbz#2172269