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.
Bug 1547730 - Failed to start Load Kernel Modules message displayed at boot when bonding and/or bridge modules attempt to load
Summary: Failed to start Load Kernel Modules message displayed at boot when bonding an...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dracut
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-21 20:03 UTC by Dustin Black
Modified: 2018-10-30 11:28 UTC (History)
3 users (show)

Fixed In Version: dracut-033-546.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 11:26:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3232 0 None None None 2018-10-30 11:28:40 UTC

Description Dustin Black 2018-02-21 20:03:26 UTC 
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
Comment 2 Lukáš Nykrýn 2018-02-22 15:45:37 UTC 
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.
Comment 3 Lukáš Nykrýn 2018-02-22 15:49:13 UTC 
And this have been done in upstream already:
https://github.com/dracutdevs/dracut/commit/9fd3e045d
Comment 4 Dustin Black 2018-02-23 20:01:58 UTC 
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.
Comment 5 Lukáš Nykrýn 2018-02-26 11:04:42 UTC 
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.
Comment 7 Lukáš Nykrýn 2018-06-20 08:24:29 UTC 
https://github.com/dracutdevs/dracut/commit/249dcc61ea2cfb5963c7f9565dcee3405e064c7b
Comment 11 errata-xmlrpc 2018-10-30 11:26:36 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.