Bug 1547730

Summary: Failed to start Load Kernel Modules message displayed at boot when bonding and/or bridge modules attempt to load
Product: Red Hat Enterprise Linux 7 Reporter: Dustin Black <dblack>
Component: dracutAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: dracut-maint-list, jikortus, jstodola
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: dracut-033-546.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 11:26:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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