Downgraded from 64-bit to 32-bit with an update?
-
Somehow I'm still using the 64-bit pfSense, but after installing some packages, I noticed Bandwidthd would no longer start. I found out one of my SO files turned into a 32-bit version. I went around looking at other ones and suddenly, I found myself in a strange situation where quite a few SO files reverted to 32-bit versions. Is this because of the recent releases or because of a package issue? Is there any way to fix this without a reinstall?
I noticed the problem a few days back and haven't noticed it since, but probably because I haven't added any packages since. I just noticed certain programs I tried to run no longer working because of 32-bit SO files. I used ddl to discover this. I have been keeping up-to-date; hopefully this issue was resolved already. I'll find out when I do more command line trickery.
uname -a
FreeBSD neomain.octen 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #1: Wed Mar 16 21:05:14 EDT 2011
root@FreeBSD_8.0_pfSense_2.0-AMD64.snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 amd64 -
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.
-
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, widescreenHere are the packages I installed that night
Avahi, darkstat, UnboundI'm pretty sure I didn't install vnstat2 though.
-
/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 -
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. ;)
