astlinux-users — AstLinux Users Mailing List

Re: [Astlinux-users] Getting segfault in app_queue.so

[Michael K. <mic...@ip...>]

Probably should try that first I suppose. 

Regards
Michael Knill

On 7/4/20, 10:21 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Maybe Asterisk (se) 13.23.1 has it fixed.
    
    Lonnie
    
    
    > On Apr 6, 2020, at 7:14 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Thanks Lonnie
    > 
    > Unfortunately the response I received Josh on the Asterisk forum was that he was sick of spending time chasing things that were already fixed and that I needed a backtrace to look any deeper. I do understand his position but that doesn't help us that much.
    > 
    > I'm not quite sure where to take it from here other than to use the non SE version of Astlinux and see if it fixes the problem.
    > PS I have another customer who is using an IVR with queueing and there are no issues. They don't get as many calls as the problem site and may not do what triggers the crash but they are on a later version of Asterisk (13.23.1) so that could be the reason. Hard to work out.
    > 
    > Regards
    > Michael Knill
    > 
    > On 7/4/20, 8:17 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    > 
    >    Michael,
    > 
    >    If Asterisk 13.25 works for you we can try to find the related patch and apply it to the 'se' 13.23.1.
    > 
    >    Possibly you can followup your forum question to pinpoint which commit(s) fix the issue.
    > 
    >    Lonnie
    > 
    > 
    > 
    >> On Apr 6, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote:
    >> 
    >> I got a response on the Asterisk forum saying that Asterisk 13.25 solved this problem for someone.
    >> Think I will probably need to upgrade past the SE version.
    >> 
    >> Regards
    >> Michael Knill
    >> 
    >> From: Michael Knill <mic...@ip...>
    >> Reply to: AstLinux List <ast...@li...>
    >> Date: Tuesday, 7 April 2020 at 7:04 am
    >> To: AstLinux List <ast...@li...>
    >> Subject: [Astlinux-users] Getting segfault in app_queue.so
    >> 
    >> Hi Guys
    >> 
    >> Yay I am receiving forum emails again.
    >> 
    >> I realise that this is an Asterisk problem but I have hit a dead end on the Asterisk forum and hoping someone here could help.
    >> I have a busy Asterisk system at a doctors clinic (a very large one) which is using Asterisk queuing for incoming calls. Its currently running Asterisk 13.18.5. It has been running fine for well over a year now.
    >> I recently added an IVR in front of the queue and was forced to revert the change due to regular segfaults:
    >> Mar 26 08:35:22 3037-QGPSC-CM1 user.info kernel: asterisk[25700]: segfault at 10 ip 00002ad14c5a319c sp 00002ad15229dcd0 error 4 in app_queue.so[2ad14c58a000+36000]
    >> Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Asterisk exited on signal 11.
    >> Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Automatically restarting Asterisk.
    >> 
    >> Now I was previously experiencing identical app_queue segfaults on this system (log messages only) when using a different dialplan setup of cascading queues. At the time I suspected that I was having issues with ASTERISK-27006 and after reverting the Asterisk version to 13.14.1, (thanks Lonnie for helping with this), the problem went away. Since then I have changed the dialplan back to a standard single queue setup and have upgraded to Astlinux 1.3.2 (Asterisk 13.18.5) and I suspect that I am experiencing the same bug.
    >> 
    >> I build generic dialplan modules which create a Local channel between them during the call flow so the caller would be connected from the IVR to the queue via a Local Channel. This could be the reason why this bug may be coming into play again.
    >> 
    >> Any ideas?
    >> Unfortunately I cant do any more on the Asterisk forum unless I can get a backtrace. Can I do this in Astlinux? Not that I am that thrilled about crashing their system again during this crazy COVID-19 time ☹
    >> 
    >> Thanks so much all.
    >> Mike
    >> _______________________________________________
    >> Astlinux-users mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > 
    >    _______________________________________________
    >    Astlinux-users mailing list
    >    Ast...@li...
    >    https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    >    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    
    
    
    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users
    
    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Getting segfault in app_queue.so

[Lonnie A. <li...@lo...>]

Maybe Asterisk (se) 13.23.1 has it fixed.

Lonnie


> On Apr 6, 2020, at 7:14 PM, Michael Knill <mic...@ip...> wrote:
> 
> Thanks Lonnie
> 
> Unfortunately the response I received Josh on the Asterisk forum was that he was sick of spending time chasing things that were already fixed and that I needed a backtrace to look any deeper. I do understand his position but that doesn't help us that much.
> 
> I'm not quite sure where to take it from here other than to use the non SE version of Astlinux and see if it fixes the problem.
> PS I have another customer who is using an IVR with queueing and there are no issues. They don't get as many calls as the problem site and may not do what triggers the crash but they are on a later version of Asterisk (13.23.1) so that could be the reason. Hard to work out.
> 
> Regards
> Michael Knill
> 
> On 7/4/20, 8:17 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>    Michael,
> 
>    If Asterisk 13.25 works for you we can try to find the related patch and apply it to the 'se' 13.23.1.
> 
>    Possibly you can followup your forum question to pinpoint which commit(s) fix the issue.
> 
>    Lonnie
> 
> 
> 
>> On Apr 6, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> I got a response on the Asterisk forum saying that Asterisk 13.25 solved this problem for someone.
>> Think I will probably need to upgrade past the SE version.
>> 
>> Regards
>> Michael Knill
>> 
>> From: Michael Knill <mic...@ip...>
>> Reply to: AstLinux List <ast...@li...>
>> Date: Tuesday, 7 April 2020 at 7:04 am
>> To: AstLinux List <ast...@li...>
>> Subject: [Astlinux-users] Getting segfault in app_queue.so
>> 
>> Hi Guys
>> 
>> Yay I am receiving forum emails again.
>> 
>> I realise that this is an Asterisk problem but I have hit a dead end on the Asterisk forum and hoping someone here could help.
>> I have a busy Asterisk system at a doctors clinic (a very large one) which is using Asterisk queuing for incoming calls. Its currently running Asterisk 13.18.5. It has been running fine for well over a year now.
>> I recently added an IVR in front of the queue and was forced to revert the change due to regular segfaults:
>> Mar 26 08:35:22 3037-QGPSC-CM1 user.info kernel: asterisk[25700]: segfault at 10 ip 00002ad14c5a319c sp 00002ad15229dcd0 error 4 in app_queue.so[2ad14c58a000+36000]
>> Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Asterisk exited on signal 11.
>> Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Automatically restarting Asterisk.
>> 
>> Now I was previously experiencing identical app_queue segfaults on this system (log messages only) when using a different dialplan setup of cascading queues. At the time I suspected that I was having issues with ASTERISK-27006 and after reverting the Asterisk version to 13.14.1, (thanks Lonnie for helping with this), the problem went away. Since then I have changed the dialplan back to a standard single queue setup and have upgraded to Astlinux 1.3.2 (Asterisk 13.18.5) and I suspect that I am experiencing the same bug.
>> 
>> I build generic dialplan modules which create a Local channel between them during the call flow so the caller would be connected from the IVR to the queue via a Local Channel. This could be the reason why this bug may be coming into play again.
>> 
>> Any ideas?
>> Unfortunately I cant do any more on the Asterisk forum unless I can get a backtrace. Can I do this in Astlinux? Not that I am that thrilled about crashing their system again during this crazy COVID-19 time ☹
>> 
>> Thanks so much all.
>> Mike
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
>    _______________________________________________
>    Astlinux-users mailing list
>    Ast...@li...
>    https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
>    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Getting segfault in app_queue.so

[Michael K. <mic...@ip...>]

Thanks Lonnie

Unfortunately the response I received Josh on the Asterisk forum was that he was sick of spending time chasing things that were already fixed and that I needed a backtrace to look any deeper. I do understand his position but that doesn't help us that much.

I'm not quite sure where to take it from here other than to use the non SE version of Astlinux and see if it fixes the problem.
PS I have another customer who is using an IVR with queueing and there are no issues. They don't get as many calls as the problem site and may not do what triggers the crash but they are on a later version of Asterisk (13.23.1) so that could be the reason. Hard to work out.

Regards
Michael Knill

On 7/4/20, 8:17 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Michael,
    
    If Asterisk 13.25 works for you we can try to find the related patch and apply it to the 'se' 13.23.1.
    
    Possibly you can followup your forum question to pinpoint which commit(s) fix the issue.
    
    Lonnie
    
    
    
    > On Apr 6, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > I got a response on the Asterisk forum saying that Asterisk 13.25 solved this problem for someone.
    > Think I will probably need to upgrade past the SE version.
    >  
    > Regards
    > Michael Knill
    >  
    > From: Michael Knill <mic...@ip...>
    > Reply to: AstLinux List <ast...@li...>
    > Date: Tuesday, 7 April 2020 at 7:04 am
    > To: AstLinux List <ast...@li...>
    > Subject: [Astlinux-users] Getting segfault in app_queue.so
    >  
    > Hi Guys
    >  
    > Yay I am receiving forum emails again.
    >  
    > I realise that this is an Asterisk problem but I have hit a dead end on the Asterisk forum and hoping someone here could help.
    > I have a busy Asterisk system at a doctors clinic (a very large one) which is using Asterisk queuing for incoming calls. Its currently running Asterisk 13.18.5. It has been running fine for well over a year now.
    > I recently added an IVR in front of the queue and was forced to revert the change due to regular segfaults:
    > Mar 26 08:35:22 3037-QGPSC-CM1 user.info kernel: asterisk[25700]: segfault at 10 ip 00002ad14c5a319c sp 00002ad15229dcd0 error 4 in app_queue.so[2ad14c58a000+36000]
    > Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Asterisk exited on signal 11.
    > Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Automatically restarting Asterisk.
    >  
    > Now I was previously experiencing identical app_queue segfaults on this system (log messages only) when using a different dialplan setup of cascading queues. At the time I suspected that I was having issues with ASTERISK-27006 and after reverting the Asterisk version to 13.14.1, (thanks Lonnie for helping with this), the problem went away. Since then I have changed the dialplan back to a standard single queue setup and have upgraded to Astlinux 1.3.2 (Asterisk 13.18.5) and I suspect that I am experiencing the same bug.
    >  
    > I build generic dialplan modules which create a Local channel between them during the call flow so the caller would be connected from the IVR to the queue via a Local Channel. This could be the reason why this bug may be coming into play again.
    >  
    > Any ideas?
    > Unfortunately I cant do any more on the Asterisk forum unless I can get a backtrace. Can I do this in Astlinux? Not that I am that thrilled about crashing their system again during this crazy COVID-19 time ☹
    >  
    > Thanks so much all.
    > Mike
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    
    
    
    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users
    
    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Getting segfault in app_queue.so

[Lonnie A. <li...@lo...>]

Michael,

If Asterisk 13.25 works for you we can try to find the related patch and apply it to the 'se' 13.23.1.

Possibly you can followup your forum question to pinpoint which commit(s) fix the issue.

Lonnie



> On Apr 6, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote:
> 
> I got a response on the Asterisk forum saying that Asterisk 13.25 solved this problem for someone.
> Think I will probably need to upgrade past the SE version.
>  
> Regards
> Michael Knill
>  
> From: Michael Knill <mic...@ip...>
> Reply to: AstLinux List <ast...@li...>
> Date: Tuesday, 7 April 2020 at 7:04 am
> To: AstLinux List <ast...@li...>
> Subject: [Astlinux-users] Getting segfault in app_queue.so
>  
> Hi Guys
>  
> Yay I am receiving forum emails again.
>  
> I realise that this is an Asterisk problem but I have hit a dead end on the Asterisk forum and hoping someone here could help.
> I have a busy Asterisk system at a doctors clinic (a very large one) which is using Asterisk queuing for incoming calls. Its currently running Asterisk 13.18.5. It has been running fine for well over a year now.
> I recently added an IVR in front of the queue and was forced to revert the change due to regular segfaults:
> Mar 26 08:35:22 3037-QGPSC-CM1 user.info kernel: asterisk[25700]: segfault at 10 ip 00002ad14c5a319c sp 00002ad15229dcd0 error 4 in app_queue.so[2ad14c58a000+36000]
> Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Asterisk exited on signal 11.
> Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Automatically restarting Asterisk.
>  
> Now I was previously experiencing identical app_queue segfaults on this system (log messages only) when using a different dialplan setup of cascading queues. At the time I suspected that I was having issues with ASTERISK-27006 and after reverting the Asterisk version to 13.14.1, (thanks Lonnie for helping with this), the problem went away. Since then I have changed the dialplan back to a standard single queue setup and have upgraded to Astlinux 1.3.2 (Asterisk 13.18.5) and I suspect that I am experiencing the same bug.
>  
> I build generic dialplan modules which create a Local channel between them during the call flow so the caller would be connected from the IVR to the queue via a Local Channel. This could be the reason why this bug may be coming into play again.
>  
> Any ideas?
> Unfortunately I cant do any more on the Asterisk forum unless I can get a backtrace. Can I do this in Astlinux? Not that I am that thrilled about crashing their system again during this crazy COVID-19 time ☹
>  
> Thanks so much all.
> Mike
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Getting segfault in app_queue.so

[Michael K. <mic...@ip...>]

I got a response on the Asterisk forum saying that Asterisk 13.25 solved this problem for someone.
Think I will probably need to upgrade past the SE version.

Regards
Michael Knill

From: Michael Knill <mic...@ip...>
Reply to: AstLinux List <ast...@li...>
Date: Tuesday, 7 April 2020 at 7:04 am
To: AstLinux List <ast...@li...>
Subject: [Astlinux-users] Getting segfault in app_queue.so

Hi Guys

Yay I am receiving forum emails again.

I realise that this is an Asterisk problem but I have hit a dead end on the Asterisk forum and hoping someone here could help.
I have a busy Asterisk system at a doctors clinic (a very large one) which is using Asterisk queuing for incoming calls. Its currently running Asterisk 13.18.5. It has been running fine for well over a year now.
I recently added an IVR in front of the queue and was forced to revert the change due to regular segfaults:
Mar 26 08:35:22 3037-QGPSC-CM1 user.info kernel: asterisk[25700]: segfault at 10 ip 00002ad14c5a319c sp 00002ad15229dcd0 error 4 in app_queue.so[2ad14c58a000+36000]
Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Asterisk exited on signal 11.
Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Automatically restarting Asterisk.

Now I was previously experiencing identical app_queue segfaults on this system (log messages only) when using a different dialplan setup of cascading queues. At the time I suspected that I was having issues with ASTERISK-27006 and after reverting the Asterisk version to 13.14.1, (thanks Lonnie for helping with this), the problem went away. Since then I have changed the dialplan back to a standard single queue setup and have upgraded to Astlinux 1.3.2 (Asterisk 13.18.5) and I suspect that I am experiencing the same bug.

I build generic dialplan modules which create a Local channel between them during the call flow so the caller would be connected from the IVR to the queue via a Local Channel. This could be the reason why this bug may be coming into play again.

Any ideas?
Unfortunately I cant do any more on the Asterisk forum unless I can get a backtrace. Can I do this in Astlinux? Not that I am that thrilled about crashing their system again during this crazy COVID-19 time ☹

Thanks so much all.
Mike

Re: [Astlinux-users] Disk checking on power reset

[Michael K. <mic...@ip...>]

Great thanks Lonnie. Just had me a little worried.

Regards
Michael Knill

On 7/4/20, 6:52 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    
    
    > On Apr 6, 2020, at 3:01 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Hi Group
    >  
    > I'm surprised I haven’t seen this before on my APU’s (possibly other systems), but when an e2fsck disk check is forced on an unclean unmount (power reset), it actually needs to fix errors every time on all the systems I have tested e.g.:
    > ------
    > ASTURW was not cleanly unmounted, check forced.
    > Pass 1: Checking inodes, blocks, and sizes
    > Pass 2: Checking directory structure                                          
    > Pass 3: Checking directory connectivity
    > Pass 4: Checking reference counts
    > Pass 5: Checking group summary information
    > ASTURW: 2489/65536 files (0.7% non-contiguous), 70516/262144 blocks           
    > Fsck detected and repaired errors on /dev/sda2
    >  
    > ASTKD was not cleanly unmounted, check forced.
    > Pass 1: Checking inodes, blocks, and sizes
    > Pass 2: Checking directory structure                                          
    > Pass 3: Checking directory connectivity
    > Pass 4: Checking reference counts
    > Pass 5: Checking group summary information                                     
    > Free blocks count wrong (14168129, counted=14168099).                         
    > Fix? yes
    >  
    > Free inodes count wrong (3635651, counted=3635632).                           
    > Fix? yes
    >  
    >  
    > ASTKD: ***** FILE SYSTEM WAS MODIFIED *****
    > ASTKD: 1616/3637248 files (0.6% non-contiguous), 354755/14522854 blocks
    > /dev/sda3 was checked and is now clean.
    > ---------
    >  
    > So my questions are:
    > 	• Is this a bad thing or is it normal? Could a power reset actually cause a disk error?
    > 	• Is there any way for this not to happen? Is it the type of mSATA I am using?
    >  
    > Thanks all.
    >  
    > Regards
    > Michael Knill
    
    Yes, that is normal from what I have seen, in fact whenever we upgrade the e2fsprogs package I power-cycle my APU2 test box and look for the e2fsck disk check response.
    
    The e2fsck check fix should never require human interaction.
    
    Possibly the type of mSATA SSD could make a difference.  No data to support that though.
    
    Lonnie
    
    
    
    
    
    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users
    
    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

[Astlinux-users] Getting segfault in app_queue.so

[Michael K. <mic...@ip...>]

Hi Guys

Yay I am receiving forum emails again.

I realise that this is an Asterisk problem but I have hit a dead end on the Asterisk forum and hoping someone here could help.
I have a busy Asterisk system at a doctors clinic (a very large one) which is using Asterisk queuing for incoming calls. Its currently running Asterisk 13.18.5. It has been running fine for well over a year now.
I recently added an IVR in front of the queue and was forced to revert the change due to regular segfaults:
Mar 26 08:35:22 3037-QGPSC-CM1 user.info kernel: asterisk[25700]: segfault at 10 ip 00002ad14c5a319c sp 00002ad15229dcd0 error 4 in app_queue.so[2ad14c58a000+36000]
Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Asterisk exited on signal 11.
Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Automatically restarting Asterisk.

Now I was previously experiencing identical app_queue segfaults on this system (log messages only) when using a different dialplan setup of cascading queues. At the time I suspected that I was having issues with ASTERISK-27006 and after reverting the Asterisk version to 13.14.1, (thanks Lonnie for helping with this), the problem went away. Since then I have changed the dialplan back to a standard single queue setup and have upgraded to Astlinux 1.3.2 (Asterisk 13.18.5) and I suspect that I am experiencing the same bug.

I build generic dialplan modules which create a Local channel between them during the call flow so the caller would be connected from the IVR to the queue via a Local Channel. This could be the reason why this bug may be coming into play again.

Any ideas?
Unfortunately I cant do any more on the Asterisk forum unless I can get a backtrace. Can I do this in Astlinux? Not that I am that thrilled about crashing their system again during this crazy COVID-19 time ☹

Thanks so much all.
Mike

Re: [Astlinux-users] Disk checking on power reset

[Lonnie A. <li...@lo...>]

> On Apr 6, 2020, at 3:01 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Group
>  
> I'm surprised I haven’t seen this before on my APU’s (possibly other systems), but when an e2fsck disk check is forced on an unclean unmount (power reset), it actually needs to fix errors every time on all the systems I have tested e.g.:
> ------
> ASTURW was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure                                          
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> ASTURW: 2489/65536 files (0.7% non-contiguous), 70516/262144 blocks           
> Fsck detected and repaired errors on /dev/sda2
>  
> ASTKD was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure                                          
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information                                     
> Free blocks count wrong (14168129, counted=14168099).                         
> Fix? yes
>  
> Free inodes count wrong (3635651, counted=3635632).                           
> Fix? yes
>  
>  
> ASTKD: ***** FILE SYSTEM WAS MODIFIED *****
> ASTKD: 1616/3637248 files (0.6% non-contiguous), 354755/14522854 blocks
> /dev/sda3 was checked and is now clean.
> ---------
>  
> So my questions are:
> 	• Is this a bad thing or is it normal? Could a power reset actually cause a disk error?
> 	• Is there any way for this not to happen? Is it the type of mSATA I am using?
>  
> Thanks all.
>  
> Regards
> Michael Knill

Yes, that is normal from what I have seen, in fact whenever we upgrade the e2fsprogs package I power-cycle my APU2 test box and look for the e2fsck disk check response.

The e2fsck check fix should never require human interaction.

Possibly the type of mSATA SSD could make a difference.  No data to support that though.

Lonnie

[Astlinux-users] Disk checking on power reset

[Michael K. <mic...@ip...>]

Hi Group

I'm surprised I haven’t seen this before on my APU’s (possibly other systems), but when an e2fsck disk check is forced on an unclean unmount (power reset), it actually needs to fix errors every time on all the systems I have tested e.g.:
------
ASTURW was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
ASTURW: 2489/65536 files (0.7% non-contiguous), 70516/262144 blocks
Fsck detected and repaired errors on /dev/sda2

ASTKD was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (14168129, counted=14168099).
Fix? yes

Free inodes count wrong (3635651, counted=3635632).
Fix? yes


ASTKD: ***** FILE SYSTEM WAS MODIFIED *****
ASTKD: 1616/3637248 files (0.6% non-contiguous), 354755/14522854 blocks
/dev/sda3 was checked and is now clean.
---------

So my questions are:

  1.  Is this a bad thing or is it normal? Could a power reset actually cause a disk error?
  2.  Is there any way for this not to happen? Is it the type of mSATA I am using?

Thanks all.

Regards
Michael Knill

[Astlinux-users] Announcing AstLinux Release: 1.3.8

[Lonnie A. <li...@lo...>]

Announcing AstLinux Release: 1.3.8

More Info: AstLinux Project
https://www.astlinux-project.org/

AstLinux 1.3.8 Highlights:
* Asterisk Versions: 13.23.1, 13.31.0, 16.8.0
* Upgrade to Linux Kernel 3.16.82, including the RUNNIX bootloader, security and bug fixes
* OpenSSL, version bump to 1.1.1f
* pppd, version bump to 2.4.8, security fix: CVE-2020-8597
* WireGuard VPN, first official release 1.0.20200330, backport of its incorporation into the Linux Kernel 5.6
* OpenVPN, version bump to 2.4.8
* chrony, version bump to 4.0-pre1, adds 'maxsamples 1' and 'chronyc -N sources' support
* acme-client, version bump to 2.8.5
* arp-scan, version bump to 1.9.7, fixed with libpcap version 1.9.1
* ncurses, version bump to 6.2
* ne, version bump to 3.3.0
* Asterisk '13se' (stable edition) version 13.23.1 is older than latest Asterisk 13.x version but more tested, built --without-pjproject
* Package upgrades providing important security and bug fixes

Full ChangeLog:
https://raw.githubusercontent.com/astlinux-project/astlinux/1.3.8/docs/ChangeLog.txt

All users are encouraged to upgrade.

Previous Asterisk 11.x users are encouraged to switch to the new Asterisk '13se' (stable edition). Some configuration changes will be needed, though minimal.

AstLinux Team

[Astlinux-users] astlinux No channel type registered for 'PJSIP'

[nedi <ne...@gm...>]

Hi
I loged in as agent and in the CLI I can see loged in Agent

But if I try to dialing a number I get this error

astlinux No channel type registered for ‚PJSIP'
astlinux No channel type registered for ‚PJSIP'

Can anyone help ?

regards
 Nedi

Re: [Astlinux-users] Help with FW 7525 bios

[Lonnie A. <li...@lo...>]

> On Apr 1, 2020, at 10:30 PM, gtracy <gt...@pe...> wrote:
> 
> I have a Lanner FW 7525 and in desperate need of a copy of the bios. Lanner no longer supports this firewall and thus the bios is no longer available on their web site.
> 
> If anyone can help me out it would be most appreciated.
> 
> Glenn.

The Lanner FW-7525 is shown on their product page:

https://www.lannerinc.com/products/network-appliances/x86-desktop-network-appliances/fw-7525

Possibly click the chat window there to get what you need.

I would also expect the 7525 variations 'A' through 'D' each have different BIOS.

Lonnie

[Astlinux-users] Help with FW 7525 bios

[gtracy <gt...@pe...>]

I have a Lanner FW 7525 and in desperate need of a copy of the bios. 
Lanner no longer supports this firewall and thus the bios is no longer 
available on their web site.

If anyone can help me out it would be most appreciated.

Glenn.

Re: [Astlinux-users] Upgrading Coreboot firmware of PC Engines APU with flashrom

[Dr. P. V. <pv...@uo...>]

Hi Lonnie,

even if threre is no dependency anymore: Please provide a dmidecode
binary as well as suggested by Michael. Otherwise you cannot easily
determine mainboard and BIOS information to check, if flash has been
successful. To my knowledge flashrom itself does not provide reading
the current BIOS version.

Regards,
Peter


On Sat, 28 Mar 2020 12:04:51 -0500
Lonnie Abelbeck <li...@lo...> wrote:

> Hi Michael,
> 
> The 'dmidecode' dependency was removed with flashrom 0.9.8
> (2015-03-01).
> 
> Time flies :-)
> 
> Lonnie
> 

Re: [Astlinux-users] No audio when incoming SIP trunk calls forwarded by endpoint back out of same SIP trunk

[Tom C. <tom...@nn...>]

> > in one case. the SIP provider is velocity, I had to actually Answer(), establish
> audio then transfer the call before 2 way audio would establish..   I
> accomplished this by answering then playing a quick "please hold" then
> sending the call off to the external number..
>
> the tip with "Answer" (and playing music during transfer ("m-option" of the
> Dial command)) worked fine!

Thanks so much for both of you - we're all working now (I think!). Really grateful for the quick replies.

Regards

Tom


Tom Chadwin, ICT Manager
Telephone: 01434 611530 Mob:
Web: www.northumberlandnationalpark.org.uk<http://www.northumberlandnationalpark.org.uk/>

IMPORTANT NOTICE - Disclaimer - This communication is from Northumberland National Park Authority (NNPA).The Authority’s head office and principal place of business is Eastburn, South Park, Hexham, Northumberland, NE46 1BS, United Kingdom. If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please delete the email and destroy any copies of it. Any views or opinions presented are solely those of the author and do not necessarily represent those of NNPA.Contractors or potential contractors are reminded that a formal Order or Contract is needed for NNPA to be bound by any offer or acceptance of terms for the supply of goods or services Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by the NNPA for any loss or damage arising in any way from the receipt or use thereof. Computer systems of this Authority may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purpose.

Re: [Astlinux-users] No audio when incoming SIP trunk calls forwarded by endpoint back out of same SIP trunk

[Michael K. <li...@mk...>]

> Am 30.03.2020 um 14:32 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>:
> 
> Ive had this same issue..  while im not running on astlinux on my production sites..  ive found that I needed to do one of 2 things..  
> anchor the media at the asterisk server, so the directmedia = no  on the SIP trunk, and in the SIP settings I needed to have my externip = my.public.ip.here  and localnet = 172.16.0.5/255.255.252.0   (use your localnet)..  it seems that the forward sends the Internal IP of asterisk in the redirect for the forward..   
> 
> I Ihandle my forwarding a little different. I handle it on the server as opposed to the phone..  (I have XML apps that forward the call in asterisk and light  the lamp on the phone when the user presses the key)..  those sites where the call is forwarded at asterisk vs the phone itself seem to fare a little better..  the reason I do this is the call still forwards even if ther phone gets unplugged, and the user can use our web-based User interface to turn their forward on / off remotely or change it. 
> 
> in one case. the SIP provider is velocity, I had to actually Answer(), establish audio then transfer the call before 2 way audio would establish..   I accomplished this by answering then playing a quick "please hold" then sending the call off to the external number..   

Hi Christopher,

the tip with "Answer" (and playing music during transfer ("m-option" of the Dial command)) worked fine!

> I can give you nore details if you wish to do this method
> -Christopher
> 
> On Monday, March 30, 2020, 4:09:09 AM EDT, Tom Chadwin <tom...@nn...> wrote:
> 
> 
> Morning all
> 
> We have a SIP trunk, with ample channels. With staff at home, they have tried to forward their phones to their home numbers. They do this on the endpoints themselves (Snom D305). However, it's not working. An incoming external call hits the phone, and is forwarded, rings, and is answered. However, after pickup, there is no audio either way.
> 
> Can anyone think of any reason why this might be happening?
> 
> Thanks
> 
> Tom
> 
> 
> Tom Chadwin, ICT Manager


Michael

http://www.mksolutions.info

Re: [Astlinux-users] FYI: WireGuard 1.0.0 is now official

[Michael K. <li...@mk...>]

> Am 30.03.2020 um 16:35 schrieb Lonnie Abelbeck <li...@lo...>:
> 
> Greetings,
> 
> FYI, I forwarded (below) a note from the WireGuard mailing list.
> 
> My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.
> 
> For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.
> 
> Lonnie
> 
> 
> ================
> Begin forwarded message:
> 
> From: "Jason A. Donenfeld" <Ja...@zx...>
> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
> Date: March 29, 2020 at 9:16:43 PM CDT
> To: WireGuard mailing list <wir...@li...>
> 
> Hi folks,
> 
> Earlier this evening, Linus released [1] Linus 5.6, which contains our
> first release of WireGuard. This is quite exciting. It means that
> kernels from here on out will have WireGuard built-in by default. And
> for those of you who were scared away prior by the "dOnT uSe tHiS
> k0de!!1!" warnings everywhere, you now have something more stable to
> work with.
> 
> The last several weeks of 5.6 development and stabilization have been
> exciting, with our codebase undergoing a quick security audit [3], and
> some real headway in terms of getting into distributions.
> 
> We'll also continue to maintain our wireguard-linux-compat [2]
> backports repo for older kernels. On the backports front, WireGuard
> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
> and we'll see where those wind up; 5.4.y is an LTS release.
> 
> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> Fedora 32 will be getting WireGuard automatically by virtue of having
> 5.6, and I expect these to increase in number over time.
> 
> Enjoy!
> Jason
> 
> 
> [1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> [2] https://git.zx2c4.com/wireguard-linux-compat/
> [3] https://lore.kernel.org/netdev/202...@zx.../
> [4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> [5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y

Hi Lonnie,

this is great news!

Michael

http://www.mksolutions.info

[Astlinux-users] FYI: WireGuard 1.0.0 is now official

[Lonnie A. <li...@lo...>]

Greetings,

FYI, I forwarded (below) a note from the WireGuard mailing list.

My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.

For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.

Lonnie


================
Begin forwarded message:

From: "Jason A. Donenfeld" <Ja...@zx...>
Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
Date: March 29, 2020 at 9:16:43 PM CDT
To: WireGuard mailing list <wir...@li...>

Hi folks,

Earlier this evening, Linus released [1] Linus 5.6, which contains our
first release of WireGuard. This is quite exciting. It means that
kernels from here on out will have WireGuard built-in by default. And
for those of you who were scared away prior by the "dOnT uSe tHiS
k0de!!1!" warnings everywhere, you now have something more stable to
work with.

The last several weeks of 5.6 development and stabilization have been
exciting, with our codebase undergoing a quick security audit [3], and
some real headway in terms of getting into distributions.

We'll also continue to maintain our wireguard-linux-compat [2]
backports repo for older kernels. On the backports front, WireGuard
was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
and we'll see where those wind up; 5.4.y is an LTS release.

Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
Fedora 32 will be getting WireGuard automatically by virtue of having
5.6, and I expect these to increase in number over time.

Enjoy!
Jason


[1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
[2] https://git.zx2c4.com/wireguard-linux-compat/
[3] https://lore.kernel.org/netdev/202...@zx.../
[4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
[5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
[6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
[7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y

Re: [Astlinux-users] No audio when incoming SIP trunk calls forwarded by endpoint back out of same SIP trunk

[The C. K. <eld...@ya...>]

 ive got some of my group on softphones..  others we set up L2TP server on a MikroTik router  at the home office and then sent them and their hard phones home with another MikroTik set as L2TP client, we use the MikroTiks with POE and 48 volt PS so they just plug in and go with their hardphones..  some people want a better speakerphone..  Bria on a laptop is great till people use the internal keyboard and type while on speaker...  the L2TP tunnel provides security for the RTP as it travels within..  we dont use OpenVPN so running snoms with VPN firmware wasnt an option.. and i dont think the Aastras have VPN at all..  or if they do ive never explored it..  


    On Monday, March 30, 2020, 8:45:13 AM EDT, Tom Chadwin <tom...@nn...> wrote:  
 
 Hi Christopher

> anchor the media at the asterisk server, so the directmedia = no  on the SIP trunk, and in the SIP settings I needed to have my externip = my.public.ip.here  and localnet = 172.16.0.5/255.255.252.0  (use your localnet)..  it seems that the forward sends the Internal IP of asterisk in the redirect for the forward..

Yup, we're set up like this. Actually tried changing to directmedia=yes as an experiment to see whether some local issue was the problem. Neither solves the issue.

> I handle my forwarding a little different. I handle it on the server as opposed to the phone

Doesn't work very well for us, as we need users to be able to control themselves, which they currently do via the endpoint web interfaces. I do note your point about the phones needing to remain powered, though. On the first day the office was shut, the caretaker went round and turned everything off.

> in one case. the SIP provider is velocity, I had to actually Answer(), establish audio then transfer the call before 2 way audio would establish..  I accomplished this by answering then playing a quick "please hold" then sending the call off to the external number..

I read about this in an ancient (>10yrs) thread. If we have to go down this route, we shall.

Thanks for the help and the info. Best way forward at the moment is probably to avoid the whole matter and for us to get people up and running with softphones (as we've done for another site). But I'd love to understand the issue...

Thanks again

Tom


Tom Chadwin, ICT Manager
Telephone: 01434 611530 Mob:
Web: www.northumberlandnationalpark.org.uk<http://www.northumberlandnationalpark.org.uk/>

IMPORTANT NOTICE - Disclaimer - This communication is from Northumberland National Park Authority (NNPA).The Authority’s head office and principal place of business is Eastburn, South Park, Hexham, Northumberland, NE46 1BS, United Kingdom. If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please delete the email and destroy any copies of it. Any views or opinions presented are solely those of the author and do not necessarily represent those of NNPA.Contractors or potential contractors are reminded that a formal Order or Contract is needed for NNPA to be bound by any offer or acceptance of terms for the supply of goods or services Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by the NNPA for any loss or damage arising in any way from the receipt or use thereof. Computer systems of this Authority may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purpose.

_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....  

Re: [Astlinux-users] No audio when incoming SIP trunk calls forwarded by endpoint back out of same SIP trunk

[Tom C. <tom...@nn...>]

Hi Christopher

> anchor the media at the asterisk server, so the directmedia = no  on the SIP trunk, and in the SIP settings I needed to have my externip = my.public.ip.here  and localnet = 172.16.0.5/255.255.252.0   (use your localnet)..  it seems that the forward sends the Internal IP of asterisk in the redirect for the forward..

Yup, we're set up like this. Actually tried changing to directmedia=yes as an experiment to see whether some local issue was the problem. Neither solves the issue.

> I handle my forwarding a little different. I handle it on the server as opposed to the phone

Doesn't work very well for us, as we need users to be able to control themselves, which they currently do via the endpoint web interfaces. I do note your point about the phones needing to remain powered, though. On the first day the office was shut, the caretaker went round and turned everything off.

> in one case. the SIP provider is velocity, I had to actually Answer(), establish audio then transfer the call before 2 way audio would establish..   I accomplished this by answering then playing a quick "please hold" then sending the call off to the external number..

I read about this in an ancient (>10yrs) thread. If we have to go down this route, we shall.

Thanks for the help and the info. Best way forward at the moment is probably to avoid the whole matter and for us to get people up and running with softphones (as we've done for another site). But I'd love to understand the issue...

Thanks again

Tom


Tom Chadwin, ICT Manager
Telephone: 01434 611530 Mob:
Web: www.northumberlandnationalpark.org.uk<http://www.northumberlandnationalpark.org.uk/>

IMPORTANT NOTICE - Disclaimer - This communication is from Northumberland National Park Authority (NNPA).The Authority’s head office and principal place of business is Eastburn, South Park, Hexham, Northumberland, NE46 1BS, United Kingdom. If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please delete the email and destroy any copies of it. Any views or opinions presented are solely those of the author and do not necessarily represent those of NNPA.Contractors or potential contractors are reminded that a formal Order or Contract is needed for NNPA to be bound by any offer or acceptance of terms for the supply of goods or services Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by the NNPA for any loss or damage arising in any way from the receipt or use thereof. Computer systems of this Authority may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purpose.

Re: [Astlinux-users] No audio when incoming SIP trunk calls forwarded by endpoint back out of same SIP trunk

[The C. K. <eld...@ya...>]

 Ive had this same issue..  while im not running on astlinux on my production sites..  ive found that I needed to do one of 2 things..  
anchor the media at the asterisk server, so the directmedia = no  on the SIP trunk, and in the SIP settings I needed to have my externip = my.public.ip.here  and localnet = 172.16.0.5/255.255.252.0   (use your localnet)..  it seems that the forward sends the Internal IP of asterisk in the redirect for the forward..   

I Ihandle my forwarding a little different. I handle it on the server as opposed to the phone..  (I have XML apps that forward the call in asterisk and light  the lamp on the phone when the user presses the key)..  those sites where the call is forwarded at asterisk vs the phone itself seem to fare a little better..  the reason I do this is the call still forwards even if ther phone gets unplugged, and the user can use our web-based User interface to turn their forward on / off remotely or change it. 

in one case. the SIP provider is velocity, I had to actually Answer(), establish audio then transfer the call before 2 way audio would establish..   I accomplished this by answering then playing a quick "please hold" then sending the call off to the external number..   

I can give you nore details if you wish to do this method-Christopher

    On Monday, March 30, 2020, 4:09:09 AM EDT, Tom Chadwin <tom...@nn...> wrote:  
 
 Morning all

We have a SIP trunk, with ample channels. With staff at home, they have tried to forward their phones to their home numbers. They do this on the endpoints themselves (Snom D305). However, it's not working. An incoming external call hits the phone, and is forwarded, rings, and is answered. However, after pickup, there is no audio either way.

Can anyone think of any reason why this might be happening?

Thanks

Tom


Tom Chadwin, ICT Manager
Telephone: 01434 611530 Mob:
Web: www.northumberlandnationalpark.org.uk<http://www.northumberlandnationalpark.org.uk/>

IMPORTANT NOTICE - Disclaimer - This communication is from Northumberland National Park Authority (NNPA).The Authority’s head office and principal place of business is Eastburn, South Park, Hexham, Northumberland, NE46 1BS, United Kingdom. If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please delete the email and destroy any copies of it. Any views or opinions presented are solely those of the author and do not necessarily represent those of NNPA.Contractors or potential contractors are reminded that a formal Order or Contract is needed for NNPA to be bound by any offer or acceptance of terms for the supply of goods or services Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by the NNPA for any loss or damage arising in any way from the receipt or use thereof. Computer systems of this Authority may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purpose.

_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....  

[Astlinux-users] No audio when incoming SIP trunk calls forwarded by endpoint back out of same SIP trunk

[Tom C. <tom...@nn...>]

Morning all

We have a SIP trunk, with ample channels. With staff at home, they have tried to forward their phones to their home numbers. They do this on the endpoints themselves (Snom D305). However, it's not working. An incoming external call hits the phone, and is forwarded, rings, and is answered. However, after pickup, there is no audio either way.

Can anyone think of any reason why this might be happening?

Thanks

Tom


Tom Chadwin, ICT Manager
Telephone: 01434 611530 Mob:
Web: www.northumberlandnationalpark.org.uk<http://www.northumberlandnationalpark.org.uk/>

IMPORTANT NOTICE - Disclaimer - This communication is from Northumberland National Park Authority (NNPA).The Authority’s head office and principal place of business is Eastburn, South Park, Hexham, Northumberland, NE46 1BS, United Kingdom. If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please delete the email and destroy any copies of it. Any views or opinions presented are solely those of the author and do not necessarily represent those of NNPA.Contractors or potential contractors are reminded that a formal Order or Contract is needed for NNPA to be bound by any offer or acceptance of terms for the supply of goods or services Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by the NNPA for any loss or damage arising in any way from the receipt or use thereof. Computer systems of this Authority may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purpose.

Re: [Astlinux-users] Upgrading Coreboot firmware of PC Engines APU with flashrom

[Lonnie A. <li...@lo...>]

Hi Michael,

The 'dmidecode' dependency was removed with flashrom 0.9.8 (2015-03-01).

Time flies :-)

Lonnie


> On Mar 28, 2020, at 11:47 AM, Michael Keuter <li...@mk...> wrote:
> 
> Hi Lonnie,
> 
> Its long ago, but it can be that dmidecode is also needed.
> Build it as well, just in case.
> 
> Sent from a mobile device.
> 
> Michael Keuter
> 
>> Am 28.03.2020 um 14:13 schrieb Lonnie Abelbeck <li...@lo...>:
>> 
>> 
>> 
>>> On Mar 28, 2020, at 7:05 AM, Dr. Peter Voigt <pv...@uo...> wrote:
>>> 
>>> My AstLinux machine is a PC Engines APU1 and I would like to upgrade
>>> the strongly outdated Coreboot BIOS.
>>> 
>>> Usualy, under Linux and FreeBSD there is a flash program called
>>> "flashrom" which can be used to flash the BIOS from the running
>>> Operating system (Linux or FreeBSD). E.g. for Debian and FreeBSD package
>>> information is available here:
>>> https://packages.debian.org/buster/flashrom
>>> https://www.freshports.org/sysutils/flashrom/
>>> 
>>> Almost three years ago I successfully did the BIOS upgrade from a
>>> running pfSense.
>>> 
>>> Does AstLinux as well provide flashrom to do this job?
>> 
>> Hi Peter,
>> 
>> flashrom is a package for custom builds, but we don't include it in the standard builds.
>> 
>> If you want, I could build and create a flashrom-1.1.tar.gz for you to use. If yes, are you using the 64-bit genx86_64-serial image ?  Let me know.
>> 
>> But in general, if your BIOS is working it is usually best to leave as is.
>> 
>> Lonnie
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Upgrading Coreboot firmware of PC Engines APU with flashrom

[Michael K. <li...@mk...>]

Hi Lonnie,

Its long ago, but it can be that dmidecode is also needed.
Build it as well, just in case.

Sent from a mobile device.

Michael Keuter

> Am 28.03.2020 um 14:13 schrieb Lonnie Abelbeck <li...@lo...>:
> 
> 
> 
>> On Mar 28, 2020, at 7:05 AM, Dr. Peter Voigt <pv...@uo...> wrote:
>> 
>> My AstLinux machine is a PC Engines APU1 and I would like to upgrade
>> the strongly outdated Coreboot BIOS.
>> 
>> Usualy, under Linux and FreeBSD there is a flash program called
>> "flashrom" which can be used to flash the BIOS from the running
>> Operating system (Linux or FreeBSD). E.g. for Debian and FreeBSD package
>> information is available here:
>> https://packages.debian.org/buster/flashrom
>> https://www.freshports.org/sysutils/flashrom/
>> 
>> Almost three years ago I successfully did the BIOS upgrade from a
>> running pfSense.
>> 
>> Does AstLinux as well provide flashrom to do this job?
> 
> Hi Peter,
> 
> flashrom is a package for custom builds, but we don't include it in the standard builds.
> 
> If you want, I could build and create a flashrom-1.1.tar.gz for you to use. If yes, are you using the 64-bit genx86_64-serial image ?  Let me know.
> 
> But in general, if your BIOS is working it is usually best to leave as is.
> 
> Lonnie
> 
> 
> 
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Upgrading Coreboot firmware of PC Engines APU with flashrom

[Lonnie A. <li...@lo...>]

> On Mar 28, 2020, at 7:05 AM, Dr. Peter Voigt <pv...@uo...> wrote:
> 
> My AstLinux machine is a PC Engines APU1 and I would like to upgrade
> the strongly outdated Coreboot BIOS.
> 
> Usualy, under Linux and FreeBSD there is a flash program called
> "flashrom" which can be used to flash the BIOS from the running
> Operating system (Linux or FreeBSD). E.g. for Debian and FreeBSD package
> information is available here:
> https://packages.debian.org/buster/flashrom
> https://www.freshports.org/sysutils/flashrom/
> 
> Almost three years ago I successfully did the BIOS upgrade from a
> running pfSense.
> 
> Does AstLinux as well provide flashrom to do this job?

Hi Peter,

flashrom is a package for custom builds, but we don't include it in the standard builds.

If you want, I could build and create a flashrom-1.1.tar.gz for you to use. If yes, are you using the 64-bit genx86_64-serial image ?  Let me know.

But in general, if your BIOS is working it is usually best to leave as is.

Lonnie