w6nij@Node622144:~$ lsmod | grep dahdi
w6nij@Node622144:~$ grep pseudo /var/lib/asterisk/messages
grep: /var/lib/asterisk/messages: No such file or directory
w6nij@Node622144:~$
So your audio module is fine, it’s DAHDI that’s missing. Please run the following and paste the output:
uname -a
dpkg -l | grep linux-headers
Then, to get things working again:
apt install --reinstall linux-headers-$(uname -r)
apt install --reinstall dahdi-dkms
modprobe dahdi
modprobe dahdi_dummy
modprobe dahdi_transcode
systemctl restart asterisk
My impression is that the published temporary fix & hold does not take care of these 6-steps.
And it just leaves you hanging with a non-working system as detailed above.
I am trying this myself on a clean install right now.
We may need to add these steps to the announcement/fix.
Or is it possible to add these steps to the fix and keep it a one-liner?
Just thinking out loud at the moment.
I’ll go ahead and try it out per the announcement and see if it breaks.
FYI- A fresh Debian install (using the currently published install image) - installs the -30 kernel and no (easy grub menu) options to roll back to a previous kernel.
Also as we already know per the official ASL3 install instructions:
It’s important to note that the new packaging format will allow for easy, automated updates of kernels through the standard
apt upgrade
process. There is no longer any reason to hold back kernel upgrades with the ASL3 packaging.
We are presently up against a problem where this does not hold true.
On my fresh newly installed system (mentioned above).
I tried the script:
wget -O- https://repo.allstarlink.org/hotfix/asl3-deb12-kernel28-fix.sh | sudo bash -x
Seems to look like it runs fine, builds everything it needs no errors.
Reboot and then have a nonworking system dahdi / simpleusb not working.
Just like W6NIJ reported.
And appears it needs the other steps to be done.
Will try that next.
apt install --reinstall linux-headers-$(uname -r)
apt install --reinstall dahdi-dkms
modprobe dahdi
modprobe dahdi_dummy
modprobe dahdi_transcode
systemctl restart asterisk
Doing those additional 6 steps fixes it.
And works after rebooting as well.
And have a good working system on the -28 kernel.
Just did all of this on our production node, it’s back up & running without the audio problems.
A friend has the problem on an Rpi, a 3B I think. So apparently it’s a problem there, too. Will the wget hot fix work on a Pi?
This does not impact Pis. That’s some other problem.
We are presently up against a bug introduced by the Debian kernel. That’s a rare occurrence for something like that.
So, to be clear, you were testing this on a system that was freshly installed and NEVER had a working setup on the 6.1.0-28 kernel? If so, I’ll have to add additional steps to the directions.
This is correct. Brand new system installed today with -30.
I also (suspect) the same thing happens even if the system previously had -28 (or something older than -28) on it previously but I currently do not have an easy way that I know of how how check or know know what was on them before they were updated.
I did have to do the same thing on my remote system that was working before the update that I did this on today that is not a newly installed system-
-which was running -on -30 before applying today’s fix putting it on -28 today.
It was working about 4 days ago before upgrading.
So I have tested this on both types of systems if that makes any sense.
One that was brand new and up to date, and another that has been previously working days ago before apt upgrade.
I had to apply on both:
To get it working:
apt install --reinstall linux-headers-$(uname -r)
apt install --reinstall dahdi-dkms
modprobe dahdi
modprobe dahdi_dummy
modprobe dahdi_transcode
systemctl restart asterisk
Just to confirm, after you exec’d the wget ... | sudo bash ...
command and the packages were all installed did you reboot before checking the audio?
And did the dahdi-dkms build process report any errors?
Yes and Yes.
Saw no errors during the build process can’t say 100% certain there were none but I watched carefully as it did everything it does.
Errors usually really stand out.
I could start all over again clean - will take a little while but I have no problem doing this.
And I could pipe it’s output to a file so you can see the entire thing run and what it does.
I found a couple of corner-case issues with the hotfix that I think will address the problems @n8lbv and maybe @w6nij were having with the hotfix. If you want to try running the hotfix again on a broken system or a clean build and test, that would be helpful.
Thought I was going insane. Replaced all my interfaces and scratching my head. Reloaded the PC even. Built on a pi4 and everything was fine. Thought my PC USB went bad.
Applied the fix per the pinned message and all is good now.
I am using USBRadio in my setup.
I"m going mildly insane trying to figure out a sane, maintainable way out of this kernel bug.
I’ll start over on a clean build – no problem with that here.
Also I will capture when the script runs in case there is anything useful there.