OK, so with the advice of someone who emailed me off list, I'm trying out some things. A power problem on the Pi I'm using for the rebuild was suspected, so I've switched my Pi-3 over to my Anker 10-port USB charger - capable of 60W output, 2.4 amps per port - This should be plenty to drive the Pi. I re-imaged the SD card from the same image I had downloaded (ASL_1.01-20180228-armhf-raspbian-stretch-image.img), and booted my Pi-3 with it. Logged in over SSH, changed the password, and did an apt update && apt -y upgrade to bring everything to the newest packages. While running the stock image, I got the following output: root@repeater:~# uname -a Linux repeater 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 armv7l GNU/Linux root@repeater:~# lsmod | grep "^snd_pcm_oss" snd_pcm_oss 39923 0 root@repeater:~# lsmod | grep "^dahdi" dahdi 229561 26 So with the stock image, kernel 4.9.80-v7+ is running, and both the dahdi and snd_pcm_oss modules are loaded. Rebooting after the apt upgrade, during the bootup, I get an error about failing to load kernel modules. SSH into the system, I end up with a host key mismatch - so between the first and second bootups, the SSH host keys are getting regenerated - this should happen during the first bootup of the image, not the second :) Delete the old host keys from my system, and run those same commands again: root@repeater:~# uname -a Linux repeater 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l GNU/Linux We are now running the new kernel for Raspbian. root@repeater:~# lsmod | grep "^dahdi" root@repeater:~# No loaded dahdi kernel module, so DKMS is not doing it's jub to rebuild the kernel module against the newer kernel. Not sure why that is. root@repeater:~# lsmod | grep "^snd_pcm_oss" root@repeater:~# Also no snd_pcm_oss module being loaded. I did a "modprobe configs" to get the config of the current kernel into /proc/config.gz, and did: root@repeater:/boot# zcat /proc/config.gz | grep -i "OSS" And it looks like the Raspbian kernel is now disabling the OSS sound modules entirely: # CONFIG_SOUND_OSS_CORE is not set # CONFIG_SND_OSSEMUL is not set So, from what I can see, we have 2 issues here. 1) DKMS is not rebuilding the dahdi module when the kernel is upgraded to a new version. This can be easily fixed with a "dkms install" command, but shouldn't the system be doing that automatically? 2) It seems the newest Raspbian kernel has disabled the legacy OSS support modules, which means /dev/dsp is not being created - and I believe that is what was causing the message "Unable to re-open DSP device 1" to constantly spew into my Asterisk logs earlier today. Unfortunately, I don't see a way, short of providing a custom kernel and maintaining that custom kernel, for this particular problem to be solved, and from my understanding, this means that with the newer Raspbian kernels, AllStar will not work - even if the Dahdi problems are solved. I don't know if this is the case on x86 - I haven't tested that out - and I really don't want to put a full blown X86 box into our repeater shed. I'm not sure exactly where to go from here, other than disable kernel updates, which IMHO isn't a smart thing to do. Maybe I need to work with the older RAT_RC1 image - it seemed to work great back when I had it on my simplex node. Anybody got any ideas? Jeremy, NQ0M On Wed, Apr 11, 2018 at 5:29 PM, Jeremy Utley <jerutley@gmail.com> wrote:

Ok, so rebuilding the Dahdi drivers worked – but the process as shown in the wiki did not work, nor did the –reinstall command – it looks like DKMS is by default building things with -j 4, and that’s too much for a Pi – my SSH connection was getting killed during the Dahdi recompile. So I had to manually do it with this command:

dkms build -m asl-dahdi-linux -v 2.11.1 -j 1

dkms install -m asl-dahdi-linux -v 2.11.1 -j 1 –force

Once I’d done that, I could load up the dahdi kernel module, and asterisk would start up. It appears I am connected to the network with the new node – however I’m having the following message spew into /var/log/asterisk/messages multiple times a second:

[Apr 11 17:21:22] WARNING[1387] chan_simpleusb.c: Unable to re-open DSP device 1 (usb_45984): No such file or directory

Anyone got any ideas?

Jeremy, NQ0M

From: Jeremy Utley <jerutley@gmail.com> Sent: Wednesday, April 11, 2018 4:43 PM To: 'Users of Asterisk app_rpt' <app_rpt-users@lists.allstarlink.org> Subject: Problems with setup from newest image

So last week while I was on vacation, I had an SD card filesystem go corrupt – lots of damaged files, Asterisk segfaulting on startup, all kinds of weird stuff happening. So I decided to rebuild this node (45984) with the newest stuff – this was my last Arch-based node, and I wanted to get back to the Debian base. So, I pulled down the 20180228 raspbian stretch image, wrote it to a new SD card, booted up the Pi, ssh’d in, expanded the filesystem, updated all packages to latest, and went thru the setup process. BTW, I love the new menu-based system – but the menu should include a way to get out to shell (if it does already, I apologize, but I did not see an option for that in it).

After I did the node setup, and the pi rebooted, I’m getting odd errors from trying to start Asterisk. Here’s an entry from journalctl:

Apr 11 16:14:33 uhf.wi0la.org systemd[1]: asterisk.service: Job asterisk.service/start failed with result 'dependency'.

Apr 11 16:14:33 uhf.wi0la.org systemd[1]: dev-dahdi-pseudo.device: Job dev-dahdi-pseudo.device/start failed with result 'timeout'.

I’m suspecting that the upgrade of the kernel I did on the first boot is making Dahdi not come up properly, so I’m trying a rebuild of Dahdi via:

apt-get install --reinstall asl-dahdi-linux-dkms

Don’t know if this will fix the problem or not – will know as soon as the process finishes. But isn’t DKMS supposed to handle this automatically?

Jeremy, NQ0M