SOLVED piaf 20650 install not working

[RonRussell]

Good Morning Tom,
Happy to say the scratch install of PIAF3 following Ward's tutorial ( http://nerdvittles.com/?p=9526 ) worked fine.
Thanks and have a great day

 

[hecatae]

mine failed due to isomenu, using same nerdvittles tutorial, had to remove isomenu manually

 

[wardmundy]

mine failed due to isomenu, using same nerdvittles tutorial, had to remove isomenu manually

Is this the 20650 ISO or a fresh PIAF 3 install?? What options were chosen to cause the failure? Thanks.

 

[hecatae]

fresh piaf 3 install, 32bit from minimal centos 6.6 iso

piaf green, asterisk 11, freepbx 2.11

 

[howardsl2]

darmock wardmundy

It seems that due to today's repository cleanup (piaf6-64 --> piaf6-64.old, piaf6 --> piaf6.old, etc.), there are now errors during a fresh PIAF3 install:

--2015-04-10 20:49:26--  http://www.pbxinaflash.org/piaf6-64/files/patch174.tgz
Resolving www.pbxinaflash.org... 74.86.213.25
Connecting to www.pbxinaflash.org|74.86.213.25|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-04-10 20:49:26 ERROR 404: Not Found.
 
update-fixes - 2.4.0 released on 020215
Download of patch174.tgz FAILED - WRITE THIS DOWN!

Another bug I've found, is when installing PIAF3 on 32-bit CentOS, the "isomenu" is an 64-bit executable and therefore cannot run on 32-bit:

*******************************************************
* Please make a selection A, B or C only!            *
* A = Continue with the installation of our products  *
* B = Load extra drivers for your hardware            *
* C = Command Line Interface                          *
*******************************************************
You have chosen to install one of our products
/usr/local/sbin/newmenu: line 14: /usr/local/sbin/isomenu: cannot execute binary file
 
root@piaf32:~ $ file /usr/local/sbin/isomenu
/usr/local/sbin/isomenu: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
 
The following file is 32-bit, however it is not used:
 
root@piaf32:~ $ file /usr/local/sbin/isomenu.org
/usr/local/sbin/isomenu.org: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

 

[darmock]

interesting. I will attempt to duplicate this one.......weird

Tom

 

[darmock]

I have regenerated the entire repo from scratch and verified that the isomenu is either 32 bit for 32 bit installs or 64 bit for 64 bit installs. I did thing by installing the raw rpm file onto a BARE centos 6.6 machine 32/64 bit and checked the results. so far so good. I am just reuploading the ENTIRE repo yet again and will test it by downloading it directly from the repo to ensure either 32 or 64 bit isomenu is in the correct rpm.

Other bugs like the renaming of some of the elderly repos to .old can safely be ignored until I can red some more of the ancillary programs. which I cam working on now. Can hardly wait till I can get back to piaf4 and move forward

Tom

 

[howardsl2]

Thanks Tom. By the way, that 404 error I mentioned was encountered during the "update-fixes" process of a fresh PIAF3 install, on both 32 and 64-bit CentOS 6.6. It claims that my Internet is down and then exits without finishing.

 

[darmock]

Here you go

64 bit machine



yum install of 64 bit rpm



ISO MENU UNDER 64 bit




Beyond that it *DOES* work fine

Fixed the 6-64 error in update fixes and just uploading patches safely ignorable but fixed none the less.


Thanks for your bug report

 

[howardsl2]

EDIT: It seems that the program /usr/local/sbin/newparadigm.sh re-downloads isomenu, and before doing that it checks the $RUNNING variable to determine if it is 32-bit or 64-bit.

However, that variable is not set. Therefore it always downloads the 64-bit isomenu, even on 32-bit systems. Please check.

 

[darmock]

good catch that file is contained in the piafxtras rpm not the piafdl rpm

fixed reuploading repo. Will take about 30 minutes however rest of the mirrors won't be synced till morning. Tested and works now that the problem was fully delineated


Tom

 

[Michelle Dupuis]

Just FYI, the file patch174.tgz is still not found (as of tonight) during install...

 

[howardsl2]

Confirmed that patch174.tgz still has 404 error during install as of 11PM CDT on 4/11.

URLs missing on all mirrors:

http://www.pbxinaflash.org/piaf6-64/files/patch174.tgz
http://www.pbxinaflash.org/piaf6/files/patch174.tgz

Another error in the output that I just noticed is for sysadmin:

Resolving Dependencies
--> Running transaction check
---> Package incron.i686 0:0.5.9-2.el6.rf will be installed
---> Package php-5.3-zend-guard-loader.i686 0:5.5.0-5_el6 will be installed
---> Package sysadmin.noarch 0:2.7.0-202.shmz65.1.18 will be installed
--> Processing Dependency: apcupsd for package: sysadmin-2.7.0-202.shmz65.1.18.noarch
--> Finished Dependency Resolution
Error: Package: sysadmin-2.7.0-202.shmz65.1.18.noarch (piaf3)
           Requires: apcupsd
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Thanks for looking into these.

 

[darmock]

it takes up to 24 hours for the changes for patch 174 to be propagated into piaf space. sometimes longer on the weekend be patient notice my original message says "however rest of the mirrors won't be synced till morning". as for the sysadmin well that is another story. Will think on what to do.


Tom

 

[wardmundy]

Tom works nights. I work mornings. So sometimes it takes "a while" to get our work products in sync. All should be well by 11 a.m. EDT today (Sunday).

 

[darmock]

The apcupsd error required a little more thought. Basically we rolled our own rpms as there were problems with some of the versions commonly available. took a bit but they are in the piaf repo. HOWEVER it takes a significant amount of time to propagate throughout piaf space so

BE PATIENT!!!!

The lab is currently uploading the updated repo to the developer site and once uploaded and then verified that no transmission errors occurred it will be send replicating to piaf space. Thus when we update things you should​

​

ALWAYS ALLOW A MINIMUM OF 24 HOURS PRIOR TO TESTING AND REPORTING ERRORS WHEN UPDATES OCCUR!​

​

​

​

We appreciate bug reports! However in this instant gratification world PIAF moves slightly slower as we are not a commercial enterprise and have real lives outside of the project. For example the PIAF Lab will be down in it's entirety for the first 20 days of August as we are all going on vacation without cell phones or computers....... We work on this project between jobs, family obligations, and sleep (There is never enough of this!). Additions or updates to the base install of PIAF will be frozen July 1st and wont occur again till after August 21st in between work/family/sleep


Best regards to all


Tom

 

[howardsl2]

Thanks again Tom (and the PIAF Team) for your time and efforts. Will wait until next week to test.

 

[wardmundy]

hwdsl2 All should be fine now.

 

[darmock]

all should be well as ward says. give it a try although I am rapidly running out of daylight (read weekend)


Tom

 

[howardsl2]

Just tried a new PIAF3 install on CentOS and everything seems to work, except for the "/usr/local/sbin/isomenu: cannot execute binary file" error on 32-bit.

Quoting my previous comment: "It seems that the program /usr/local/sbin/newparadigm.sh re-downloads isomenu, and before doing that it checks the $RUNNING variable to determine if it is 32-bit or 64-bit. However, that variable is not set. Therefore it always downloads the 64-bit isomenu, even on 32-bit systems. This causes the error mentioned above."