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…
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.
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).
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…
Right on target
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
Thanks both for your help
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?
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.
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?
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?
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.
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.