Dev1 Galaxy Forum / Alsa errors during boot of Excalibur

Re: Alsa errors during boot of Excalibur

dummy@example.com (greenjeans) — Thu, 20 Nov 2025 17:52:24 +0000

Thank you @fsmithred!!

I'm so sorry y'all are having to deal with stuff like this right now. Seems like there's quite a few of these upstream shenanigans going on with this release of debian.

Re: Alsa errors during boot of Excalibur

dummy@example.com (fsmithred) — Thu, 20 Nov 2025 13:40:12 +0000

Here's the fixed version of /usr/lib/udev/rules.d/90-alsa-restore.rules that you get in a netinstall of excalibur. The edit is hacked into the installer isos, so you won't get this fix on an upgrade from daedalus. And it might get clobbered if there's an upgrade to alsa.

The desktop-live iso got the upstream version, which has a few other changes. I hope that doesn't cause problems. That file is in /etc/udev/rules.d so if it does cause trouble, it can be removed without breaking anything.

This replaces /usr/lib/udev/rules.d/90-alsa-restore.rules
or better, put it in /etc/udev/rules.d/90-alsa-restore-rules

# do not edit this file, it will be overwritten on update

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"

ENV{ALSA_CARD_NUMBER}="$attr{device/number}"

# mark HDA analog card; HDMI/DP card does not have capture devices
DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"

# check for ACP hardware
TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp6x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp63-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp-dmic-codec", GOTO="alsa_hda_analog"
GOTO="alsa_restore_std"

LABEL="alsa_hda_analog"
# restore configuration for profile with combined cards (HDA + digital mic)
TEST!="/run/udev/alsa-hda-analog-card", GOTO="alsa_restore_std"
IMPORT{program}="/usr/bin/cat /run/udev/alsa-hda-analog-card"
ENV{ALSA_CARD_HDA_ANALOG}!="", ENV{ALSA_CARD_NUMBER}="$env{ALSA_CARD_HDA_ANALOG}"

LABEL="alsa_restore_std"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $env{ALSA_CARD_NUMBER}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $env{ALSA_CARD_NUMBER}"

LABEL="alsa_restore_end"

Re: Alsa errors during boot of Excalibur

dummy@example.com (greenjeans) — Tue, 14 Oct 2025 19:47:15 +0000

Well nature always sides with the hidden flaw, lol, yeah looks like they fixed that 3 weeks ago.

But downstream must still be wrong, and it's not that part.

Re: Alsa errors during boot of Excalibur

dummy@example.com (fsmithred) — Tue, 14 Oct 2025 01:29:07 +0000

@greenjeans
I replaced 90-alsa-restore.rules with what you posted above. Got error in dmesg:

[ 9.332608] udevd[753]: invalid key/value pair in file /usr/lib/udev/rules.d/90-alsa-restore.rules on line 3, starting at character 73 (',')

I checked upstream and there's one character difference between what's posted above (---) and what's on github (+++).
https://github.com/alsa-project/alsa-ut … e.rules.in

--- 90-alsa-restore.rules	2025-10-13 23:59:29.972000000 +0000
+++ 90-alsa-restore.rules.upstream	2025-10-14 01:12:30.304000000 +0000
@@ -8,7 +8,7 @@
 ENV{ALSA_CARD_NUMBER}="$attr{device/number}"
 
 # mark HDA analog card; HDMI/DP card does not have capture devices
-DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"
+DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0c", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"
 
 # check for ACP hardware
 TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"

Re: Alsa errors during boot of Excalibur

dummy@example.com (sjox) — Wed, 17 Sep 2025 16:54:39 +0000

Ah! ntpsec is the package with the daemon!
(I overlooked that...)
Yes, it currently only runs once a day
If you are not an accuracy freak, then it is enough!
(On server, of course, not.)
Thanks

Re: Alsa errors during boot of Excalibur

dummy@example.com (fsmithred) — Tue, 16 Sep 2025 22:37:12 +0000

b) IDTYPE="RANDOM"

Feature.

e) ntpsec-ntpdate

I'm not sure if that one runs when you reboot. I have a script to run it when I think my time has drifted. Fuzzy, I know.

For full synchronization, use the ntp package.

Re: Alsa errors during boot of Excalibur

dummy@example.com (sjox) — Tue, 16 Sep 2025 18:09:19 +0000

Hi,

Yes, the problem with "/usr/lib/udev/rules.d/90-alsa-restore.rules" is actually available in all Debian-derived distributions and has been around for a relatively long time! (PCLinuxOS and Artix solved this problem!)
However, these "alsa-utils" are important because you can set "Autodetect" via the Alsamixer.
(Speaker/headphones then switch automatically – but only after a reboot!)
At the end of the rules file, I simply entered the line LABEL-"alsa-restore-std".
Of course, this is not a solution, but it eliminates this annoying message!

I have been experimenting with Excalibur for over a month and am actually very satisfied.
However, there are other peculiarities - also in the RC1 (XFCE4):

a)
First, I had to run the command "xdg-user-dirs-update --force".
Only then were the catalogues created in German.
(user-dirs.dirs and user-dirs.locale)
Under Cinnamon this problem does not exist!

(b)
Then I had to comment out in the file "/etc/default/dbus" the entry "IDTYPE"RANDOM" with a "#".
Thank you for the solution - I found it here in the forum!
Is this a bug or a feature?

c)
Why was mate-polkit installed? There is xfce-polkit!
There are error messages in my ".xsession-errors"!
There are no entries when using xfce-polkit.

d)
Rsyslog has been solved!

e)
There doesn't seem to be an automatic time synchronization with "ntpsec-ntpdate"?
I had to make do with an entry in the “cron.daily”.

f)
Fstrim for SSD maintenance must be activated manually!
(I prefer to me too!)

g)
The computer could not go into broad-based mode!
Remedy: sudo /bin/bash -c "echo GPP0 > /proc/acpi/wakeup"
You have to enter extra in /etc/rc.local. (without sudo)

(h)
A problem with the "speech-dispatcher" in combination with Pulseaudio!
The sound output is strongly distorted - also in Firefox.
(Youtube ist ok - but on X/Twitter the speech-dispatcher is always activated)
Remedy a change in the /etc/speech-dispatcher/speechd.conf file
'AudioOutputMethod "alsa"' helped.
(with pipewire there are no problems)

These were actually only annoying little(?) things that can be solved.

But there is something very important:
I noticed that under XFCE (and only under XFCE) the screen often freezes for several seconds! With me it happened approx. 2-3 times a week!
This problem can also be found in various forums, and is also extensively discussed when looking for "ring gfx_0.0.0 timeout, but soft recovered".

It should be a problem with the AMD graphics driver and you can fix it simply by disabling the composite effects of XFCE4!
(These are now disabled by default in the Devuan RC1)
But I would like to have a composite manager, because, for example, the Firefox edition when leafing back and forth without it jerking! The use of Picom provided a remedy.
(Compiz caused me screen errors).
If you select "egl" as a Picom backend, then the composite manager runs absolutely stable with my AMD card and you are permanently spared from freezing!
I just used the included sample configuration.
The one copied from "/usr/share/doc/picom/examples/picom.sample.conf" to "/.config/picom.conf"! It is complex but well documented and changes are effective immediately - so you have a quick feedback when testing.

Unfortunately, another problem will arise:
Huge number of error messages in the ".xsession-errors" - although you don't notice anything!
This problem is also known: https://bbs.archlinux.org/viewtopic.php?id=306908
If I understand that correctly, XFWM is buggy under 4.20 and therefore there is an improved version on Git: https://gitlab.xfce.org/xfce/xfwm4.
I was able to compile and even install a new xfwm window manager after a few attempts!
First, the necessary DEV packages must be provided:
sudo apt install libwnck-3-dev libxfce4ui-2-dev libgtkd-3-dev libglib2.0-dev pkg-config cmake meson (I hope I haven't forgotten anything)
There is also a good tutorial - I changed it for myself: "meson setup --prefix=/usr build" (Then overwrite the freshly compiled files the old ones.)
In fact, it worked! It runs stable and without error messages in the ".xsession-errors"!

Well, however, this is quite a deep intervention and this should not be necessary!
Now my question:
Is there any chance that this improved Xfwm version will find its way into the Devuan package sources?

Thanks

Re: Alsa errors during boot of Excalibur

dummy@example.com (greenjeans) — Mon, 08 Sep 2025 17:48:48 +0000

/usr/lib/udev/rules.d/90-alsa-restore.rules

Here's the version in alsa-utils from their git:

# do not edit this file, it will be overwritten on update

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*",@extratest@ GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"

ENV{ALSA_CARD_NUMBER}="$attr{device/number}"

# mark HDA analog card; HDMI/DP card does not have capture devices
DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"

# check for ACP hardware
TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp6x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp63-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp-dmic-codec", GOTO="alsa_hda_analog"
GOTO="alsa_restore_std"

LABEL="alsa_hda_analog"
# restore configuration for profile with combined cards (HDA + digital mic)
TEST!="/run/udev/alsa-hda-analog-card", GOTO="alsa_restore_std"
IMPORT{program}="/usr/bin/cat /run/udev/alsa-hda-analog-card"
ENV{ALSA_CARD_HDA_ANALOG}!="", ENV{ALSA_CARD_NUMBER}="$env{ALSA_CARD_HDA_ANALOG}"

LABEL="alsa_restore_std"
TEST!="@daemonswitch@", RUN+="@sbindir@/alsactl@args@ restore $env{ALSA_CARD_NUMBER}"
TEST=="@daemonswitch@", RUN+="@sbindir@/alsactl@args@ nrestore $env{ALSA_CARD_NUMBER}"

LABEL="alsa_restore_end"

And here's the current version in excalibur/trixie:

# do not edit this file, it will be overwritten on update

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"

ENV{ALSA_CARD_NUMBER}="$attr{device/number}"

# mark HDA analog card; HDMI/DP card does not have capture devices
DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"

# check for ACP hardware
TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp6x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp63-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp-dmic-codec", GOTO="alsa_hda_analog"
GOTO="alsa_restore_std"

LABEL="alsa_hda_analog"
# restore configuration for profile with combined cards (HDA + digital mic)
TEST!="/run/udev/alsa-hda-analog-card", GOTO="alsa_restore_std"
IMPORT{program}="/usr/bin/cat /run/udev/alsa-hda-analog-card"
ENV{ALSA_CARD_HDA_ANALOG}!="", ENV{ALSA_CARD_NUMBER}="$env{ALSA_CARD_HDA_ANALOG}"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $env{ALSA_CARD_NUMBER}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $env{ALSA_CARD_NUMBER}"

LABEL="alsa_restore_end"

Re: Alsa errors during boot of Excalibur

dummy@example.com (greenjeans) — Mon, 08 Sep 2025 16:34:37 +0000

Okay, more info. The bug is in alsa-utils, in the 90-alsa-restore.rules file. Looks like alsa fixed it months ago, but then a patch from Debian broke it again so now I guess it's their bug, and it's still an issue in Trixie as of 2 days ago.

https://bugs-devel.debian.org/cgi-bin/b … ug=1093057

The patch is also supposed to be a fix for some mics not working from what i've read.

Re: Alsa errors during boot of Excalibur

dummy@example.com (greenjeans) — Sun, 07 Sep 2025 16:36:34 +0000

Known issue, supposedly fixed, some links:

https://github.com/alsa-project/alsa-ut … e.rules.in

https://github.com/alsa-project/alsa-utils/issues/280

https://github.com/alsa-project/alsa-ut … 17e53b41a8

An even easier workaround (have not tested myself): https://andrzej.langow.ski/2025/05/14/s … -ignoring/

I guess the fix never made it into trixie?

The file is somewhere.

I think it's just the LABEL + definition missing, not an actual file? Possibly:

LABEL="alsa_restore_std"
TEST!="@daemonswitch@", RUN+="@sbindir@/alsactl@args@ restore $env{ALSA_CARD_NUMBER}"
TEST=="@daemonswitch@", RUN+="@sbindir@/alsactl@args@ nrestore $env{ALSA_CARD_NUMBER}"

And from Ubuntu bugs:

I read the Debian bug which reports that although this was fixed in 1.2.14, there are Debian/Ubuntu patches that were not correctly updated which means the bug is still present in the latest packaging so I'm reopening this issue.

I don't have excalibur booted up right now, will boot up a live-session later and do some more testing.

Re: Alsa errors during boot of Excalibur

dummy@example.com (ralph.ronnquist) — Sat, 06 Sep 2025 23:09:15 +0000

Did you try

find /usr /var /etc -name '*90?alsa?restore?std*'

The file is somewhere.

You should also check

dpkg -S 90-alsa_restore_std

to see where it comes from.

Alsa errors during boot of Excalibur

dummy@example.com (greenjeans) — Sat, 06 Sep 2025 19:11:32 +0000

Thought 'd make a separate thread for this, in a nutshell on excalibur I am still getting the alsa errors on boot-up for months now.

"GOTO alsa_restore_std has no matching label in /usr/lib/udev/rules.d/90-alsa_restore_std",

and indeed there is no alsa_restore_std in that folder, maybe there should be one or the alsa rules file in there needs to be edited?

My temp workaround is to make a file in /etc/udev/rules.d/ , 90-alsa-restore-rules, that overrides the existing rules file:

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $attr{device/number}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $attr{device/number}"

LABEL="alsa_restore_end"