Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Currently in Fedora/RedHat dracut installs its fedora.conf.example
as the default config file, in which sysloglvl is set 5. This leads
to maxloglvl=5 in dracut calls, making unnecessary lsinitrd calls
during initramfs builds by kdump.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
This issue still exists on latest RHEL-7, there is a merged upstream dracut patch:
https://github.com/dracutdevs/dracut/pull/272/commits/bd93e9287d9c6e1a2aa17b7f90dc13fdcba2157c
That skip the unnecessary lsinitrd call when --quiet is used, and kdump's mkdumprd is using --quiet, so this problem is fixed in RHEL-8.
I think it will be better to just backport this patch for dracut on RHEL-7
(In reply to Kairui Song from comment #4)
> This issue still exists on latest RHEL-7, there is a merged upstream dracut
> patch:
> https://github.com/dracutdevs/dracut/pull/272/commits/
> bd93e9287d9c6e1a2aa17b7f90dc13fdcba2157c
>
> That skip the unnecessary lsinitrd call when --quiet is used, and kdump's
> mkdumprd is using --quiet, so this problem is fixed in RHEL-8.
> I think it will be better to just backport this patch for dracut on RHEL-7
There is also an commit required to be backported for kexec-tools:
commit 69ba16a409b1260ac3a5451ec5f3f2eac244b73c
Author: Dave Young <dyoung>
Date: Wed Sep 6 15:25:59 2017 +0800
mkdumprd: use --quiet dracut argument to speedup initramfs build
FYI, Another account found similar issue on kernel 3.10.0-957.1.3.el7.x86_64
Physical HP BL460 Gen 9 blade with RHEL 7.6, kernel 3.10.0-957.1.3.el7.x86_64. RAM: 64 GB.
By default, kdump initrd will be rebuilt when necessary.
a) Using default configuration, the boot process takes too long, even when there are no package or kernel updates:
# systemd-analyze
Startup finished in 1.265s (kernel) + 12.022s (initrd) + 1min 3.411s (userspace) = 1min 16.699s
# systemd-analyze blame
44.303s kdump.service
15.766s network.service
13.120s tidal.service
10.276s arpwatch.service
6.380s hp-snmp-agents.service
...
b) When we force_no_rebuild to 1 in /etc/kdump.conf to bypass rebuilding of kdump initrd, the boot is much faster:
# systemd-analyze
Startup finished in 1.264s (kernel) + 12.066s (initrd) + 32.050s (userspace) = 45.381s
# systemd-analyze blame
15.689s network.service
13.108s tidal.service
6.981s arpwatch.service
6.299s hp-snmp-agents.service
2.125s postfix.service
2.069s lvm2-pvscan@8:3.service
2.069s lvm2-pvscan@8:6.service
1.665s commvault.Instance001.service
1.207s tuned.service
1.109s lvm2-pvscan@8:5.service
818ms systemd-udev-settle.service
739ms dev-mapper-os\x2droot.device
629ms lvm2-monitor.service
420ms snmpd.service
349ms httpd.service
227ms systemd-journal-flush.service
221ms nfs-server.service
195ms kdump.service
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2019:2134