LIBXML2_2.5.2 Required by /php not defined

[Roots0]

Running full install of i386 on a C3.

After changing MAC address of the WAN interface php stopped responding so i rebooted. Nothing. Loging into the shell gives the following error when i try anything but the shell:

/libexec/ld-elf.so.1: /usr/local/lib/libxml2.so.5: version LIBXML2_2.5.2 required by /usr/local/bin/php not defined

Anyway to fix without a reinstall, id like not to lose my settings and rrd data.

[eri--]

You probably removed a package.
The only way yo do that is restore libraries manually from an update file of from an iso.

[Roots0]

I was using Unbound DNS and rrd summary, I dint remove either though. Maybe I dint shut down correctly.

I dont see LIBXML on the cd is it a part of a package? If so why would it stop pfsese core from working?

[jimp]

libxml is on the CD, in the base system, etc. It's needed because pfSense stores its config in XML and XML is used in many places on the system.

What has happened previously, though some protections exist now, is that when you install a package, the package installs its own version of libxml, and then when you remove the package, it removes libxml, even though the base system still needs it.

[wagonza]

Neither Unbound nor RRD Summary install libxml as a dependancy. @Roots0 you positive you did not have any other packages installed that you removed?

[linch]

Hi All,

I would like to mention that this error has appeared with our PFsense machines a couple of times.

the causes - package installation failure OR updating of a beta snapshot to a newer one…

We have always had to completely reinstall the PFsense to fix it (copying libraries from another pfsense have not helped)...

Latest issue - an update to Beta5 snapshot (from 8th of February) - the update reported in the UI - all was fine... however logging via SSH shows:

Using username "root".
/libexec/ld-elf.so.1: /usr/local/lib/libxml2.so.5: version LIBXML2_2.5.2 required by /usr/local/bin/php not defined

however the libxml library is there:
[2.0-BETA5][root@xxxxxx.xxxxxx]/root(3): ls -l /usr/local/lib/libxml2.so.5
-rwxr-xr-x  1 root  wheel  1495704 Aug  4  2010 /usr/local/lib/libxml2.so.5

Its size matches the one from another server (freshly installed with the same beta version).

Currently, the machine runs fine - but if we reboot it - we will be the complete reinstall situation (as it is stated int he beginning of the thread  :o)…

If you need some info about the machine that may help in an investigation - shoot (before someone decides to reboot it :))

-Kalin

[jimp]

It still must be related to packages in some way, and even then only certain ones. I've been upgrading tons of VMs and other systems and have yet to see anything of the sort.

[linch]

the current packages list is empty:

[2.0-BETA5][root@xxxxx.xxxxxx]/root(4): pkg_version -v
packages                            ?  orphaned: sysutils/bsdinstaller
[2.0-BETA5][root@xxxxx.xxxxxx]/root(5):

Before the beta snapshot update there was the "arpwatch" package installed… the oldest config.xml in the /cf/conf/backup/ folder has this info:

<revision><time>1297180948</time>

<username>admin</username></revision>

the backup .xml file has time stamp of the time around our beta update…

Is the update process deinstalling packages?

[wvnet]

Just got hit by this - noticed it's removing/reinstalling packages every time I upgrade.  This time I saw it kick an error as it was going through the process, on the openvpn client export package, I think.
Rebooted, and that was that.  LIBXML error, stick at the command line.  Any fixes?  I've got a generated OpenVPN certstore in there, and exported clients out on several user laptops that I'd rather not reinstall…

[jimp]

the openvpn client export package has no libraries that it pulls in like that, so it wouldn't be the source of the problem.

The usual culprits are snort or squid.

[wvnet]

:)
Well at least a restore is relatively painless, even if you hadn't backed
up your config.xml, like I hadn't…
Since shell is accessible, I formatted & mounted a USB key,
copied over config.xml from /CONF, moved it to a laptop,
then wiped and reinstalled.
Booted the fresh install, chose 'restore' in the diagnostics section of the GUI,
selected the config.xml from laptop, and it's all back to rights.

Thanks for the quick reply btw.

[linch]

so, we see at least 5 different packages that are killing the upgrades… and the only cure is reinstall?...

It looks like there is something in common - that is crashing the upgrades... the package system control or something (just shooting in the dark  ???)?

-Kalin

[jimp]

Well the way packages are reinstalled now, the key libraries are backed up before the packages are reinstalled, and restored afterward.

I haven't seen anyone who would reproduce it 100% every time with the current code.