http://bugzilla.opensuse.org/show_bug.cgi?id=962235 Bug ID: 962235 Summary: systemd-modules-load.service fails inside initrd if snd_aloop is listed in /etc/modules-load.d Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Minor Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: Yarny@public-files.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 661992 --> http://bugzilla.opensuse.org/attachment.cgi?id=661992&action=edit Output of "journalctl --boot" after the failure occured during boot Loading the kernel-module 'snd_aloop' via modules-load.d somehow propagates into the initrd as soon as that is recreated. However, loading this module fails for some reason within the initrd. It succeeds lateron, after the boot process left the initrd. To reproduce: $ echo 'snd_aloop' > /etc/modules-load.d/snd_aloop.conf $ mkinitrd $ reboot # then watch out for "[FAILED] Failed to start Load Kernel Modules." dmesg shows lots of messages like
snd_aloop: Unknown symbol snd_ctl_add (err 0) snd_aloop: Unknown symbol snd_pcm_lib_free_vmalloc_buffer (err 0) snd_aloop: Unknown symbol snd_pcm_new (err 0) (see attached output of "journalctl --boot").
It's not clear to my why it (dracut?) tries to load the module inside the initrd -- loading it after leaving the initrd would be sufficient. I tried to suppress it with the kernel command-line argument "rd.driver.blacklist=snd_aloop", but to no effect. The boot process itself is not interrupted by this failure, so this is merely a cosmetic problem. Yet, a service failure during early boot, prominently visible while the luks passphrase is requested, is quite irritating for the user. BTW, loading the "lp" module with the same mechanism works fine. -- You are receiving this mail because: You are on the CC list for the bug.