Some days ago I upgraded a EZKINIL chromebook device (Acer Chromebook Spin 514 CP514-1H) to Fedora Silverblue 42. It was working flawlessly since Fedora 40 before.
However, with the first update of Fedora 42, the sound card refused to work.
Here you see the 42.1.1 installation image freshly installedâŠ
Next you see the same inforamtion with the latest updates applied on May 29th. Please notice there is only a dummy audio output device and no input device available with this kernel version.
Here is the output, the Gnome Logs app collected for me.
11:20:22 systemd: Failed to start grub-boot-success.service - Mark boot as successful.
11:18:19 gdm-session-wor: gkr-pam: unable to locate daemon control file
11:18:11 systemd-logind: Failed to open '/boot//loader/entries': Remote address changed
11:18:06 kernel: acp3x-alc5682-max98357 AMDI5682:00: ASoC: driver name too long 'acp3xalc5682m98357' -> 'acp3xalc5682m98'
11:18:05 systemd-tmpfile: "/root" already exists and is not a directory.
11:18:03 kernel: /usr/bin/mount for / exited with exit status 32.
11:18:03 kernel: Failed to start systemd-remount-fs.service - Remount Root and Kernel File Systems.
The kernel message at 11:18:06 looks suspicious to me. Any ideas how to fix that issue?
The main problem is that I can return to the pinned 42.1.1 snapshot. However, power management does not seem to work very well there. Audio works there, but the fan is noisy and I canât control the screen brightness.
For the 42.20250528.0 snapshot, I only get the dummy audio device, but power management works as it should.
This is quite frustrating since Fedora Silverblue worked pretty awesome before.
You can use Updates, Upgrades & Rollbacks :: Fedora Docs to try rolling back to another version between the latest and the installation one. That should help you pinpoint which version introduced the issue and then which package changed with rpm-ostree db diff.
Currently Iâm on this machine and meanwhile I tried a fresh install, so there are no other snapshots between the 42.1.1 installation image with working sound and clumsy power management and a few fresher snapshot swith well working power management in each snapshot - but with a dummy device as audio output.
Rolling back to another state wonât help with my problem. As soon as the computer updates alsa or the kernel, audio will break again.
Here are my logs from Gnome Logs:
20:11:49 gdm-session-wor: gkr-pam: unable to locate daemon control file
20:11:36 systemd-logind: Failed to open '/boot//loader/entries': Remote address changed
20:11:28 kernel: acp3x-alc5682-max98357 AMDI5682:00: ASoC: driver name too long 'acp3xalc5682m98357' -> 'acp3xalc5682m98'
20:11:28 systemd-logind: Failed to open '/boot//loader/entries': Remote address changed
20:11:27 systemd-tmpfile: "/root" already exists and is not a directory.
20:11:25 kernel: /usr/bin/mount for / exited with exit status 32.
20:11:25 kernel: Failed to start systemd-remount-fs.service - Remount Root and Kernel File Systems.
Take a look at this line:
20:11:28 kernel: acp3x-alc5682-max98357 AMDI5682:00: ASoC: driver name too long âacp3xalc5682m98357â â âacp3xalc5682m98â
This error message does not appear when I start the 42.1.1 installation snapshot with working audio.
It apperars in every other snapshot after (which update alsa and the kernel, compared to the installation image, btw..) and did never appear in Fedora 40 and 41.
Fun fact: Bluetooth Audio works. So the computer owner currently uses a bluetooth box for audio output. I still donât think that this should be the fix for that problem.
I donât understand. There are versions between those, maybe not installed on your system but on the server. If you follow the guide above you should be able to install them and find the exact version that broke things.
The system plays audio over Bluetooth just fine, but the internal audio device isnât detected â it only shows âDummy Outputâ. Based on this, letâs go through a few essential checks.
lspci -nnk | grep -A3 Audio
â Check what kernel drivers and modules are loaded
pactl list short sinks
â is device identified by PulseAudio/PipeWire?
ls /usr/share/alsa/ucm2/
â Is it a UCM profile issue? Check the UCM directory.
Some ASoC-based devices (like the ALC5682) may show only âDummy Outputâ if the User Control Model (UCM) definitions are incomplete or missing.
These three checks will help determine whether the issue is at the device level, session level, or due to a driver loading failure.
If needed, feel free to share the output of the above commands â I can then help guide the next steps more specifically.
Thanks for sharing the command output. It seems like the issue might be related to the SOF audio driver. Your system appears to be loading the snd_pci_acp3x driver, but no actual audio sink is available (auto_null is the only one listed), which suggests a possible disconnect between the driver and user space (PipeWire or PulseAudio).
One workaround might be to try forcing the legacy HDA driver instead of SOF, by adding a kernel boot parameter via GRUB.
However, since this involves editing GRUB and kernel parameters, it might require some assistance from more experienced contributors to ensure itâs done safely and effectively.
Iâm sorry I couldnât help further at this stage, but I hope this at least points in the right direction. Letâs hope someone with more kernel-level experience can jump in!
I currently have the machine with me. Editing the kernel line should not be the problem for me.
However, after that weekend my girlfriend will get her computer back for studying. And she will apply the updates gnome-software presents to her. Because thatâs how users where conditioned all the years.
How can I additionally make sure that future updates will not break the audio output again?
Fedora updates occur about once or twice a week, and most users donât thoroughly review which componentsâsuch as audio stacks or driversâare being updated before applying them. Due to the fast-moving nature of Fedoraâs update cycle, itâs great for experiencing upstream changes quickly, but this also increases the likelihood of regressions or system breakage.
For the systems I manage, I follow these precautions to mitigate risk:
Snapshot before risky updates: If a weekly update includes known sensitive componentsâlike the kernel or audio stackâthat have previously caused issues, I create a snapshot before applying the update.
Track configuration changes with etckeeper: Before applying any configuration changes, I use etckeeper to track modifications in /etc.
Pre-Update testing: I run a quick validation before applying updates. (e.g., test boot with a live image or a clone of the current system, especially when kernel/audio-related updates are included.)
These steps help me balance Fedoraâs fast updates with the need for a stable audio and system environment.
Honestly, the frequent updates can be quite overwhelming. Thatâs why I use an LTS-based distro for my main desktop, where stability matters most. Fedora is great for testing and catching upstream changes early, but for day-to-day reliabilityâespecially with kernel or audio stack regressionsâI prefer something with a slower update cycle.
you donât need to edit anything in grub.
use grubby to add or remove kernel args
or better try first by adding them in the grub2 boot menu ( grub2 boot menu, highlight kernel you want to boot, press âeâ , add kernel parameter at the end of the linux line , CTRL x to boot
sudo grubby --args='new args' --update-kernel=0
0 update only kernel at index 0
ALL update all kernels
sudo grubby --remove-args='arg' --update-kernel=0 / ALL
sudo grubby --info=ALL shows current settings for all kernels
EDIT: ah, Silverblue, no idea if this works with Silverblue, probably not.
Linux updates often break things, and not just audio. Fedora moves faster so is often the first to encounter issues. I have USB audio and WiFi dongles (chosen to use in-kernel drivers) for use when an update breaks one of those. Other issues may require booting an older kernel or snapshot.
Linux always carries a risk of breakage with future updates, so a) waiting a few days before applying updates to allow time for issues to be noticed and b) routine use of snapshots before updates will minimize the impact of inevitable cases of updates that break things.
Having an easy way to revert to a working configuration is the best ways to mitigate breakage due to a buggy update, but you should also think about backups and and recovery from hardware failures that prevent a system from booting and/or destroy user data.
Any chance to upgrade to the 6.14.9 kernel? This has a LOT of fixes compared to 6.14.8. Latest and final for 6.14 is 6.14.11 in updates-testing repository.
otherwise compare outputs of journalctl --no-hostname -b0 -g 'snd_|ucm|hda' from liveiso and 6.14.8 for clues.
can you overlay this and test if it restores audio?
All you need is to overlay alsa-ucm-1.2.14-3.fc42.noarch.rpm
the other rpms should be identical to 1.2.14-2.fc42
You should def. open a regression bug report on bugzilla.redhat.com for Fedora / alsa-lib with your findings.
I will give it another shot later this week. I have limited access to that machine, so I canât play around with it that often. Since this problem seems to be distribution independent, I guess a USB pen with Fedora Workstation installed will do the trick for testing purposes?
So I can prepare a bootstick and check it without modifying the current system.
On sunday I played arround with some other immutable distributions and all have the same issue after updating alsa.
yes, this should work as well.
Fedora live iso has installed alsa 1.2.13 and the alsa project has changed the file and directory naming scheme in 1.2.14. Unfortunately they missed to update some configurations accordingly.
Maybe you can test this in a workstation live environment.
Anyway, all you need to do is update alsa to 1.2.14 and check that the internal speakers are not emitting sound.
