apache2.tcz error while loading shared libraries: libpcre.so.0

[MikeLevin]

Hi everyone. I'm relatively new to Micro Core Linux. Here's my QEMU string:

./qemu -kernel bzImage -initrd microcore.gz -L ./ -hda hd.qcow -redir tcp:8080::80 -append "quiet waitusb=5 tce=hda1 home=hda1 opt=hda1 local=hda1"

Runs perfectly. I can fetch and run Apache2 with:

tce-load -wi apache2.tcz

And then I can start it with:

sudo apachectl -k start

But after a reboot, the same command to start apache results in the error:

/usr/local/apache2/bin/httpd: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory.

I looked at the apache2.tcz.dep file, which contains:

apr-util.tcz
openssel-0.9.8.tcz
pcre.tcz

I take it that the pcre.tcz is the requirement that the error is referring to, but I try:

tce-run pcre.tcz

Doesn't change things.

So, I try re-loading it

tce-load -wi pcre.tcz

...and it says pcre is already installed!

Any advice? Be gentle. I'm new to Micro Core and pretty new to Linux.  Here's the background on what I'm doing http://forum.tinycorelinux.net/index.php/topic,11258.0.html

[robc]

did you try running `sudo ldconfig` to see if the library issue clears up?

[gerald_clark]

You have "tce=hda1 home=hda1 opt=hda1 local=hda1"
Did you modify your /opt/.filetool.lst acordingly?
http://wiki.tinycorelinux.net/wiki:persistent_home

[MikeLevin]

I tried just about everything I could based on the above two pieces of advice, and still no luck. From searching through the forum, I believe I am encountering problems that may exist in hybrid mode, of things not being set up to be PPI-compatible.

I've deleted the contents of /opt/.filetool.lst so that backup doesn't occur.

I've scoured the forums. Am I in unexplored territory, using Micro Core Linux in scatter mode under QEMU to make quick-boot VM appliances?

[gerald_clark]

That's why scatter mode is unsupported.

[robc]

I tried just about everything I could based on the above two pieces of advice, and still no luck. From searching through the forum, I believe I am encountering problems that may exist in hybrid mode, of things not being set up to be PPI-compatible.

I've deleted the contents of /opt/.filetool.lst so that backup doesn't occur.

I've scoured the forums. Am I in unexplored territory, using Micro Core Linux in scatter mode under QEMU to make quick-boot VM appliances?

Were the extensions copied into the filesystem (ie copy2fs flag set) or were they ln cped (default extension install)? What does `ls -l /usr/local/lib/libpcre*` output?

[maro]

Well, it might not be "scatter mode" what MikeLevin is using. As that would require that the intrd has been extracted to a file system like 'hda1', and would also necessitate a matching boot code like 'root=/dev/hda1'.

Having said that, I'm pretty sure that using "hybrid mode" (i.e. boot code 'local=hda1') is the cause of the problem. And whilst "scatter mode" is widely frowned upon I suspect that "hybrid mode" is also not much "loved". I reckon it does not receive nowadays much attention and therefore little to no regular or targeted testing is happening. My impression is that it stems from a time when there was a choice between '.tce' (i.e. gzip-ed tar-archives) and '.tcz' style extensions. The former have disappeared quite a while ago. I somewhat harbour the view that boot code 'local=...' only makes sense when combined with the "copy2fs" option of 'tce-load' (e.g. tce-load -wic apache2).

So back to the immediate problem: the reported observations are a consequence of the fact that 'tce-load' checks for the existence of extension flag files '/usr/local/tce.installed'. If a non-zero length file exist in this directory it will serve as an extension startup script. With boot code 'local=...' these files are now persistent and all dependencies of 'apache2.tcz' are therefore deemed to be "already installed" (even though they are indeed not any more).

What to do about this? Well, the simple (an IMHO highly recommended) "solution"would be to NOT use the 'local=hda1' boot code. In my re-test of the scenario it solved the problem quite nicely.

An alternative approach (albeit not re-tested by me today) would be to use the "copy2fs" option. This way not only the files in '/usr/local/tce.installed' but all other files of the extensions in '/usr/local' would be persistent. BUT as soon as one of the extensions contains files outside of '/usr/local' (e.g. in '/usr/lib') those files would become MIA after a reboot. A very superficial check indicated that for 'apache2.tcz' (and it's dependencies) this approach might work, but this is not certain to remain so in the future. So for the "price" of not having an elegant method to update extensions when a new version becomes available, combined with the risk that as soon as something breaks you'll be on your own I would strongly advise to not go down this road.

Finally, as a totally unrelated observation I'd like to state that for an emulated system the 'waitusb=...' boot code is not required. It is a absolute necessity when using external storage devices (e.g. USB hard disks or pendrives) on "real" hardware, but for a VM it can be ignored. Unless of course when passing trough a "real" physical device to the VM, but that is not the case in this example here.

[MikeLevin]

Well, to put it Apache terminology:

It works!

The -wic parameters did the trick. Thanks.

Let me spell out a little more about what I'm trying to do and get your advice. I'm open to different approaches.

I'm building a Web appliance that you run seconds after a download or popping in a USB drive, which will inevitably be shut-down by a lot of people by clicking on the close gadget. Yep, it's bad practice, but no, I won't be able to stop them. So naturally, I am drawn to the involatile fresh system every time reboot. I think that there will be considerable appeal to this VM due to the neat trick of the same VM booting on Linux, Windows or Mac desktop with no install or admin rights, and the service it will provide.

After the apps are initially installed on this VM, there does not really need to be persistence on the VM between reboots. By that I mean, the VM can reset to the initial state it was distributed in, with pre-installed apps. But there will be a lot of configuration originally, such as an app in Apache cgi-bin. Additionally, the contents of cgi-bin will be updated from a code revision control repository on every reboot. This COULD persist between VM boots if the advantage is great enough (cutting down bandwith usage), but I'm willing to live with it either way. It depends on what is of greater value: incorruptibility or cutting down bandwidth usage. It's not a very large app.

I'll also be installing a bunch of API libraries that will have to be updated time-to-time, and will face the same issues. But when that happens, I can just tell people to download the new VM, since it is so small.

Is this all making sense?

Also, I am not particularly married to the tce system, even though I understand it is one of the big advantages of this platform. But it seems that I may just want to use tce to get the gcc common build stuff, then do the installs that way in those cases where there's not an extension (like mod_python for Apache). Once the original hda1 is set up, I can always restore it from a backup file.

Thoughts? Advice from the gurus?

[MikeLevin]

Hi everyone. It's been ages since this message thread. I was interested in the mod_python on TCL issue again and googled it, and saw my name... ha ha!

Anyway, I have finally released the first beta of my runs-anywhere/no install QEMU based on micro core. I haven't updated to the latest of everything in order to keep boot times fast, and frankly because everything is working so well. But I'm just about ready to try building my bash script "recipe" for an Apache2 / mod_python, vim / mercurial (for development) platform.

If a single distro file that will run as a virtual machine on the desktop of Windows (XP/7), Mac OSX (10.6.8 / 10.8.x), Ubuntu, Fedora, or OpenSUSE interests you, then check out http://mikelev.in/levinux/