Porteus-v1.0-rc2-x86 "So close to the FINAL..."

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
Falcony
Full of knowledge
Full of knowledge
Posts: 235
Joined: 01 Jan 2011, 12:44
Location: Russia

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#61 by Falcony » 08 Jun 2011, 07:59

Thanks, guys!

I supporse it is just I have several installation - on USB, HDD.

Try to load on PC without any other porteus installation

roadie
Full of knowledge
Full of knowledge
Posts: 205
Joined: 02 Jan 2011, 18:41
Distribution: Porteus 3.5...with a twist
Location: In a hayfield

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#62 by roadie » 08 Jun 2011, 15:41

I have some strange activity happening with rc2, running a frugal install and Always Fresh.

It seems to be centered around the QT-4.7.0 and VLC-1.1.9.xzm's, although it's happening with others as well. The problem comes when deactivating modules, I can select a module and deactivate it and all's well.

If I select more than one module, plus QT or VLC mods, it deactivates them fine..........problem is, first, it deactivates 001-core.xzm.

It runs through the process, tells me it's deactivating previously deactivated modules, 001-core is always first, then it dies, as it would with the core gone. It drops to a black screen, nothing works, no commands, only thing left is to give it a quick death. Would be great to have a console at least to see what in hell is going on, but, no joy there.

I'm using Porteus Module Tools for activation and Porteus Module Manger for deactivation........it did the same with xdeactivate.........no, 001-core is never checked to be deactivated.

Maybe someone else can try to duplicate it?

Also, there's a dead symlink in /mnt/live/memory/changes/lib..........libcap.so.2 > libcap.so.2.20.........from what I saw it's tied in with Kde............libcap.so.2.19

If I'm in the wrong place for posting, by all means, kick it to wherever it should be.

roadie

User avatar
Hamza
Warlord
Warlord
Posts: 1847
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#63 by Hamza » 08 Jun 2011, 16:03

Welcome Back!

If your issue is about Porteus v1.0 rc2 x86 (32-bit) version.
You're in the right place,
otherwise, please move this post to relevant thread.

Thank you for report this bug.
NjVFQzY2Rg==

roadie
Full of knowledge
Full of knowledge
Posts: 205
Joined: 02 Jan 2011, 18:41
Distribution: Porteus 3.5...with a twist
Location: In a hayfield

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#64 by roadie » 08 Jun 2011, 16:40

Hamza,

See, that's the thing.........I'm not sure if the bug is in v1.0 rc2 x86 (32-bit) version or the modules............I did suspect the modules, but can't see any files in the modules that should cause that...........and, why would 001-core get deactivated anyway?

It seems strange that deactivation of any module should cause the deactivation of a base module.......I mean, the base is kinda important.......I want it kept in place..... :D

Maybe the forum needs another section for bugs like this........possibly called "Bugs in Limbo"?...... :)

Anyway, I'll keep pokin at it........maybe something will show.

roadie

User avatar
fanthom
Site Admin
Site Admin
Posts: 4617
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#65 by fanthom » 08 Jun 2011, 16:44

@roadie
fix is ready and i was hoping we release rc3 before anyone spot that :)
i have used 'rev' command instead of 'sort -r' and it causes all the troubles... (first modules were deactivated instead of last ones)
thanks for bug report :)
Please add [Solved] to your thread title if the solution was found.

roadie
Full of knowledge
Full of knowledge
Posts: 205
Joined: 02 Jan 2011, 18:41
Distribution: Porteus 3.5...with a twist
Location: In a hayfield

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#66 by roadie » 08 Jun 2011, 16:55

fanthom,

Thanks, thought I might be seeing things..........though, the voices are still there........ :D

roadie

User avatar
wread
Module Guard
Module Guard
Posts: 1092
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v3.2.5-kde5-64 bits
Location: Santo Domingo
Contact:

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#67 by wread » 08 Jun 2011, 22:29

@roadie
Which version of vlc 1.1.9 and of qt4.7 are you using? I posted a few days ago links to both modules made by myself. They work ok for me, the same by feng in China. I don't see why these wouldn't work for you in Canada.

Even this minute I deactivated qt.4.7 and the 001-core ist still there. No bug. Iḿ using 32 bits rc2. :roll:

Regards!
Last edited by wread on 20 Jun 2011, 01:26, edited 1 time in total.
Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

roadie
Full of knowledge
Full of knowledge
Posts: 205
Joined: 02 Jan 2011, 18:41
Distribution: Porteus 3.5...with a twist
Location: In a hayfield

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#68 by roadie » 09 Jun 2011, 00:59

wread,

I'm actually using your modules, but the problem doesn't lie with them.

By the way, very nice modules....... :)

roadie

User avatar
wread
Module Guard
Module Guard
Posts: 1092
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v3.2.5-kde5-64 bits
Location: Santo Domingo
Contact:

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#69 by wread » 10 Jun 2011, 02:07

@roadie
thanks for the compliment. BTW, what file system are you using? Coming from Slax, I always used xfs filesystem, but with Porteus and xfs I had bad luck, many crashes and weird things. Now I prefer ext3.

Sometimes we forget we need space on device for uncompressing modules. Deactivating a module with a device almost full, can cause strange things, like you are having. Try leaving out some big modules to see if it still happens.

Regards,

wread
Last edited by wread on 20 Jun 2011, 01:28, edited 1 time in total.
Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

User avatar
agreimann
Samurai
Samurai
Posts: 137
Joined: 19 Apr 2011, 21:09
Location: U.S.

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#70 by agreimann » 10 Jun 2011, 03:20

So close to the FINAL... I get excited thinking of that. :D

Keep up the fight against Windoze! :x

@wread: I noticed Porteus does not handle a vast array of filesystems in the same way Slax did. Porteus supports them, but not in booting off them with changes smoothly. I do believe you're right there about using ext filesystems.

User avatar
Hamza
Warlord
Warlord
Posts: 1847
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#71 by Hamza » 10 Jun 2011, 11:53

@wread,
If you have any issue with this development version. Please share it, maybe we can help you.
NjVFQzY2Rg==

zer0-G
White ninja
White ninja
Posts: 16
Joined: 08 Feb 2011, 20:37
Location: Texas

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#72 by zer0-G » 10 Jun 2011, 22:38

Hello,

I think I may have found a bug in rc2. psswd.xzm is not saving on both my frugal install to HDD and USB. In rc1 this worked fine though. I am using "from_dev=/dev/sda1 from_dir=/x/p32v10r2" in my boot configurations. I have noticed after I set new passwords that it reports to have saved to "/mnt/sda1//x/p32c10r2/porteus/modules". Maybe the double forward slash is the problem...

I am able to use the rc1 psswd.xzm in the interim.

Regards

User avatar
brokenman
Site Admin
Site Admin
Posts: 5574
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#73 by brokenman » 10 Jun 2011, 23:41

Thanks for the report. Will test it now. I think the double slash will resolve to the same address anyway.

Posted after 19 minutes 52 seconds:
Just tested on my USB drive partitioned with two partitions.

Part1 - FAT32 64Mb for boot folder
Part2 - ext3 3.5Gb for porteus folder

Had no troubles changing the password during boot, which worked once i was logged on. Where i did have a problem with this setup was with the md5sum check at the start. It runs from the Porteus folder, and looks for boot at ../ but obviously in this case it was on a different partition. The only people i can think that would setup their drives in this way are ex-slaxers with limited bootloaders ... but it still needs attention i think.

Anyway Zero-G i could not reproduce it.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
wread
Module Guard
Module Guard
Posts: 1092
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v3.2.5-kde5-64 bits
Location: Santo Domingo
Contact:

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#74 by wread » 10 Jun 2011, 23:52

@Hamza
Thanks for the help offering; I am a little unhappy with Porteus only because the 3D fonts of Google-Earth are not working properly. They do work ok in Slax. Starting with Slax-Remix the big fonts of GE are broken!

I thought first it was my module. The good working versions of slax didn't show the 3D fonts ok in Porteus; I made a module of version 6.0.1 and it happened the same. I even packaged it as lzm (the GE 6.0.1) for slax and it works ok! So my modules are ok and Porteus has a bug. Fanthom knows about it, and he is trying to solve it too.

Using lxde is the same. I thought the bug could be in Trinity KDE 3, so my last research was to take KDE3 out and see what happens with KDE4. Neither with KDE4 the fonts appear; it is always the same, empty boxes instead of characters. BTW I have the kde4 (32 bits) modules installed now; if you would like to test them, let me know, so I can post them for you (it is an old version, 4.2.1).

Now I have the bug pinpointed to the 002-xorg module. I tried to use the 002-xorg module form slax, but it won't work at all; they are different, not compatible. I mean what Thomas could make, our team should be able to accomplish too, isn't it so?

I'm sure the bug is there, because I'm having crashes of kwin, but the OS keeps working; the .xsession-error file says the crash is caused by missing fonts! Sure the same fonts or at least related, that are missing in Google Earth.

@fanthom: when you read this post, please look in 002-xorg.xzm to find what is missing....

Ok, Hamza, you are now informed of what cooks in my brain. Maybe you have more precise ideas of how to proceed.

Regards!
Last edited by wread on 20 Jun 2011, 01:24, edited 1 time in total.
Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

User avatar
brokenman
Site Admin
Site Admin
Posts: 5574
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Porteus-v1.0-rc2-x86 "So close to the FINAL..."

Post#75 by brokenman » 11 Jun 2011, 01:28

I have google Earth 6 latest running in Porteus 32bit with fonts working great. Google uses their own built in Qt4 libraries so you won't need anything else other than a vanilla Porteus 32bit.

Here's how.

Download the rpm version of google earth.
rpm2tgz googleearth.rpm
txz2xzm googleearth.tgz
activate googleearth.xzm
ln -sf /lib/ld-linux.so.2 /lib/ld-lsb.so.3 # Google earth is LSB compliant (Linux Standards Base)

http://porteus.googlecode.com/files/fon ... arch-1.xzm
Now download this cyrillic font and activate it. Restart your X session and away you go! So not really a bug at all, it's just that google use a screwy font .... and google earth is NOT open source!! If it was, this problem wouldn't be so common.

I hope this rekindles your love for Porteus. :Rose:
How do i become super user?
Wear your underpants on the outside and put on a cape.

Post Reply