Porteus

@Cyril

And speaking of the characters in 1251 encoding, they are displayed in PCManFM in PuppyRus correctly.

just checked and puppyrus from your link uses "ru_RU.UTF-8" encoding and not cp1251.

regarding non-removable disks in pcmanfm panel:
according to official LXDE blog
http://blog.lxde.org/?p=768
it should be enough to set "show_internal_volumes=1" in ~/.config/libfm/libfm.conf.
this trick does work on my gentoo box but not in Porteus.
i have copied libfm and pcmanfm files from gentoo to porteus and pcmanfm still does not show internal volumes.
must be something else (udev version, settings?) but can't find it....
help is appreciated.

@fanthom

I tried time ago your method, show internal volumes = 1, the result is a lot of loop volumes.
Maybe this can help developers:
I boot Porteus v1.1 i486 into LXDE (toroot, no changes);
of course my internal hdd is not shown in PCManFM;
I open lxterminal and type these commands:

umount /dev/sdaX
mount /dev/sdaX

(where X is the number of the internal hdd, 2 in my case) and magically PCManFM shows correctly my internal hard drive. PCManFM shows all drives except the internal ones (SATA in my case with two different notebooks).
I hope this could help you

Regards

fanthom, I found these information:
Ponce blog
bugs.archlinux.org
desktop.lxde.pcmanfm

Cheers

@kalo86, Blaze
thanks guys - i have finally found the reason:
after setting "show_internal_volumes=1" in ~/.config/libfm/libfm.conf you must restart whole LXDE as restarting pcmanfm is not enough
libfm config must be re-read during startup and then all drives icons are shown.

I tried time ago your method, show internal volumes = 1, the result is a lot of loop volumes.

i should have a cure for this as well - must check first....

yes - it works but only for modules activated during boot. modules activated during lxde session as (probably) treaten as removable drives and still visible in pcmanfm. shouldnt be a big issue...

Cheers

fanthom, your advice work for me. Thank you.

Hi, I was having some issues running the new porteus on i-3 and faster processors. It could not mount devices like pendrive. Though it starts Trinity and logs in as guest, it was not starting dbus and hald and most of the applications including firefox would not run.

After two days of investigation, I found that the modules were not getting loaded properly. The issue is now solved after reconstructing the 001-core.xzm module with the modification of REMOVING all the & from the end of the rc.XX scripts (it increases booting time).

I am not sure if anyone has come across this issue. The fix solved 99.9% of the issues I had, I was regularly getting "KLauncher could not be reached via DCOP" message when running applications in Trinity. It now shows up only when I work as a user and run kdesu -c SOMETHING. Hope this helps someone.
Cheers,
-Sajeeth Philip

According to forum's rules, please add [SOLVED] to topic's title.

The & at end meant that the script will be run in background instead of frontground.

fanthom should be interested by this tweak.

Thanks sajeethphilip this is interesting.

I have had no problems on i5 or i7. Are you running from hard drive or a USB device? If more people report this we will need to look into it ... but i have not heard of it anywhere else.

Quite often when rebuilding a base module, i have needed to run a special dev script by fanthom that recreates cache files and rebuilds the 002-xorg module with the updates. This could also be the root of some of your errors regarding Klauncher and DCOP. When you say 'new' i assume you are talking about v1.1-final.

@sajeethphilip
when you go through original rc.M you will see that rc.inet1, rc.inet2, rc.messagebus (dbus), rc.hald (hal), rc.sysvinit and rc.local are not sent to the background and must be fully executed before booting moves on.
i'm not saying that this is not the root of your problems - it's just a little weird to me.

please do me a favor: use original 001-core.xzm on your PC and boot porteus with "autoexec=sleep~10" cheatcode. this should be enough for finishing all task from the background. let me know it that helps.

btw: i have created /usr/local/bin/kdesu script (included in 32bit release) which workarounds "DCOP errors". i can run "kdesu -c kate" without any troubles here.
please let me know what do you do to to reproduce "DCOP" error.

@brokenman
caches are ok.
"DCOP" issues comes from buggy 'kdesu' implementation in Trinity:
http://trinity-users.pearsoncomputing.net/?0::130
seems that it's being fixed in trunk:
http://web.archiveorange.com/archive/v/ ... qUD1WXyYE2

Cheers

Hi,

I was on road and could not check the posts earlier. I tried the original xzm and found that the problem returns.
1. Pendrive does not mount when i plug it in.

/etc/rc.d/rc.messagebus status says
dbus is stopped.

2. The DCOP message also returns if I do the following.

Log in as guest.
Everything works.
Use the run command (Alt-F2) and type kdesu -c konsole
Everything works
log out from guest
log in again
Trinity prompts you to give root password to run kdesu which was not exited when we logged out
Enter password, console returns.
Clicking on any application gives the message:
KLauncher could not be reached via DCOP

As I said, I am yet to make sure that this issue is specific to me. I give below the kdesu script in my machine.

#!/bin/sh

kinit(){
uid=`ps aux | grep kdesu_stub | grep -v grep | awk '{print$1}'`, x=1
while [ "$x" -le 60 -a "$uid" != "root" ]; do
sleep 1
uid=`ps aux | grep kdesu_stub | grep -v grep | awk '{print$1}'`
let x=x+1
done
sleep 3
kdeinit >/dev/null 2>&1
}

/usr/bin/kdesu $@ &
kinit


Mine is a Compaq Presario CQ62 i3 genuine intel laptop.

Cheers,

hello,

I tried the original xzm and found that the problem returns.

did you run it with "autoexec=sleep~10" cheatcode as advised in my previous post?
if yes then please do a very last test for me:
a) boot with original 001-core.xzm module into text mode with "autoexec=telinit~3;sleep~10" cheatcode
b) login to porteus and issue "/etc/rc.d/rc.messagebus status" command
if the output says that daemon is stopped then i'll remove all "&" from rc scripts in next release.
(wish this issue was discovered before 1.1 final)

The DCOP message also returns

seems that kde is ignoring $PATH variable and calls /usr/bin/kdesu direclty instead of /usr/local/bin/kdesu. here is a fix for that:
http://ponce.cc/porteus/i486/current/Po ... 6-1ftm.xzm
hopefully all DCOP errors will be resolved now

Thanks for bug report.

did you run it with "autoexec=sleep~10" cheatcode as advised in my previous post?

Sorry I forgot to tell you. When the sleep~10 cheat code was used, it was found that everything got mounted properly and message bus status showed running.

Cheers,

Posted after 1 hour 26 minutes 29 seconds:

Additional Information

1. Good news! The fix has worked! Now I do not get the error when I log back after running kdesu. But another issue is there. It was there earlier, but did not go with the fix. When i click netscape icon in guest after logging back, kde crashes and logs me out!! I am using the original xzm. After loging back again, it works fine, though.

2. I traced down that, strange enough, if I add the vlc-1.0.6 xzm module, even if I give sleep~10 cheat code, dmesg fails!

Error 1 persists even if the & is removed from the rc.M file contents. But that solved the issue with item 2.

Cheers,

Posted after 1 hour 2 minutes 16 seconds:

vlc module

In case it is useful, I have put the vlc module in my dropbox and here is the link:
http://dl.dropbox.com/u/44560890/vlc-1.0.6-1-all.xzm
Cheers,

When i click netscape icon in guest after logging back, kde crashes and logs me out!!

are you referring to Firefox icon? if yes then i can't recreate this error.

if I add the vlc-1.0.6 xzm module, even if I give sleep~10 cheat code, dmesg fails!

again - not sure what you mean by "dmesg fails". i have checked vlc module linked in your post and discovered that it contains a "killer dependency" which is glibc-solibs-2.9-i486-3. this package comes from Slackware-13.0:
http://slackfind.net/en/packages/search ... tversion=5
and should never be included in any porteus module as we are based on 13.37
please make sure that all your packages comes from Slackware-13.37 and not any other version.

just to be sure: did you check all your errors reported in this thread in porteus booted in "always fresh" mode with base modules only?
this requirement is set in FAQ answer 14:

How do I report a bug?
Try to recreate the bug first: boot Porteus in 'always fresh mode' with only the basic Porteus modules. If you are able to recreate the error, post a bug report on the Porteus forum in the relevant section.

maybe "stopped dbus" issue is caused by some bad quality (or outdated) modules placed in your /porteus/modules folder? - just guessing...

Thanks. I think that explains. I did all testing in fresh mode. But the problems showed up only when I installed it to my laptop that had some older modules that I was using. However, I still wonder how this error went away when I removed the & from rc,M contents, in which case /etc/rc.d/rc.messagebus status shows "dbus-daemon is running" (the opposite is what I meant when I saud dbus fails). I shall try upgrading all modules and check if everything works fine.
Cheers,

Posted after 20 minutes 42 seconds:

are you referring to Firefox icon? if yes then i can't recreate this error.

Did you try it after running kdesu?

Did you try it after running kdesu?

yes - and i can't recreate the error in any way when DCOP fix is activated.
please remove your additional modules and try then.