Bug 1116849

Can you check the content of the journal and see if there're interesting logs from systemd-modules-load.service ?

If not it might be interesting to reboot with the debug logs enabled (append "systemd.log_level=debug printk.devkmsg=on" to the kernel command line).

Another question: do your system have a separate /usr ?

Martin, we recently moved sg.conf out from systemd package to suse-modules-load.service so this might be related...

I just noticed that you choose to place sg.conf in /etc/... but I'm not sure to understand why as /etc is sysadmin's territory. We used to have it in /usr/... but if this module can be involved to mount /usr, /lib might be a better choice.

(In reply to Franck Bui from comment #1)
> Can you check the content of the journal and see if there're interesting
> logs from systemd-modules-load.service ?

# journalctl -u systemd-modules-load.service
-- Logs begin at Tue 2019-01-29 10:07:43 CET, end at Tue 2019-01-29 14:49:44 CET. --
jan 29 10:07:43 eiktum systemd-modules-load[221]: Inserted module 'scsi_dh_alua'
jan 29 10:07:43 eiktum systemd-modules-load[221]: Inserted module 'scsi_dh_emc'
jan 29 10:07:43 eiktum systemd-modules-load[221]: Inserted module 'scsi_dh_rdac'
jan 29 10:07:43 eiktum systemd-modules-load[221]: Inserted module 'dm_multipath'
jan 29 10:07:43 eiktum systemd-modules-load[221]: Inserted module 'sg'
jan 29 10:07:43 eiktum systemd-modules-load[221]: Failed to insert module 'snd_hda_intel': No such file or directory
jan 29 10:07:43 eiktum systemd[1]: Started Load Kernel Modules.
jan 29 10:07:46 eiktum systemd[1]: Stopped Load Kernel Modules.
jan 29 10:08:03 eiktum systemd-modules-load[439]: Inserted module 'snd_hda_intel'
jan 29 10:08:03 eiktum systemd[1]: Started Load Kernel Modules.

> If not it might be interesting to reboot with the debug logs enabled (append
> "systemd.log_level=debug printk.devkmsg=on" to the kernel command line).

will come next

Another question: do your system have a separate /usr ?
# df -h /usr
Bestandssysteem Grootte Gebruikt Besch Geb% Aangekoppeld op
/dev/sda2           20G      16G  3,6G  82% /

(In reply to Franck Bui from comment #1)
> If not it might be interesting to reboot with the debug logs enabled (append
> "systemd.log_level=debug printk.devkmsg=on" to the kernel command line).

# journalctl -u systemd-modules-load.service
-- Logs begin at Tue 2019-01-29 15:00:30 CET, end at Tue 2019-01-29 15:06:39 CET. --
jan 29 15:00:32 eiktum systemd[1]: systemd-modules-load.service: Changed dead -> exited
jan 29 15:00:32 eiktum systemd[1]: systemd-modules-load.service: Installed new job systemd-modules-load.service/stop as 121
jan 29 15:00:32 eiktum systemd[1]: systemd-modules-load.service: Changed exited -> dead
jan 29 15:00:32 eiktum systemd[1]: systemd-modules-load.service: Job systemd-modules-load.service/stop finished, result=done
jan 29 15:00:32 eiktum systemd[1]: Stopped Load Kernel Modules.
jan 29 15:00:56 eiktum systemd[444]: systemd-modules-load.service: Executing: /usr/lib/systemd/systemd-modules-load
jan 29 15:00:56 eiktum systemd-modules-load[444]: Skipping overridden file '/usr/lib/modules-load.d/sg.conf'.
jan 29 15:00:56 eiktum systemd-modules-load[444]: apply: /usr/lib/modules-load.d/multipath.conf
jan 29 15:00:56 eiktum systemd-modules-load[444]: Loading module: scsi_dh_alua
jan 29 15:00:56 eiktum systemd-modules-load[444]: Module 'scsi_dh_alua' is already loaded
jan 29 15:00:56 eiktum systemd-modules-load[444]: Loading module: scsi_dh_emc
jan 29 15:00:56 eiktum systemd-modules-load[444]: Module 'scsi_dh_emc' is already loaded
jan 29 15:00:56 eiktum systemd-modules-load[444]: Loading module: scsi_dh_rdac
jan 29 15:00:56 eiktum systemd-modules-load[444]: Module 'scsi_dh_rdac' is already loaded
jan 29 15:00:56 eiktum systemd-modules-load[444]: Loading module: dm_multipath
jan 29 15:00:56 eiktum systemd-modules-load[444]: Module 'dm_multipath' is already loaded
jan 29 15:00:56 eiktum systemd-modules-load[444]: apply: /etc/modules-load.d/sg.conf
jan 29 15:00:56 eiktum systemd-modules-load[444]: Loading module: sg
jan 29 15:00:56 eiktum systemd-modules-load[444]: Module 'sg' is already loaded
jan 29 15:00:56 eiktum systemd-modules-load[444]: apply: /etc/modules-load.d/yast.conf
jan 29 15:00:56 eiktum systemd-modules-load[444]: Loading module: snd-hda-intel
jan 29 15:00:57 eiktum systemd-modules-load[444]: Inserted module 'snd_hda_intel'
jan 29 15:00:57 eiktum systemd[1]: systemd-modules-load.service: Child 444 belongs to systemd-modules-load.service.
jan 29 15:00:57 eiktum systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=0/SUCCESS
jan 29 15:00:57 eiktum systemd[1]: systemd-modules-load.service: Changed start -> exited
jan 29 15:00:57 eiktum systemd[1]: systemd-modules-load.service: Job systemd-modules-load.service/start finished, result=done
jan 29 15:00:57 eiktum systemd[1]: Started Load Kernel Modules.
jan 29 15:01:11 eiktum systemd[1]: systemd-modules-load.service: Changed dead -> exited
jan 29 15:01:24 eiktum systemd[1]: systemd-modules-load.service: Changed dead -> exited
jan 29 15:01:25 eiktum systemd[1]: systemd-modules-load.service: Changed dead -> exited
jan 29 15:01:26 eiktum systemd[1]: systemd-modules-load.service: Changed dead -> exited

(In reply to Freek de Kruijf from comment #4)
> [...]
> jan 29 10:07:43 eiktum systemd-modules-load[221]: Failed to insert module
> 'snd_hda_intel': No such file or directory

Interesting at this point the module can't be found...

> jan 29 10:08:03 eiktum systemd-modules-load[439]: Inserted module 'snd_hda_intel'

but soon after it was found...

It would have been interesting to see the full logs so we could have seen what made the module available.

My guess is that the module is missing in the initramfs.

Could you run the following command ?

  $ lsinitrd | grep "snd_hda_intel\|modules-load"

> Another question: do your system have a separate /usr ?
> # df -h /usr
> Bestandssysteem Grootte Gebruikt Besch Geb% Aangekoppeld op
> /dev/sda2           20G      16G  3,6G  82% /

Apparently /usr doesn't have a dedicated partition on your system, does it ?

(In reply to Franck Bui from comment #6)
> (In reply to Freek de Kruijf from comment #4)
> Could you run the following command ?
> 
>   $ lsinitrd | grep "snd_hda_intel\|modules-load"

# lsinitrd | grep "snd_hda_intel\|modules-load"
drwxr-xr-x   2 root     root            0 Jan 26 13:44 etc/modules-load.d
-rw-r--r--   1 root     root          102 Nov  7 15:48 etc/modules-load.d/sg.conf
-rw-r--r--   1 root     root           14 Apr 20  2018 etc/modules-load.d/yast.conf
drwxr-xr-x   2 root     root            0 Jan 26 13:44 usr/lib/modules-load.d
-rw-r--r--   1 root     root          102 Jan 10 15:19 usr/lib/modules-load.d/multipath.conf
-rw-r--r--   1 root     root            3 Dec  7 14:44 usr/lib/modules-load.d/sg.conf
-rwxr-xr-x   1 root     root        18560 Dec 10 13:37 usr/lib/systemd/systemd-modules-load
lrwxrwxrwx   1 root     root           31 Jan 26 13:44 usr/lib/systemd/system/sysinit.target.wants/systemd-modules-load.service -> ../systemd-modules-load.service
-rw-r--r--   1 root     root         1011 Dec 10 13:36 usr/lib/systemd/system/systemd-modules-load.service

> > Another question: do your system have a separate /usr ?
> > # df -h /usr
> > Bestandssysteem Grootte Gebruikt Besch Geb% Aangekoppeld op
> > /dev/sda2           20G      16G  3,6G  82% /
> 
> Apparently /usr doesn't have a dedicated partition on your system, does it ?

Right, it does not.

can you find snd_hda_intel in one of the following .conf file ?
                                          
 /etc/modules-load.d/sg.conf
 /usr/lib/modules-load.d/multipath.conf
 /etc/modules-load.d/yast.conf

(In reply to Franck Bui from comment #8)
> can you find snd_hda_intel in one of the following .conf file ?
>                                           
>  /etc/modules-load.d/sg.conf
>  /usr/lib/modules-load.d/multipath.conf
>  /etc/modules-load.d/yast.conf

Nowhere to be found.

(In reply to Freek de Kruijf from comment #9)
> Nowhere to be found.

According to:

> jan 29 15:00:56 eiktum systemd-modules-load[444]: apply: /etc/modules-load.d/yast.conf
> jan 29 15:00:56 eiktum systemd-modules-load[444]: Loading module: snd-hda-intel

it's in yast.conf...

Can you try to find where snd-hda-intel is defined (try using grep for example) ?

(In reply to Franck Bui from comment #3)
> Martin, we recently moved sg.conf out from systemd package to
> suse-modules-load.service so this might be related...
> 
> I just noticed that you choose to place sg.conf in /etc/... but I'm not sure
> to understand why as /etc is sysadmin's territory. We used to have it in
> /usr/... but if this module can be involved to mount /usr, /lib might be a
> better choice.

This is the rationale:

    Move sg.conf to /etc and mark it as config file
    
    suse-module-tools traditionally places files below /etc and not
    /usr/lib. On non-SCSI systems, forcing sg to load makes no sense;
    make it easier for admins to override that behavior.

(In reply to Franck Bui from comment #10)
> it's in yast.conf...
> 
> Can you try to find where snd-hda-intel is defined (try using grep for
> example) ?

Yes. Its in /etc/modules-load.d/yast.conf; its the only line in that file.
Also in /etc/modprobe.d/50-sound.conf, /etc/modprobe.d/50-sound.conf.YaST2save and
/etc/modprobe.d/my-alsa.conf

> /etc/modules-load.d/yast.conf

Where does that file come from? I don't have it on my system. What exactly is the content?

Also what the output of:

 $ lsinitrd -f etc/modules-load.d/yast.conf

(In reply to Martin Wilck from comment #13)
> > /etc/modules-load.d/yast.conf
> 
> Where does that file come from? I don't have it on my system. What exactly
> is the content?

It is inserted on Apr 20, 2018 see attached y2log.

Created attachment 795539 [details]
y2log-2.gz

yast2 logfile compressed

(In reply to Franck Bui from comment #14)
> Also what the output of:
> 
>  $ lsinitrd -f etc/modules-load.d/yast.conf

# lsinitrd -f etc/modules-load.d/yast.conf
snd-hda-intel

To sum up:

 - for some unknown reasons YaST2 created  /etc/modules-load.d/yast.conf which
   lists snd-hda-intel

 - yast.conf is included in initrd but snd-hda-intel is missing
   from there therefore the loading of this module fails inside initramfs

 - after switching to rootfs, systemd-modules-load.service tries to load
   the modules again and this time snd-hda-intel is present and the loading
   succeed.

This leads to the following questions:

 - why YaST2 forces the loading of snd-hda-intel on this system ?

 - do we really need to load snd-hda-intel in initrd ?

     - if not, we might want to prevent dracut from including it somehow

     - if so, yast2 should make sure that snd-hda-intel is embedded (not sure
       to understand why dracut didn't pick it up though. Even if hostonly=1
       is used it should have selected it I think)

At that point I think the YaST team should have a look.

Also Ccing Takashi as he might want to comment on that.

(In reply to Franck Bui from comment #18)
>  - why YaST2 forces the loading of snd-hda-intel on this system ?

Good question. The module used to be loaded just fine with HW autodetection, AFAIK. Perhaps there are some corner cases where autodetection doesn't work?
Anyway IMO "modules-load.d" should always be a last resort. There are plenty of other ways to enforce module load order.

>  - do we really need to load snd-hda-intel in initrd ?

I'd say definitely not, unless we're targeting text-to-speech for the dracut emergency mode.

> 
>      - if not, we might want to prevent dracut from including it somehow

We'd need a general mechanism to tell dracut which modules-load.d files to include and which to exclude. I'm not aware of such a thing.

>      - if so, yast2 should make sure that snd-hda-intel is embedded (not sure
>        to understand why dracut didn't pick it up though. Even if hostonly=1
>        is used it should have selected it I think)

@Freek, could you provide "dracut --debug" output from your system?

(In reply to Martin Wilck from comment #19)
> We'd need a general mechanism to tell dracut which modules-load.d files to
> include and which to exclude. I'm not aware of such a thing.

If "modules-load.d" should always be a last resort (which I agree with) then we could prevent dracut from importing the content of modules-load.d by default and if a module really needs to be loaded in initrd with "modules-load.d" then a .conf file could be dropped in /etc/dracut.conf.d/ to instruct dracut to import the specific conf file in "modules-load.d".

(In reply to Franck Bui from comment #20)

> If "modules-load.d" should always be a last resort (which I agree with) then
> we could prevent dracut from importing the content of modules-load.d by
> default and if a module really needs to be loaded in initrd with
> "modules-load.d" then a .conf file could be dropped in /etc/dracut.conf.d/
> to instruct dracut to import the specific conf file in "modules-load.d".

That'd need to be discussed upstream.

The entry for snd-hda-intel in /etc/modules-load.d is definitely superfluous, and it's not needed for initrd at all.

I really wonder how this yast.conf slipped in there.  I tested the standard YaST2 sound configuration now, and it doesn't save the file there but only adjust /etc/modprobe.d/...

Created attachment 795605 [details]
output of: dracut --debug > /home/freek/dracut--debug.txt 2>&1

(In reply to Takashi Iwai from comment #22)
> The entry for snd-hda-intel in /etc/modules-load.d is definitely
> superfluous, and it's not needed for initrd at all.
> 
> I really wonder how this yast.conf slipped in there.  I tested the standard
> YaST2 sound configuration now, and it doesn't save the file there but only
> adjust /etc/modprobe.d/...

You may find the answer in the attached YaST2 log file.

(In reply to Freek de Kruijf from comment #23)
> Created attachment 795605 [details]
> output of: dracut --debug > /home/freek/dracut--debug.txt 2>&1

> dfatal 'Will not override existing initramfs (/boot/initrd-4.20.2-1-default) without --force'

That didn't work. You need to run

   dracut --debug -f /boot/initrd-4.20.2-1-default.TEST 4.20.2-1-default

Sorry for having lazily omitted the default arguments.

(In reply to Martin Wilck from comment #25)
> (In reply to Freek de Kruijf from comment #23)
> > Created attachment 795605 [details]
> > output of: dracut --debug > /home/freek/dracut--debug.txt 2>&1
> 
> > dfatal 'Will not override existing initramfs (/boot/initrd-4.20.2-1-default) without --force'
> 
> That didn't work. You need to run
> 
>    dracut --debug -f /boot/initrd-4.20.2-1-default.TEST 4.20.2-1-default
> 
> Sorry for having lazily omitted the default arguments.

I used:

dracut --debug -f /boot/initrd-4.20.2-1-default.TEST 4.20.2-1-default > /home/freek/dracut--debug.txt 2>&1

File /home/freek/dracut--debug.txt will be attached.

Created attachment 795614 [details]
/home/freek/dracut--debug.txt.xz

(In reply to Freek de Kruijf from comment #27)
> Created attachment 795614 [details]
> /home/freek/dracut--debug.txt.xz

Hmm, this log pretty much looks as if snd-hda-intel had indeed been included in the initrd this time. Could you double-check (lsinitrd /boot/initrd-4.20.2-1-default.TEST | grep snd)?

(In reply to Martin Wilck from comment #28)
> (In reply to Freek de Kruijf from comment #27)
> > Created attachment 795614 [details]
> > /home/freek/dracut--debug.txt.xz
> 
> Hmm, this log pretty much looks as if snd-hda-intel had indeed been included
> in the initrd this time. Could you double-check (lsinitrd
> /boot/initrd-4.20.2-1-default.TEST | grep snd)?

# lsinitrd /boot/initrd-4.20.2-1-default.TEST | grep snd
-rw-r--r--   1 root     root        28779 Jan 24 17:17 lib/modules/4.20.2-1-default/kernel/sound/core/snd-hwdep.ko
-rw-r--r--   1 root     root        71707 Jan 24 17:17 lib/modules/4.20.2-1-default/kernel/sound/core/snd-rawmidi.ko
-rw-r--r--   1 root     root        18035 Jan 24 17:17 lib/modules/4.20.2-1-default/kernel/sound/core/snd-seq-device.ko
-rw-r--r--   1 root     root        66163 Jan 24 17:17 lib/modules/4.20.2-1-default/kernel/sound/core/snd-timer.ko
-rw-r--r--   1 root     root       182475 Jan 24 17:17 lib/modules/4.20.2-1-default/kernel/sound/hda/snd-hda-core.ko
-rw-r--r--   1 root     root       313347 Jan 24 17:17 lib/modules/4.20.2-1-default/kernel/sound/pci/hda/snd-hda-codec.ko
-rw-r--r--   1 root     root        98739 Jan 24 17:17 lib/modules/4.20.2-1-default/kernel/sound/pci/hda/snd-hda-intel.ko

Indeed it is there.

A boot with this TEST initrd still shows the unknown symbols.

jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_pcm_add_chmap_ctls (err -2)
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_sgbuf_get_chunk_size (err -2)
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_pcm_format_width (err -2)
jan 30 15:08:45 eiktum systemd-modules-load[218]: Failed to insert module 'snd_hda_intel': No such file or directory
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_pcm_add_chmap_ctls (err -2)
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_sgbuf_get_chunk_size (err -2)
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_pcm_format_width (err -2)
jan 30 15:08:45 eiktum systemd[1]: Reached target Remote File Systems.
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_pcm_add_chmap_ctls (err -2)
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_sgbuf_get_chunk_size (err -2)
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_pcm_format_width (err -2)
jan 30 15:08:45 eiktum systemd[1]: Starting Show Plymouth Boot Screen...
jan 30 15:08:45 eiktum systemd[1]: Received SIGRTMIN+20 from PID 333 (plymouthd).
jan 30 15:08:45 eiktum kernel: ACPI: bus type USB registered
jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol snd_pcm_add_chmap_ctls (err -2)

Please run 'save_y2logs' and attach the complete log archive.

(In reply to Freek de Kruijf from comment #30)
> A boot with this TEST initrd still shows the unknown symbols.
> 
> jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol
> snd_pcm_add_chmap_ctls (err -2)
> jan 30 15:08:45 eiktum kernel: snd_hda_core: Unknown symbol
> snd_sgbuf_get_chunk_size (err -2)

These symbols are from snd_pcm. It seems that something goes wrong with the module dependency resolution for snd_hda_intel in dracut.

I don't think this deserves further debugging on the dracut. It's not helpful to force sound modules into the initrd.

Created attachment 795697 [details]
output of save_y2logs

'yast2 sound' takes the liberty to add it:

> 2018-04-20 11:59:22 <1> eiktum(10173) [Ruby] modules/Kernel.rb:483 Adding module to be loaded at boot: snd-hda-intel

While I would question the usefulness of this I also think that dracut should
continue to produce workable initrds if the user *does* do it and we shouldn't start arguing about bad and good modules here.

AFAIK yast's sound module hasn't seen functional changes for years so the
module thing must have worked so far.

modules-load.d(5) doesn't forbid sound modules so I think it should work (even if it's not very elegant).

Well, can we find out the culprit why snd-hda-intel gets added there at first?

dracut should be fixed to deal with that module, yes, but the primary bug is that YaST put the module entry wrongly by some reason.  This must be fixed above all.

(IOW, *luckily* dracut was buggy so that the issue surfaced :)

BTW, we have another bug report for the same issue wrt dracut and snd-hda-intel in bug 1120747, so the dracut issue can be tracked there.
In this bug, let's concentrate on YaST side.

It's what yast's sound module always did, I guess. See e.g. bug 838185 for the systemd related migration.

Maybe sometimes it is necessary to add module options to sound modules? I've no idea. What do you think, is yast's sound module needed at all or could we even drop it?

I just run 'yast sound' (for the first time ever...) and it looks basically like a frontend for alsa sound module options.

If the expectation is that it should *not* mess with modules the whole exercise seems pretty pointless to me.

As there's not even an explanation of the individual module options presented, I don't see any real value. Again, I'd vote for dropping this yast modules.

I myself don't mind at all to drop yast2-sound, but some people may miss it :)
Originally it was for setting up the sound devices in a non-PnP manner, but it's already legacy.  The only purpose nowadays would be to set up the options via GUI.

But my question still remains -- why snd-hda-intel was added there.
In include/sound/write_routines.rb, it checks the bus and it adds the entry only if it's neither PCI nor USB.

        # load the module automatically on boot
        if entry["bus"] != "pci" && entry["bus"] != "usb" && !module_name.empty?
          Builtins.y2milestone("The soundcard is not attached to PCI or USB")
          Kernel.AddModuleToLoad(module_name)
          ret = Kernel.SaveModulesToLoad
        end

And snd-hda-intel is a PCI driver, so it shouldn't have been added, if I understand the code correctly...

The problem seems to be this:

> Save card: $["alias":"snd-card-0", "model":"RV770 HDMI Audio [Radeo
n HD 4850/4870]", "module":"snd-hda-intel", "options":$["index":"0"], "unique_key":"5yAR.dhjYDcGDBr3"]

This looks a bit mixed up. Not sure from where it originates; maybe some left-over from an update or hardware change in the past?

(In reply to Steffen Winterfeldt from comment #42)
> The problem seems to be this:
> 
> > Save card: $["alias":"snd-card-0", "model":"RV770 HDMI Audio [Radeo
> n HD 4850/4870]", "module":"snd-hda-intel", "options":$["index":"0"],
> "unique_key":"5yAR.dhjYDcGDBr3"]
> 
> This looks a bit mixed up. Not sure from where it originates; maybe some
> left-over from an update or hardware change in the past?

I have this system from 2010 using the intel sound system on the motherboard. A few years ago my monitor died, so I got a new monitor which was first driven by the VGA interface (full-HD) and used the intel sound system. My display card died and I got a more simple display card, which was first used with the VGA interface. Later I changed things to use the HDMI interface also for the sound. Tumbleweed was used from the very start of it. I needed to experiment/configure quite a lot to get sound running via HDMI. Still I want to listen to the sound via a headset, but did not get it working; only possible via the intel card. I use YaST and systemsettings to configure the sound system.

Hope this answers your question.

Thanks!

Tracking in YaST Scrum board.

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

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

No further response. Will start a new issue when problem surfaces again.