Downgraded from 64-bit to 32-bit with an update?

jimp

Without knowing exactly what package you had installed that may have caused that, it's impossible to say what might have happened.

Up until a few days ago, vnstat was pulling i386 libraries on amd64 but that's been fixed, so if you use that (but you may not be since you use bandwidthd) it might explain a few things.

Saturn2888

Here's a list of what I installed. The two rows are separated by what I kept and what I removed.
Avahi, Bandwidthd, Cron, darkstat, iperf, OpenVPN Client Export Utility, Shellcmd
Unbound, Varnish, widescreen

Here are the packages I installed that night
Avahi, darkstat, Unbound

I'm pretty sure I didn't install vnstat2 though.

Saturn2888

/usr/local/lib/libiconv.so.3 <- After the newest update, this file, yet again, became 32-bit. It showed something like it was updating packages and to not touch the GUI. After it completed, that file reverted to a 32-bit version, not a 64-bit one and Bandwidthd was unable to start. I fixed this by copying it from a 7.3 64-bit machine I have, but that's not the ideal process. I'm sure one of the packages I do have installed is causing this, just need to know which one.

[2.0-RC1][root@localhost]/root(2): file /usr/local/lib/libiconv.so.3 /usr/local/bandwidthd/bandwidthd
/usr/local/lib/libiconv.so.3:     ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
/usr/local/bandwidthd/bandwidthd: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.1, stripped

Saturn2888

Is there any way to check the installers for the packagers to see what they extract or to make this file unable to be overwritten? I have a problem here because I couldn't even boot up today since some software package or update or update to a software package reinstalled the 32-bit version of /usr/local/lib/libiconv.so.3. This is the 3rd time it's happened and this time I couldn't even start pfSense or get and allocate IPs. Hopefully there's some way I can better look into this so it never happens again.

jimp

I checked all of the libiconv files in the amd64 folder on the packages server, and they were all 64-bit.

Saturn2888

@jimp:

I checked all of the libiconv files in the amd64 folder on the packages server, and they were all 64-bit.

Does that include the ones packages install? Does the pfSense server host those as well? It's specifically /usr/local/lib/libiconv.so.3.

jimp

If you install, for example, bandwidthd, it looks at:

http://files.pfsense.org/packages/amd64/8/All/bandwidthd-2.0.1_4.tbz

Any other files it needs will be pulled from the base URL of the package, namely:
http://files.pfsense.org/packages/amd64/8/All/

Such as:

$ pkg_info -r bandwidthd-2.0.1_4.tbz 
Information for bandwidthd-2.0.1_4.tbz:

Depends on:
Dependency: png-1.4.5
Dependency: jpeg-8_3
Dependency: pkg-config-0.25_1
Dependency: freetype2-2.4.4
Dependency: libiconv-1.13.1_1
Dependency: gd-2.0.35_7,1

And since libiconv-1.13.1_1.tbz exists under http://files.pfsense.org/packages/amd64/8/All/ - that is the one it will take.

Saturn2888

I wonder what's happening then. This is a new build as of a few weeks ago so it's not anything I did aside from installing packages. If it's not Bandwidthd, Is it Darkstat or any of the other services I installed?

Avahi
Bandwidthd
Cron
darkstat
iperf
OpenVPN Client Export Utility
Shellcmd

Saturn2888

I've got it. avahi and darkstat both modify this file which is why they will not start up now that the file has changed. I recommend checking both. After setting "chflags schg /usr/local/lib/libiconv.so.3", bandwidthd works normally, but avahi and darkstat no longer start.

[root]/root(16): ldd /usr/local/sbin/avahi-daemon
/usr/local/sbin/avahi-daemon:
        libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x280a2000)
        libavahi-core.so.6 => /usr/local/lib/libavahi-core.so.6 (0x280ad000)
        libdaemon.so.0 => /usr/local/lib/libdaemon.so.0 (0x280e0000)
        libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x280e5000)
        libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x28105000)
        libssp.so.0 => /usr/lib32/libssp.so.0 (0x28145000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28148000)
        libiconv.so.3 => not found (0x0)
        libthr.so.3 => /usr/lib32/libthr.so.3 (0x28151000)
        libc.so.7 => /usr/lib32/libc.so.7 (0x28166000)
        libiconv.so.3 => not found (0x0)
        libiconv.so.3 => not found (0x0)
        libiconv.so.3 => not found (0x0)

[root]/root(19): ldd /usr/local/sbin/darkstat
/usr/local/sbin/darkstat:
        libpcap.so.7 => /lib/libpcap.so.7 (0x800656000)
        libz.so.5 => /lib/libz.so.5 (0x800787000)
        libc.so.7 => /lib/libc.so.7 (0x80089c000)

[root]/root(18): file /usr/local/lib/libiconv.so.3
/usr/local/lib/libiconv.so.3: ELF 64-bit LSB shared object,
          x86-64, version 1 (FreeBSD), dynamically linked, not stripped

darkstat refuses to start as well. Going into darkstat's settings and clicking "Save", it starts up no problem. Something might've changed in its configuration file. This leaves avahi. Hitting "Save" on it didn't fix it. I'm assuming its the cause of the 32-bit SO file. What do you think? I don't know how to verify, but if you did, I think you'd notice that it's got a 32-bit libiconv.so.3.

jimp

The darkstat issue is probably separate, Avahi is probably the real problem there.

Saturn2888

Ah ok. Should I report a bug or would this forum posting be enough to give it acknowledgment?

jimp

A bug report on http://redmine.pfsense.org/ would be a good idea so it doesn't get lost.

Saturn2888

Hi jimp. I don't have a username there. Would you mind posting it for me? I've done the research and stuff but don't feel like making an account just to report a quick bug. ;)