Porteus

Please , Do not say this :

i am mistaken.

Because , you are a great contributor , and with your error , now , we know , the LLS by fanthom is not compatible with UnionFS Patch.

Maybe , fanthom will found a solution for this.

We are a community , and maybe , one day , we will in Top 10 of the Best Distro.

Hamza wrote:Please , Do not say this :

i am mistaken.

We are a community , and maybe , one day , we will in Top 10 of the Best Distro.

For what I can say, the open and democratic way things are handled with Porteus so far gives us for a quite new distro a good head start in that direction, and I think we all agree that we want to keep it that way...

Ups, off topic.

@beny
unfortunately that's the same patch which i tried before. does not compile at all.

@Hamza
according to skyhog99 post on slax forum:
http://www.slax.org/forum.php?action=vi ... ntID=70101
LLS can be easily transformed from aufs to unionfs.
as mentioned above - i couldn't check it as compilation failed

currently i'm fighting with aufs and 2.6.38 kernel. got few tips from Junjiro and making some tests. while in Porteus-v1.0, following test freezes PC: *.img is a compressed ext2 filesystem and code above does the same jab as activation/deactivation of xzm modules.
This test freezes Porteus-1.0 and passes in Porteus-v09.
One would say: it's a kernel fault
not really
i have used Porteus 1.0 kernel with my gentoo box and this test passes too. Looks like it doesn't work only while in live mode.
need to dig more into this....

Damn .. that's a little disturbing.

hi brokenman i can post a console screen that i have made from activate deactivate in e 17 wm? in e17 no hang

Posted after 2 minutes 38 seconds:
bash-4.1# cd /mnt/live/mnt/sde1/porteus/base/
bash-4.1# deactivate /mnt/live/mnt/sde1/porteus/base/005-kdeapps.xzm
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
Updating MIME database: /usr/bin/update-mime-database /usr/share/mime &
bash-4.1# deactivate /mnt/live/mnt/sde1/porteus/base/004-kde.xzm
bash-4.1# activate /mnt/live/mnt/sde1/porteus/base/005-kdeapps.xzm
Updating shared library links: /sbin/ldconfig &
/usr/bin/activate: line 131: syntax error near unexpected token `fi'
/usr/bin/activate: line 131: ` fi'
bash-4.1# activate /mnt/live/mnt/sde1/porteus/base/004-kde.xzm
Module is already activated. Deactivate? Answer y/n
n
bash-4.1# deactivate /mnt/live/mnt/sde1/porteus/base/005-kdeapps.xzm
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
rm: cannot remove `/usr/share/applications/qmmp.desktop': No such file or directory
rm: cannot remove `qmmp_cue.desktop': No such file or directory
rm: cannot remove `qmmp_enqueue.desktop': No such file or directory
rm: cannot remove `smplayer.desktop': No such file or directory
rm: cannot remove `smplayer_enqueue.desktop': No such file or directory
Updating MIME database: /usr/bin/update-mime-database /usr/share/mime &
bash-4.1#
e17 follow to work regular

E17 .. you mean enlightment desktop?

We need to get this working from both console and GUI (double click on module). I don't think it is KDE causing this as i have experienced the same thing while using 'installpkg' from lxde. I guess we should all really concentrate on this and crack it. It is looking like it is not aufs, and if it is junjiro is not focused on it.

Are you saying you don't experience this while using E17 with porteus?

What would be the easiest way to repeat that test on other machines?

Or do you think that is not necessary?

Still it could be that the freeze not happens on all x86_64 systems...

...

At least.... when we got a fix to that issue we can create the Service Pack 2... *tries to see the light at the end of the tunnel*

but deactivate isn't in right click menu only activate,how can i deactivate module from gui in porteus64,and why console tell me that module are activated if not...

Posted after 3 minutes 12 seconds:
the console screen, show how i have done test in e17 and at final system running regular.

beny wrote:but deactivate isn't in right click menu only activate,how can i deactivate module from gui in porteus64,and why console tell me that module are activated if not...

When I am not root... how can I activate or deactivate anyway?
At least that not worked with V08...
(unless I start konqueror from a root shell, but that's not really plain GUI since I could also run activate and deactivate in the same root shell...)

Trying to set up x86_64 1.0 beta on an USB pendrive running Slax 6.1.2

I hope I not get the issue that the mbr writing script not runs when started by a non 64 bit system... at least I read about that issue on here somewhere...

i think with console,but i am not shure,

beny wrote:i think with console,but i am not shure,

It does work with rootshell -> starting konqueror AND using a rootshell and activate/deactivate, but like I said: that's not really GUI.

We need that fixed for the final release so that the user (aka "guest") needs to give the root password so that he can use the GUI menu entries...
___________________________________________________

About setting up Porteus-v1.0-beta-x86_64 from a Slax 6.1.2 system: Nope sadly not working I get the same error that I read about in here as it seems: Is there already a working fix for 1.0 beta x86_64 for that error?
sdc1 is the pendrive I wanted to put Porteus-v1.0-beta-x86_64 on and sdb1 is the pendrive with Slax 6.1.2 that runs the current host system...

how can i deactivate module from gui in porteus64

Double click on it. If it is already activated, the activate script will switch to deactivate.
Perhaps a right click menu item should be added to deactivate, just to make things easier.

When I am not root... how can I activate or deactivate anyway?

From console i think activate script asks for root password.

I'm afraid if you are booted into a 32bit environment, you won't be able to work with 64bit binary.

currently i'm fighting with aufs and 2.6.38 kernel. got few tips from Junjiro and making some tests.

Fanthom while testing in 32bit i found i can activate/deactivate and installpkg as much as i like without problem until i run into a large module that contains an ld.so.* file, whereupon it hangs. I was using 'for a in *.xzm; do activate $a; done` and same for installpkg. For me the large module was Virtualbox. I can't help thinking that this problem comes back to ldconfig and ld.so files. Can someone else test the theory?

I can just about guarantee a freeze after i have been using vbox for a while and then hammer installpkg or activate/deactivate.

with double click on modules everything goes well,no hang on lxde,in e17 i can't try because dolphin is active and module refuse to deactivate,but i have change kernel
Linux porteus 2.6.38-porteus #1 ZEN SMP PREEMPT Fri Apr 1 20:54:01 UTC 2011 x86_64 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
but i don't think that are important.

@all
no point for waisting you time on testing aufs issue. It's there for sure and only Junjiro can fix it.
i have figured out that above test (also activaton/deactivation of a modules) is passing when i'm in text/console mode and fails while in GUI.
form my point of view aufs fails when some processes have an access to files/folders which are added/removed from live filesystem.

here is a photo of a kernel panic which occurs when you add ro branch (a sandbox module) with *.desktop file in /usr/share/applications and then run 'kbuildsycoca4' KDE-4 utility which refresh KDE menu with new icons.
this error is always reproducible here.

http://img232.imageshack.us/img232/8699/oopsz.jpg

@Rava
the only solution is to compile static lilo and syslinux. unfortunately lilo itself is 700KB big while compiled statically.... didn't check syslinux/extlinux yet.
32bits are also affected as you wont be able to run 32bit lilo in pure 64bit environment (no multilib).

brokenman wrote:Double click on it. If it is already activated, the activate script will switch to deactivate.
Perhaps a right click menu item should be added to deactivate, just to make things easier.

I mean GUI as in: LXDE without any KDE stuff.
At least in the V08 there was no links made for usability of the modules with the default file brower of LXDE

I again run Slax 6.1.2 so I cannot give you the actual heads up on 1.0 beta with all KDE stuff removed....

Yes, I really should set up virtual machines for all SLAX and Porteus'ses I run at times so that I can at least run Porteus 1.0 beta (64 bit) at least on all native OS...

When I am not root... how can I activate or deactivate anyway?

From console i think activate script asks for root password.[/quote]
I cannot remember what it did with 1.0 beta, but the V08 one just gave an error message "you need to be root" (see above also for my issues not running the most current Porteus at times)

I'm afraid if you are booted into a 32bit environment, you won't be able to work with 64bit binary.

Sadly, yes. I needed to fire up a 64 Bit Porteus on another machine to initialize the USB pendrive...

______________________________

fanthom wrote:the only solution is to compile static lilo and syslinux. unfortunately lilo itself is 700KB big while compiled statically.... didn't check syslinux/extlinux yet.
32bits are also affected as you wont be able to run 32bit lilo in pure 64bit environment (no multilib).

If such lilo and syslinux is only needed for initialising the USB stick and not put on it like that it would be okay, since when running the stick the non-staically linked smaller version would again run since then it's a 64 bit system...

But I presume it would not work like that. Or would it?