CLI gibberish -- prompt and input appear to be some sort of unicode characters

I’m using Linux alarm 3.14.65-16-ARCH on arm. i’m kinda glad to know it isn’t due to the arm environment… :wink:
You say it happened after a kernel update? Did you have to rebuild asterisk or just did it happen just after rebooting?
I tried to play with the locale/language/input environment parameters but same results…
I’m pretty sure i had it working correctly last month, I’ll try to find an old image.

Vincent

Probably not a kernel update, that’s something that is different between the two of us, but probably the update of some other component. It literally happened one day when CLI had been running for a while. I went to bed and it was fine. I woke up in the morning and it was not fine. Unfortunately, by the time I’d thought about it enough to conclude that it was some component that had been upgraded, it was too late for me to figure out which component (assuming I’m even right, which I could easily not be).

Stephen

Well i got an old image (± 1 month old), rebuild asterisk 13 lts, and the cli is just fine. I’ll try to make small updates and see which one breaks it…

Well if the bug comes from a single package, it’s one of these… I ran an update on a batch, didn’t really expect any of them to be the culprit (except systemd maybe…) But after i ran the update, without even rebooting or restarting asterisk, the bug appears…

Packages (17) libarchive-3.2.1-2 libassuan-2.4.3-1 libedit-20160618_3.1-1 libffi-3.2.1-2 libgcrypt-1.7.2-1 libgpg-error-1.24-1
libmnl-1.0.4-1 libsasl-2.1.26-8 libsystemd-230-7 nano-2.6.1-1 netctl-1.12-2 pam-1.3.0-1 procps-ng-3.3.12-1
s-nail-14.8.9-1 systemd-230-7 systemd-sysvcompat-230-7 tzdata-2016f-1

I would hazard a guess that it’s libedit.

In the CHANGES file for Asterisk:

  • Asterisk can now use a system-provided NetBSD editline library (libedit) if it is available.
1 Like

Nice work!

My bet is libedit:

Stephen

Right on target :slight_smile:
I reverted back to an old image and updated everything but libedit, and the cli is fine.
Just for the sake of completeness:
Works: libedit 20150325_3.1-2
Glitches: libedit-20160618_3.1-1

Not sure if the bug is in asterisk or libedit, but libedit might stay out of date for a little while on my servers :wink:
Thanks both for your help

Vincent

Nice work!

I’m thinking that the only reason that this is just affecting us, is that Arch is probably one of the few installs that is using libedit.

Stephen

Hi guys,

I’m having the same issue with alarm. Is there an easy way to fix this problem? Which version of Asterisk does the problem first appear in? Or is the problem just with libedit? Is there a way i can rollback libedit on alarm?

Thanks,
Luke

Hi Luke,

there are two ways to fix the problem:

  • downgrade libedit to the version described in Vincent’s post of July 27th: get the tar.xz from somewhere (maybe your package cache?: /var/cache/pacman/pkg/), invoke pacman -U on the package file, that should downgrade it. CLI should be working again after restarting asterisk. You yet have to be careful that on any system update you do from then on (pacman -Syu) to add --ignore libedit otherwise pacman will update your libedit back to the latest version!
  • my solution was yet different as I did not want to downgrade the system libedit (is used by other packages too and I am not sure about security fixes): as I build asterisk myself anyway, I added --without-libedit to its configure -line. This will force asterisk to build & use its own internal version of libedit, and not the one found in the system. That way, asterisk is independent of any updates to the Arch version of the lib.

Hope it helps,
H.

1 Like

I love this solution! I will do this the next time I build Asterisk. Thank you.

But meanwhile, there must be something about the configuration of libedit within Arch which is causing these problems. That would be the final solution. Anyone have any idea what it might be?

Stephen

Hi Horatio,

Thanks for your help, sorry for the late reply. I’ll have a go at recompiling asterisk in a few days and see how I go.

Thanks
Luke

This problem still exists on fedora25.

rpm -qva|egrep ‘asterisk|libedit’

asterisk-voicemail-13.9.1-1.fc25.1.x86_64
libedit-3.1-16.20160618cvs.fc25.x86_64
asterisk-voicemail-plain-13.9.1-1.fc25.1.x86_64
asterisk-sip-13.9.1-1.fc25.1.x86_64
asterisk-13.9.1-1.fc25.1.x86_64
asterisk-sounds-core-en-1.5.0-1.fc24.noarch
asterisk-dahdi-13.9.1-1.fc25.1.x86_64
asterisk-sounds-core-en-gsm-1.5.0-1.fc24.noarch

It’s still the latest (and only) version of libedit available.

Hello Everyone,
Fedora Server 25 fix is right here are

http://ftpsrv01.networklab.ca/fedora/25/RPMS/x86_64/

To apply fix.

Install networklab.repo /etc/yum.repos.d
Use dnf

dnf clean all; dnf update asterisk\*; dnf downgrade libedit;

Restart asterisk

systemctl restart asterisk.service

Add exclude line to /etc/dnf/dnf.conf

exclude=libedit

Hi, just getting to this now. Can you tell me more about the networklab
repo? Is this something you maintain? What are the asterisk changes that
were made here? Is it just for compatibility to fix the libedit problem, or
other more general changes?

Thanks!

Hello,
Yes our repo is actively maintained by NetworkLab. This particular case we back ported correct version of libedit to fedora 25 and generated new asterisk rpms.

Awesome, thanks so much.

Same Problem here after upgrading Ubuntu LTS Xenial (16.04) to Bionic (18.04) on armhf (raspberry pi 2).
I’m stuck.

Did you try compiling Asterisk without libedit as one user suggested earlier in the thread?

Thanks for the fast reply John. No I didn’t yet… I just saw that the upgrade process didn’t work… some packages left unconfigured or not updated, asterisk among them. Need to fix that first. Will write an update soon.