Bug 1254340

I can't reproduce this using the package from http://download.virtualbox.org/virtualbox/5.0.2/VirtualBox-5.0-5.0.2_102096_fedora22-1.x86_64.rpm. Any chance you can try with that package?

I traced down the problem. The systemd-modules-load service is run two times. First time it is run from the dracut and second time from the root filesystem. The problem happened the following way:

- kernel update caused regeneration of the dracut image - there was new kernel, so the virtualbox modules weren't there so they weren't included in the dracut image. But /usr/lib/modules-load.d/VirtualBox.conf requested the modules to load was included in the dracut image
- reboot, akmods kicked in and built Virtualbox modules

So it worked in the end, because the VirtualBox modules were loaded by the second run of the systemd-modules-load service. But the first run of systemd-modules-load service from the dracut failed. I fixed this problem by running:
# dracut -f

which included the VirtualBox modules into dracut.

I think VirtualBox modules needn't be included into dracut. So is there any way how to specify kernel modules to load from the filesystem only and not from the dracut? By e.g. moving /usr/lib/modules-load.d/VirtualBox.conf to some different directory not to be processed by first run of systemd-modules-load service from the dracut?

reassigning to dracut, which should either filter the conf file or add the kernel modules.

Fedora 21 : 

dracut failes to start the kernel modules on boot, but later on, it simply works:

[root]# systemctl status systemd-modules-load
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: active (exited) since Mi 2015-10-28 12:16:40 CET; 8s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 4996 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
 Main PID: 4996 (code=exited, status=0/SUCCESS)


as it's the first messages you see after you choose the kernel, i had to capture it via a video :)

it happens right before :

"Starting Apply Kernel Variables...
 Starting Create Static Denice Nodes in /dev..."

unfortunatly it does not wanne say why it fails.

hope this helps:

# lsmod
Module                  Size  Used by
twofish_generic        20480  0 
twofish_avx_x86_64     53248  2 
twofish_x86_64_3way    28672  1 twofish_avx_x86_64
twofish_x86_64         16384  2 twofish_avx_x86_64,twofish_x86_64_3way
twofish_common         24576  4 twofish_generic,twofish_avx_x86_64,twofish_x86_64_3way,twofish_x86_64
nls_utf8               16384  1 
udf                    94208  1 
crc_itu_t              16384  1 udf
fuse                   94208  11 
xt_CHECKSUM            16384  1 
iptable_mangle         16384  1 
ipt_MASQUERADE         16384  3 
nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
iptable_nat            16384  1 
nf_nat_ipv4            16384  1 iptable_nat
nf_nat                 28672  2 nf_nat_ipv4,nf_nat_masquerade_ipv4
nf_conntrack_ipv4      16384  2 
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
xt_conntrack           16384  1 
nf_conntrack          106496  5 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4
bridge                114688  0 
stp                    16384  1 bridge
llc                    16384  2 stp,bridge
it87                   49152  0 
hwmon_vid              16384  1 it87
uvcvideo               90112  0 
videobuf2_vmalloc      16384  1 uvcvideo
videobuf2_core         53248  1 uvcvideo
videobuf2_memops       16384  1 videobuf2_vmalloc
v4l2_common            16384  1 videobuf2_core
videodev              159744  3 uvcvideo,v4l2_common,videobuf2_core
snd_usb_audio         184320  1 
eeepc_wmi              16384  0 
snd_usbmidi_lib        32768  1 snd_usb_audio
media                  24576  2 uvcvideo,videodev
snd_hda_codec_hdmi     53248  1 
snd_rawmidi            32768  1 snd_usbmidi_lib
kvm_amd                61440  0 
asus_wmi               24576  1 eeepc_wmi
kvm                   495616  1 kvm_amd
sparse_keymap          16384  1 asus_wmi
rfkill                 24576  2 asus_wmi
video                  20480  1 asus_wmi
snd_hda_codec_realtek    90112  1 
snd_hda_codec_generic    73728  1 snd_hda_codec_realtek
snd_hda_intel          32768  6 
snd_hda_controller     32768  1 snd_hda_intel
nvidia               8667136  45 
snd_hda_codec         110592  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
snd_hda_core           36864  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_controller
snd_hwdep              16384  2 snd_usb_audio,snd_hda_codec
snd_seq                69632  0 
edac_core              57344  0 
snd_seq_device         16384  2 snd_seq,snd_rawmidi
edac_mce_amd           24576  0 
k10temp                16384  0 
fam15h_power           16384  0 
snd_pcm               118784  5 snd_usb_audio,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller
sp5100_tco             16384  0 
i2c_piix4              24576  0 
snd_timer              32768  2 snd_pcm,snd_seq
snd                    81920  27 snd_hda_codec_realtek,snd_usb_audio,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_usbmidi_lib,snd_hda_codec,snd_hda_intel,snd_seq_device
drm                   331776  3 nvidia
soundcore              16384  1 snd
tpm_infineon           20480  0 
tpm_tis                20480  0 
shpchp                 40960  0 
tpm                    36864  2 tpm_tis,tpm_infineon
acpi_cpufreq           20480  0 
binfmt_misc            20480  1 
vboxnetadp             28672  0 
vboxnetflt             28672  0 
vboxdrv               405504  2 vboxnetadp,vboxnetflt
dm_crypt               28672  8 
crct10dif_pclmul       16384  0 
crc32_pclmul           16384  0 
crc32c_intel           24576  0 
ghash_clmulni_intel    16384  0 
serio_raw              16384  0 
mxm_wmi                16384  0 
r8169                  86016  0 
mii                    16384  1 r8169
wmi                    20480  2 mxm_wmi,asus_wmi

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

I'm seeing this exact same behaviour in Fedora 25 with kernel 4.8.10-300.fc25.x84_84 specifically. Starting the previous kernels from GRUB2 works okay still without the error message.

My machine is a bare metal installation.

It's also been reported by another user on fedoraforum.org

http://forums.fedoraforum.org/showthread.php?t=312374

Please change Version: to 25. I didn't want to open a duplicate bug for an existing problem that's re-occurred here.

Potential cause:

Nov 30 23:33:33 KABINI.fedora systemd-modules-load[187]: Failed to find module 'nf_conntrack_pptp'


Manifestation: [FAILED]  failed to start load kernel modules
See 'systemctl status systemd-modules-load.service' for details .

Output of suggested status check:

systemctl status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled)
   Active: active (exited) since Thu 2016-12-01 07:44:36 GMT; 4min 24s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 700 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
 Main PID: 700 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/systemd-modules-load.service

(In reply to Mike Simms from comment #6)
(In reply to Mike Simms from comment #7)

I don't think that this is the same bug. See bug #1400041 instead.

I am receiving the same error. I recently did a bare metal install and do not have VirtualBox installed.

"systemctl status systemd-modules-load.service" shows no errors
"journalctl -u systemd-modules-load.service" shows no errors

package kernel-core-4.8.10-300.fc25

[FAILED]  failed to start load kernel modules
See 'systemctl status systemd-modules-load.service' for details .

● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled)
   Active: active (exited) since Tue 2016-12-06 06:24:13 EST; 55s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 1038 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
 Main PID: 1038 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/systemd-modules-load.service

Dec 06 06:24:13 localhost.localdomain systemd-modules-load[1038]: Inserted module 'nf_conntrack_pptp'
Dec 06 06:24:13 localhost.localdomain systemd[1]: Started Load Kernel Modules.

I get the same error and found this:

systemd-modules-load[187]: Failed to find module 'nf_conntrack_pptp'

in the journal. This started after upgrade from kernel 4.8.6. lsmod shows the module is loaded so should I just ignore the error as suggested in bug #1400041 and wait for a fix - I am way out of my depth in this field!

I'm exactly in the same situation as Neil, except that for me this started with 4.8.10.

Forgot to say, I'm in Fedora 25, so as Mike suggested, version should be changed to 25.

You don't need to report that this bug affects you, the reason why this happens is understood. This issue is triggered by the first initramfs being regenerated after installing pptp, which usually happens at a kernel update.

(In reply to Christian Stadelmann from comment #13)
> You don't need to report that this bug affects you, the reason why this
> happens is understood. This issue is triggered by the first initramfs being
> regenerated after installing pptp, which usually happens at a kernel update.

BTW I dropped the nf_conntrack_pptp module autoloading in new rebased version of PPTP (1.9.0). According to upstream it shouldn't be autoloaded as it is usually not needed on non-routers and only workarounds/hides real problems. New PPTP contains some fixes for better interoperability. You can still autoload the module manually if you really need it. But keeping this bug open as the requested functionality could be useful for others.

I'm not sure whether the problem I'm having is really the same one. With F25 x86_64 on an AMD FX-8350 processor, systemd-modules-load.service failed, but status isn't telling me why it failed:

$ systemctl status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-12-14 21:45:07 MST; 3 days ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
 Main PID: 1298 (code=exited, status=1/FAILURE)

Dec 14 21:45:07 p1.lan systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
Dec 14 21:45:07 p1.lan systemd[1]: Failed to start Load Kernel Modules.
Dec 14 21:45:07 p1.lan systemd[1]: systemd-modules-load.service: Unit entered failed state.
Dec 14 21:45:07 p1.lan systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.

(In reply to Eric Smith from comment #15)
> I'm not sure whether the problem I'm having is really the same one. With F25
> x86_64 on an AMD FX-8350 processor, systemd-modules-load.service failed, but
> status isn't telling me why it failed:
> 
> $ systemctl status systemd-modules-load.service
> ● systemd-modules-load.service - Load Kernel Modules
>    Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service;
> static; vendor preset: disabled)
>    Active: failed (Result: exit-code) since Wed 2016-12-14 21:45:07 MST; 3
> days ago
>      Docs: man:systemd-modules-load.service(8)
>            man:modules-load.d(5)
>  Main PID: 1298 (code=exited, status=1/FAILURE)
> 
> Dec 14 21:45:07 p1.lan systemd[1]: systemd-modules-load.service: Main
> process exited, code=exited, status=1/FAILURE
> Dec 14 21:45:07 p1.lan systemd[1]: Failed to start Load Kernel Modules.
> Dec 14 21:45:07 p1.lan systemd[1]: systemd-modules-load.service: Unit
> entered failed state.
> Dec 14 21:45:07 p1.lan systemd[1]: systemd-modules-load.service: Failed with
> result 'exit-code'.

Are you able to insert the modules by restart of the systemd-modules-load.service? Are you able to insert the modules manually? Is the result same with the selinux disabled and reboot? If all answers are yes, then your problem is probably related.

On Fedora 25 i'm having the same problem as Jaroslav Škarvada with the vbox* modules. After kernel upgrades i'm getting systemd-modules-load errors on boot until i rebuild the intitramfs and the vbox*-modules are getting included.

I had VirtualBox working on Fedora 25 using the VirtualBox and akmod-VirtualBox packages from Fedora repositories until maintenance near end of February broke things with a systemd-modules-load.service failure. 

 As su I tried:
akmods   (which said the module was OK)
systemctl restart systemd-modules-load.service   (which failed but produced an SE alert for systemd_modules_load_t  being denied "module_load" for vboxdrv.ko with tcontext of modules_object_t.

SELinux Troubleshooter suggested applying a local policy fix via
ausearch -c 'systemd-modules' --raw | audit2allow -M my-systemdmodules
semodule -X 300 -i my-systemdmodules.pp
  after which
systemctl restart systemd-modules-load.service 

ran successfully and VirtualBox was happy again.
I've been through subsequent kernel updates and re-boots and this fix seems to have resolved the issue.

This was obviously a different problem than the one originally reported here, as in my case the modules existed but SELinux was just preventing loading.  I suspect discussing this variant here may be useful to others since the bug title clearly fits, even though this particular failure was apparently just introduced by f25 maintenance in February 2017.

(In reply to Joel C Ewing from comment #18)
> This was obviously a different problem than the one originally reported
> here, as in my case the modules existed but SELinux was just preventing
> loading.  I suspect discussing this variant here may be useful to others
> since the bug title clearly fits, even though this particular failure was
> apparently just introduced by f25 maintenance in February 2017.

I think I have also encountered this (different) problem and filled: 
https://bugzilla.redhat.com/show_bug.cgi?id=1427896

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

still happens under Fedora 25

This still happens in Fedora 26. Every time there is a kernel upgrade I run akmods and dracut to resolve this issue.

Even I have same problem on Fedora 25. Looking for next kernel update to fix this problem. 

Error on opening Virtual Box:

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is probably not loaded.You may not have kernel driver installed for kernel that is runnig, if so you may do as root: dnf install akmod-VirtualBox kernel-devel-$(uname -r)If you installed VirtualBox packages and don't want reboot the system, you may need load the kernel driver, doing as root: akmods; systemctl restart systemd-modules-load.service


where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT.

The dracut side of this bug should be fixed. dracut should install all kernel drivers present in /usr/lib/modules-load.d and /etc/modules-load.d

If akmods recompiles drivers later, then it should run dracut afterwards.

The problem is that VirtualBox modules needn't be included into dracut image.
Is there any way how to exclude kernel modules from the initramfs and to load they from the root filesystem only?

(In reply to Elia Devito from comment #25)
> The problem is that VirtualBox modules needn't be included into dracut image.
> Is there any way how to exclude kernel modules from the initramfs and to
> load they from the root filesystem only?

This is fairly simple: Create a new file in /etc/dracut.conf.d and put a line into it like this one:

omit_drivers+=" usb-storage uas ums-* snd soundcore snd-* "

This will omit a few specified kernel modules. Those modules will be load after the kernel switched to your root filesystem if necessary.

Then, you will need to regenerate your initramfs by running

# dracut

(i.e. as root or with sudo). You might need the "--force" option. See `man 5 dracut.conf` for details.

(In reply to Christian Stadelmann from comment #26)
> (In reply to Elia Devito from comment #25)
> > The problem is that VirtualBox modules needn't be included into dracut image.
> > Is there any way how to exclude kernel modules from the initramfs and to
> > load they from the root filesystem only?
> 
> This is fairly simple: Create a new file in /etc/dracut.conf.d and put a
> line into it like this one:
> 
> omit_drivers+=" usb-storage uas ums-* snd soundcore snd-* "
> 
> This will omit a few specified kernel modules. Those modules will be load
> after the kernel switched to your root filesystem if necessary.
> 
> Then, you will need to regenerate your initramfs by running
> 
> # dracut
> 
> (i.e. as root or with sudo). You might need the "--force" option. See `man 5
> dracut.conf` for details.

The issue is still here

If I exclude virtualbox modules through a config file in the /etc/dracut.d/ folder dracut does not include modules but keeps including /lib/modules.load.d/VirtualBox.conf file causing a warning at startup, there is a standard way to load a module at system startup only and exclude it from Initramfs?

(In reply to Elia Devito from comment #27)
> The issue is still here
> 
> If I exclude virtualbox modules through a config file in the /etc/dracut.d/
> folder dracut does not include modules but keeps including
> /lib/modules.load.d/VirtualBox.conf file causing a warning at startup, there
> is a standard way to load a module at system startup only and exclude it
> from Initramfs?

I don't think I can answer this question. Having virtualbox provide a config file in /lib/modules.load.d/ sounds pretty bad style to me. Kernel modules should be written in a way that they can be automatically loaded on demand and you should be able to use a systemd service, timer or target to do so.

PS: Please don't needinfo me on this bug, I doubt I can help and I try to read your comment even without needinfo.

The main problem with dracut during initram is:

1. It uses systemd-modules-load to load modules.
   This reads modules from various directories including /usr/lib/modules-load.d/*.conf

2. If Virtualbox is installed, it will therefore read /usr/lib/modules.load.d/VirtualBox.conf
   This requests vboxdrv and others.

3. These modules are not included in initramfs, which leads to the error message.
   Booting continues, as these modules are not needed for booting.

4. After switch_root, systemd-modules-load is executed by real systemd on root filesystem.
   This will again load VirtualBox.conf and request vboxdrv which is now available and loads.

I see these solutions:

a. As dracut uses systemd-modules-load it should include all modules requested from that.
   TODO: Extend dracut modules find algorithm to follow systemd-modules-load

b. remove /usr/lib/modules.load.d/VirtualBox.conf from initramfs as these modules are not needed
   during boot.
   QUESTION: How should dracut know, which conf files to include and which to ignore?

c. At least disable the error message from initramfs' systemd-modules-load and always exit(0).
   If there is a major problem, rd.shell will pop up.

I favor for solution a. so dracut should be extended to follow systend-modules-load

Additional debugging showed, that dracut follows systemd-modules-load and includes vboxdrv from VirtualBox.conf. So by using "dracut --force" on a installed system fixes the problem.

Therefore, this does not seem to be a dracut problem. I assume it is more a problem of rpm scripts included in kernel rpms building initramfs in a wrong way (probably without using "dracut").

Problem identified for VirtualBox: The problem occurs after updating a kernel when VirtualBox is already installed:

1. rpm -U kernel...
   This installs all modules and creates a new initramfs using dracut. It contains VirtualBox.conf but not the needed modules, as they are (not yet) available.

2. A few seconds later, akmod finds out, that the virtualbox modules are missing and creates them by compiling source code.

3. Now the modules are available, but initramfs is already created in step 1. This leads to the error message on next reboot.

Solution #1

Manually execute "dracut -f" after updating the kernel and waiting for akmod (a few minutes after installing the kernel).
This works, but is not nice as a manual step has to be done and remembered.

Solution #2

Somehow tell akmod to execute "dracut -f" after building the module. I assume this is a missing feature of akmod.

However, it is not a dracut problem, so closing it.

Bugopened at RPMFusion: 

https://bugzilla.rpmfusion.org/show_bug.cgi?id=5329


@Bubeck:  Why not simply remove those unneccessary mods from dracuts and systemds load list?

(In reply to customercare from comment #32)
> Bugopened at RPMFusion: 
> 
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=5329
> 
> 
> @Bubeck:  Why not simply remove those unneccessary mods from dracuts and
> systemds load list?

Currently we have the modules and /usr/lib/modules.load.d/VirtualBox.conf to load them with systemd-modules-load. The (loaded) modules are needed by VirtualBox, so they must be loaded on boot.
dracut includes every file from /usr/lib/modules.load.d/*.conf but is not able to include the modules (as they are not available during rpm -U kernel..). This leads to the problem.

However, /usr/lib/modules.load.d/VirtualBox.conf is used by the second run of systemd-modules-load. So there is no option to remove it from the system. 
This file could be omitted by dracut for including in initramfs (as they modules are missing and it is used by the second run). But I see no option to omit a file for inclusion by dracut. 

So, I dont know how. :)

I removed VirtualBox but I still have this issue. I don't even have /usr/lib/modules.load.d/ on the system anymore.

I think systemd should emit a warning, but not cause the service to fail if a module is not found. This happens
quite often, and making the service fail is unnecessarily harsh. I'll work on a patch to change systemd-modules-load.

https://github.com/systemd/systemd/pull/13856

What might be causing it in absence of VirtualBox?

i.e. Nvidia

FEDORA-2019-4c3ce3aa5c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4c3ce3aa5c

systemd-243.4-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4c3ce3aa5c

What will be the behavior with the latest update? Will it still fail, but skip displaying the error at the boot time, require me to run dracut command and reboot?

The service will emit an error message that it cannot load the module, but will report failure to systemd, so there will be warning in the logs, but e.g. 'systemctl --failed' will that. If you actually need the module to be loaded in the initramfs, then yes, you'd need to run dracut to generate an initramfs that contains the module. But in general running dracut should not be necessary.

systemd-243.4-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Still happening with systemd-243.4-1.fc31.x86_64.

(In reply to Dima Ryazanov from comment #44)
> Still happening with systemd-243.4-1.fc31.x86_64.

It is not clear what you mean by "still".
Do you still see this message:
srp 17 20:07:21 yarda systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
?

Also, did you rebuild your initramfs after updating systemd?