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:
The very first message in the dracut boot list is a red [ FAILED ] message for Load Kernel Modules. Logs report "Failed to start Load Kernel Modules" message. The problem is only really cosmetic, as the systemd-modules-load service start runs again after the root filesystem is mounted, and the modules then load correctly. However, this it is an undesirable user experience to see this FAILED message when the system boots.
Version-Release number of selected component (if applicable):
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)
# uname -a
Linux g1-fresh 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 13 10:46:25 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
# rpm -qa |grep -i dracut
dracut-network-033-502.el7.x86_64
dracut-033-502.el7.x86_64
How reproducible:
Message is consistent in VM test environment. No bonding or bridging is in use. Message has also been observed consistently in hardware lab on same versions.
Steps to Reproduce:
1. Boot system
2. Observe message
3. Roll eyes
Actual results:
Ugly but innocuous [ FAILED ] message displayed early in the boot process
Expected results:
Service should instead display [ OK ]
Additional info:
From journal:
Feb 21 19:59:06 g1-fresh systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Feb 21 19:59:06 g1-fresh systemd[1]: Failed to start Load Kernel Modules.
Feb 21 19:59:06 g1-fresh systemd[1]: Unit systemd-modules-load.service entered failed state.
Feb 21 19:59:06 g1-fresh systemd[1]: systemd-modules-load.service failed.
Feb 21 19:59:06 g1-fresh systemd[1]: Starting Apply Kernel Variables...
Feb 21 19:59:06 g1-fresh systemd[1]: Started Create Static Device Nodes in /dev.
Feb 21 19:59:06 g1-fresh systemd[1]: Started Apply Kernel Variables.
Feb 21 19:59:06 g1-fresh systemd-journal[97]: Journal started
-- Subject: The journal has been started
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- The system journal process has started up, opened the journal
-- files for writing and is now ready to process requests.
Feb 21 19:59:06 g1-fresh systemd-modules-load[93]: Failed to find module 'bonding'
Feb 21 19:59:06 g1-fresh systemd-modules-load[93]: Failed to find module 'bridge'
Feb 21 19:59:06 g1-fresh systemd-modules-load[93]: Inserted module '8021q'
Later, when systemd-modules-load attempts to start again after loading the root filesystem:
Feb 21 19:59:08 g1-fresh systemd-modules-load[510]: Inserted module 'bonding'
Feb 21 19:59:08 g1-fresh systemd-modules-load[510]: Inserted module 'bridge'
-- Subject: Unit systemd-modules-load.service has finished start-up
So my theory is following.
You (or a package) have modified the modules-load configuration and recreate initrd just after that.
Because the module was loaded at that time, dracut did not include it in the image. If you would have rebooted, between those two actions, the module would be loaded and dracut would have included it in the image. Or you can use the --no-hostonly option.
But anyway, maybe we should change the behavior here and always include the module in such case.
I wouldn't guarantee that something we have done with these systems hasn't caused the problem similar to what you described, however, these are systems that have been freshly built by kickstart from the latest RHGS ISO. So there is no in-between process or step that should have caused the problem -- this is simply showing up on a fresh install.
Yep, it was most certainly caused by a package installation, not by a user. But anyway it is easy to fix on Dracut side. Since this is not a blocker, I will schedule it for 7.6.
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-2018:3232