Created attachment 8666 [details]
sreenshot

Created attachment 8667 [details]
screenshot2

Where shall I post this bug?

I can confirm the issue.

nov 18 15:48:35 localhost fedora-loadmodules[526]: modprobe: ERROR: could not insert 'hdaps': No such device
nov 18 15:48:35 localhost systemd[1]: fedora-loadmodules.service: Main process exited, code=exited, status=1/FAILURE


My Lenovo T420 (4180MMG) doesn't have HDAPS, afaik, so it correctly says it can't find it.

However, I doubt fedora-loadmodules should fail over that.

Assigning to hdapsd maintainer and CC'ing systemd maintainer.

Assignee: sysadmin-bugs => lists.jjorge
Source RPM: hdaps => hdapsd, systemd
Product: Infrastructure => Mageia
CC: (none) => mageia, marja11
Version: unspecified => Cauldron
Component: BuildSystem => RPM Packages

fedora-loadmodules fails if it fails to load any of the modules it's asked to load.  If there's a failing module, just remove it from whatever file it's loading from (/etc/modprobe.preload or /etc/modprobe.preload.d/*)

hello, i'm sorry for the late answer. I have attached file in /etc/modprobe.preload.d
Should I remove it?
I felt like I understood it while writing this bug but I don't get it actually.
Thank you very much anyway for answering. 
Best regards.
Koskhun

Created attachment 8816 [details]
file in /etc/modprobe.preload.d

For each file listed in /etc/modprobe.conf, /etc/modprobe.preload, or in
a file in /etc/modprobe.preload.d, check /proc/modules to see if it loaded.
If it failed to load on that hardware, remove that module from the list modules
to be loaded.

After that run "dracut -f" (as root) to update the initrd in /boot and reboot.

CC: (none) => davidwhodgins

This is an old bug that I never reproduce on 3 hardware.

Note, under virtualbox, I have a VM that has fedora-loadmodules.service to fail with missing intel_rng module (no such device).

So, inspecting
/etc/modprobe.conf    Nothing intel_rng
/etc/modprobe.preload   Culprit. intel_rng here.

Rebooting the VM: fedora-loadmodules.service no longer failed.


But, back to reporter issue.
Does this still the case?

CC: (none) => ouaurelien
Status: NEW => NEEDINFO

I could still reproduce it in cauldron today, on the same hardware as mentioned in comment 4 (when I bought it, I'm sure HDAPS wasn't among its system specifications)
mrt 05 13:09:00 localhost fedora-loadmodules[728]: Loading modules: nvram sdhci_pci evdev evdev hdaps acpi-cpufreq cpufreq_powersave cpufreq_conservative cpufreq_ondemand
mrt 05 13:09:00 localhost fedora-loadmodules[738]: modprobe: ERROR: could not insert 'hdaps': No such device
mrt 05 13:08:55 localhost systemd[1]: fedora-loadmodules.service: Main process exited, code=exited, status=1/FAILURE
mrt 05 13:08:55 localhost systemd[1]: fedora-loadmodules.service: Failed with result 'exit-code'.

Removing hdaps from /etc/modprobe.preload and then running dracut -f, as suggested by Dave Hodgins, does indeed keep fedora-loadmodules from trying to load hdaps, but hdaps is added back to /etc/modprobe.preload during next boot, so I expect the error to come back with next kernel that gets installed.

(In reply to Dave Hodgins from comment #8)
> For each file listed in /etc/modprobe.conf, /etc/modprobe.preload, or in
> a file in /etc/modprobe.preload.d,

acpi-cpufreq cpufreq_powersave cpufreq_conservative cpufreq_ondemand are in /etc/modprobe.preload.d/cpufreq

fedora-loadmodules doesn't fail on them (so this is off-topic :-þ )
> check /proc/modules to see if it loaded.
However, they don't appear in that file

Damn!

Which script/update does do this?
Therefore, this service is labelled as loading LEGACY modules...
Do we still need this?

CC: (none) => mageia, tmb
Assignee: pkg-bugs => basesystem
Status: NEEDINFO => NEW

Likely harddrake. If it is then a workaround is to add a line with
HARDDRAKE_ONBOOT=no
to /etc/sysconfig/system

Not sure if it's harddrake2 or ldetect-lst that will need to be fixed.

(In reply to Aurelien Oudelet from comment #11)
> Damn!
> 
> Which script/update does do this?
> Therefore, this service is labelled as loading LEGACY modules...
> Do we still need this?

Forgot to add, yes it's still needed to load the modules listed in
/etc/modprobe.conf, /etc/modprobe.preload, or /etc/modprobe.preload.d,
for hardware that is not yet handled by udev (as I understand it), or
to manually blacklist a module such as nouveau or nvidia.

*** Bug 28569 has been marked as a duplicate of this bug. ***

CC: (none) => pealfa

(In reply to Dave Hodgins from comment #13)
> (In reply to Aurelien Oudelet from comment #11)
> > Damn!
> > 
> > Which script/update does do this?
> > Therefore, this service is labelled as loading LEGACY modules...
> > Do we still need this?
> 
> Forgot to add, yes it's still needed to load the modules listed in
> /etc/modprobe.conf, /etc/modprobe.preload, or /etc/modprobe.preload.d,
> for hardware that is not yet handled by udev (as I understand it), or
> to manually blacklist a module such as nouveau or nvidia.

Yes. So, this is required.

Whiteboard: (none) => MGA7TOO MGA8TOO

From bug 28569#c3 ...

(In reply to Pe Alfa from comment #0)
> If I put in /etc/modprobe.preload 
> # hdaps
> failed disappears
> Is it a solution? 

Moving the failing to load modules from being loaded after the initrd switches
root to the hard drive to being loaded by the initrd does hide the problem,
but it doesn't stop the module from failing to load, or mcc insisting that
the module is needed.

So it's a workaround, not a solution. It is a valid option for those who
encounter this bug until it is fixed. Thanks for pointing it out.