[App_rpt-users] Problems with setup from newest image

[Jeremy Utley]

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 at repeater:~# uname -a
Linux repeater 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 armv7l GNU/Linux
root at repeater:~# lsmod | grep "^snd_pcm_oss"
snd_pcm_oss            39923  0
root at 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 at 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 at repeater:~# lsmod | grep "^dahdi"
root at 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 at repeater:~# lsmod | grep "^snd_pcm_oss"
root at 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 at 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 at 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 at gmail.com>
> Sent: Wednesday, April 11, 2018 4:43 PM
> To: 'Users of Asterisk app_rpt' <app_rpt-users at 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