[App_rpt-users] URI-X Issues With New Raspbian build

[Eric Osterberg]

That's a lot of text I'm not going to fully read. I sense some frustration.

*(Under statement/insert sarcasm)*
First idea I have for you... Your "asterisk -rvvv" command is trying to
connect with an already running instance of the asterisk service. That
error message about "...var/run/asterisk.ctl..." does not exist... simply
means that the service isn't online. You might try this command... "asterisk
-cgvvv". I suspect you'll learn more about what's failing from that output.

Here's a reference to the command line options...
https://www.voip-info.org/asterisk-options
PS: I know nothing about this build... Just some basic asterisk
administration... Hope it helps you and you in turn pay it forward and help
others.

73 - Good luck...
  NØNKI - Eric in Minneapolis Minnesota

On Wed, Jul 11, 2018 at 10:47 PM, Jim Aspinwall No1PC <no1pc at yahoo.com>
wrote:

> So, I 'blew' the latest Stretch build into a new USB flash device...
> booted and tried to configure an existing node onto it on hardware that is
> known to work under prior.
>
> 1. ASL-MENU did NOT over-write the rpt.conf nor iax.conf files with given
> parameters - run as 'repeater' sudo root or enabled root user.  FAIL.  How
> is this fail 'possible' ?
>
> 2. Asterisk -rvvvvv... consistently revealed that the attached known
> interface did not exist and failed out with "...var/run/asterisk.ctl..."
> does not exist... when it actually does - what condition manifests this?
>
> NO low voltage errors on the console... all this on a known Pi3 AND RA-40
> interface configuration under prior Jessie install...
>
> To this... after decades of WinTel system support and a variety of x-Nix
> support work...
>
> ... please understand I do NOT *want* to hint at, support, or indicate
> that 'Crompton' may be on to something because his builds aren't all that
> stable and documentation and support are no better an often wrong,
> accusational... but have not exhibited this level of 'stupid' non-function.
>
> I am also someone at the brunt of "it doesn't work" as an esclation point
> in massive enterprises, and can at least identify and analyze log files
> that may contain some hints... "give me (path)xxx log file..." and at least
> I provide or know full paths, not casual non-specific references.  I would
> hope, expect the contributing community to be robust in definitive, helpful
> logging and not simply dismiss users to unqualified rhetoric/fault.
>
> That said...the latest Jessie build is a failure.  The latest Stretch
> build is a failure.  "change my mind"
>
> I'm back to tweaking the prior Jessie build to work as 'advertised' sans
> asl-menu and don't dare chance an upgrade/update process to the latest...
>
> I merely anticipate the coders know various failure conditions, can detect
> and log them... but that is an anticipation not rendered in actual logical
> recorded fact.|
>
> OK - get it - code contributors are volunteers. Volunteers that are
> supposedly intimate and knowledgeable with the code, functions, conditions,
> etc.  Bad power (not evident), bad storage/boot device (not evident),
> yadda... so, what?
>
> If you cannot document the 'proper' necessary requirements for hardware,
> process, etc. you cannot hold us users accountable or nor unknown
> circumstances to blame for failures. This is logical, programmatic...
> SOMETHING can detect (or not) attached hardware and communications
> functions... but yet not tell us what part(s) failed?
>
> Certainly when a convenient configuration menu/utility cannot/will not
> write-out changed parameters - one can determine a file system or rights
> issue... and reveal same... not leaving the user with the deception the
> system is good to go when it is sitting there at useless defaults.
>
> We really do NOT want this project left to Crompton for the popular vote,
> nor the x-Nix elitists... it's much too good for either of that.
>
> I among others are willing to dig deep and provide any log files, etc.
> that are effective to supportive solutions.  If logging content is
> ambiguous, not adequate to specific known logical issues, improve logging.
> If scripts do not work... let's debug...
>
> The leave behind is that if you were lucky enough to capture a prior Jesse
> build... sans asl-menu... stash it away and work around manual configs,
> leave it not user-friendly.
>
> If there are specific hardware, storage device requirements, document and
> better test for them. Obviously a current bootable latest Jessie build is
> NOT effective to new or existing node success. Why?
>
> Leave all of this to unstable, undocumented Crompton builds, or do equal
> or better...
>
> How can I/we help?
>
>
> -------------------
> Today's Topics:
>
>   1. Re: URI-X Issues With New Raspbian build (Steve Zingman)
>   2. Replay of June 26th Net at 8pm EDT (tonight) on    29999 (Mike)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 Jul 2018 15:31:47 -0400
> From: Steve Zingman <szingman at msgstor.com>
> To: Users of Asterisk app_rpt <app_rpt-users at lists.allstarlink.org>
> Subject: Re: [App_rpt-users] URI-X Issues With New Raspbian build
> Message-ID: <b9e5a338-8b97-9d40-5a73-7a1757b76366 at msgstor.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> If I had to guess, I would say a bad SD card burn. or a bad card.
>
> Steve N4IRS
>
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit http://lists.allstarlink.org/
> cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of
> the page. Enter your email address and press the "Unsubscribe or edit
> options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a message to
> the list detailing the problem.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20180712/3d9669f4/attachment.html>