Downgraded from 64-bit to 32-bit with an update?
-
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.
-
I checked all of the libiconv files in the amd64 folder on the packages server, and they were all 64-bit.
-
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.
-
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,1And since libiconv-1.13.1_1.tbz exists under http://files.pfsense.org/packages/amd64/8/All/ - that is the one it will take.
-
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
-
-
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 strippeddarkstat 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.
-
The darkstat issue is probably separate, Avahi is probably the real problem there.
-
Ah ok. Should I report a bug or would this forum posting be enough to give it acknowledgment?
-
A bug report on http://redmine.pfsense.org/ would be a good idea so it doesn't get lost.
-
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. ;)
