[Solved]Problem startup activation of modules Port. 2.0 64

[Payoon]

Hi folks,
don't know this is the right place to post, because I don't know the fault is on my side or not.

I think there is something with the startup activation in Porteus 2.0 64bit. I created a module for emelfm2 ( excellent two pane file manager), which has two dependencies (libhal and libhalstorage, both provided by the package libhal).

So I made two modules from packages downloaded from Slackware 13.37 (emelfm2-0.8.0-x86_64-2sl.txz and hal-0.5.14-x86_64-3.txz): emelfm2-0.8.0-x86_64-2sl.xzm and hal-0.5.14-x86_64-3.xzm, activated them and the filemanager worked fine.
I moved them to /porteus/modules and rebooted, but after reboot emelfm2 didn't work, because it was missing libhal.so.1 and libhalstorage.so.1 although they were embedded in the hal module.
I checked in /porteus/modules: both modules (emelfm2 and hal) were activated. I deactivated and activated again: emelfm2 works fine.
Reboot: emelfm2 doesn't work, because of missing libhal.so.1 and libhalstorage.so.1.
I have tried this with debian packages also. With the same result.
I also merged the two modules, but the problem persists.

When examining the /usr/lib64 directory I found, that after reboot some symlinks were missing.For example:


After manual deactivation and reactivation:
libhal.la exists
libhal.so symlink to libhal.so.1.0.0 exists
libhal.so.1 symlink to libhal.so.1.0.0 exist
libhal.so.1.0.0 exists

Filemanager works fine.

After reboot:
libhal.la exists
libhal.so symlink to libhal.so.1.0.0 exists
libhal.so.1 symlink to libhal.so.1.0.0 NOT EXISTS !! And this is the one emelfm2 asks for when trying to start for commandline.
libhal.so.1.0.0 exists

Same thing for libhalstorage

After deactivate and then reactivate I could see them again.
I have done exactly the same in porteus 2.0 32bit and there both modules (32bit ones) work flawless, also after reboot.

That's all what a layman could find out.

Has anyone an explanation?

Thanks in advance.
Payoon

[fanthom]

hello Payoon,

'ldconfig' is a command which creates shared lib cache and rebuilds missing symlinks. it runs during module activation but not during Porteus startup. 2 reasons for that:
a) i assume that modules are created correctly and have all symlinks in place (this is the case for all modules from official porteus repo).
b) ldconfig slows down boot time by few seconds (depends on number of extra modules)

just checked on my PC and after conversion hal module has all symlinks in place.
please check /mnt/live/memory/images/hal-0.5.14-x86_64-3.xzm/usr/lib64 to confirm that it's also the case on your side.

if yes then you must be saving changes and probably deleted symlinks manually. if this is the case then please copy missing symlinks from /mnt/live/memory/images/hal-0.5.14-x86_64-3.xzm/usr/lib64 to /usr/lib64 (this action will remove relevant whiteout files from aufs writable branch and everything will be ok)

btw: if working with many modules coming from unknown repos (bad quality) you could add a 'ldconfig' command to /etc/rc.d/rc.local file to not bother with fixing symlinks manually.

EDIT:\\
bear in mind that your module should be created with txz2xzm command or through right mouse click in file manager.
unpacking through the archivers is not acceptable (and could be the reason of missing symlinks).

[Payoon]

I'll try my best and give further notice.
Thanks a lot.
payoon

[Payoon]

Hello fanthom,
you were right after I added ldconfig to rc.local everything is OK.
Thank You for helping me again.

Payoon