IMPORTANT: Packages that should be unlisted for amd64 installations…



  • Hi,

    I started the arduous task of testing each one of the packages to see which one(s) is/are the culprits of the disabled system issue I have been describing elsewhere around here.

    But so far, the top most dangerous package to install is Avahi. After installing Avahi, the command

    file /usr/local/lib/* | grep 32
    

    yields this output:

    libavahi-common.so.3:      ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    libavahi-core.so.6:        ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    libdaemon.so.0:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    libdbus-1.so.3:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    libexpat.so.6:             ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    libiconv.so.3:             ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    libintl.so.8:              ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    
    

    To make matters worse, even after immediately uninstalling the package, and then upgrading to a new snapshot of pfSense (to ensure critical libraries like libiconv.so.3 are being reinstalled as amd64), the command still yields this:

    /usr/local/lib/libavahi-common.so.3:      ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libavahi-core.so.6:        ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libdaemon.so.0:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libdbus-1.so.3:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libintl.so.8:              ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    
    

    In other words, the package not only installs garbage 32-bit libraries, even for libraries that already have 64-bit versions installed and replacing these, it doesn't even uninstall properly and leaves who-knows-how-much crap behind. In other words, a single attempt at installing Avahi will likely force you to reinstall the entire system!

    Further trying to install the ntop package results in this:

    librrd_th.so.2:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    
    

    of which also a 64-bit version should be installed, rather than a 32-bit version.

    Lastly the vnstat2 package is entirely 32-bit, hence also has no business showing up in the available package list for the amd64 version of pfSense until it's properly recompiled and reconfigured.

    More to come as I test further packages for their installation sins…



  • These packages install 32-bit binaries and libraries:
    Avahi
    FreeSWITCH
    FreeSWITCH Dev
    ntop
    vnstat2

    Of these Avahi is an absolute show stopper, because it installs a 32-bit version of libiconv.3.so which will essentially render the system unusable upon reboot.

    Avahi should be removed from the list of available packages until this is fixed.

    Neither Avahi nor any of the FreeSWITCH packages clean up properly after themselves, i.e. a deinstall will at least a good portion of their libraries installed. I had no chance to test if any of the FreeSWITCH versions with their 32-bit libs and binaries actually work in the amd64 version of pfSense, but at least superficially they don't cripple the entire installation.

    ntop seems to clean up after itself, at least as far as the 32-bit stuff in /usr/local/lib is concerned.

    After installing all packages, and then deinstalling all the 32-bit brood, I'm still left with these in /usr/local/lib, and none of these were present (at least in a 32-bit form), before the test started:

    file /usr/local/lib/* | grep 32
    /usr/local/lib/libavahi-common.so.3:      ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libavahi-core.so.6:        ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libcurl.so.5:              ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libdaemon.so.0:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libdbus-1.so.3:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libform.so.5.7:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libformw.so.5.7:           ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libintl.so.8:              ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libmenu.so.5.7:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libmenuw.so.5.7:           ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libncurses.so.5.6:         ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libncurses.so.5.7:         ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libncursesw.so.5.7:        ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libodbc.so.1:              ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libogg.so.5:               ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libogg.so.5.3:             ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libpanel.so.5.7:           ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libpanelw.so.5.7:          ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libspandsp.so.1:           ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libspandsp.so.2:           ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libtinfo.so.5.6:           ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libtinfo.so.5.7:           ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libtinfow.so.5.7:          ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    /usr/local/lib/libvorbis.so.4:            ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
    
    


  • FreeSWITCH

    This one just bit me. I installed it yesterday then suddenly had a non-working firewall. I'm not 100% sure this was the root cause of the issue, but it's the only thing I can attribute it to. I've reinstalled the 32-bit version where I am going to remain for the forseeable future….



  • Thanks for sharing. The moderators should consider doing a sticky on what packages are screwed up in Pfsense 32 and 64 bit.

    Better yet, why include broken packages and make a mess for folks trying to upgrade?

    I've hosed a couple boxes to the "Welcome To Snapshot Land" Traktor Mix Theme Song  ;D



  • vnstat2 seems to have been fixed, it now installs amd64 packages…



  • I did some more testing. Since pfSense has the 32-bit compatibility librries installed, some 32-bit stuff should be workable, even though it's not ideal.

    FreeSwitch Dev at least does not seem to impede the system upgrade process. Neither does ntop or vnstat2.

    The real killer is Avahi, it's should be delisted until it's fixed.

    Further, squid3 should be delisted, too. It can't be deinstalled at all, and thus requires the entire system to be installed from scratch to have it removed.

    There might be issues with other packages, too, but I first need to get rid of squid3 before I can test that.



  • There is a sticky with package statuses at http://forum.pfsense.org/index.php/topic,22158.0.html

    This links to a Google Spreadsheet at http://spreadsheets.google.com/pub?key=tFSe4gIfr3P0Nr1uYLxCHdw&single=true&gid=0&output=html

    I have updated the spreadsheet with a column specifically for 64-bit packages and have copied over the info provided in this thread. If you want to update it, editing rights to the spreadsheet are managed by cbuchler; I emailed him for the access I have.



  • Given my recent experiences, it seems that stunnel has to be added to this list, too…


Locked