Porteus-v1.0-beta-x86_64 is ready :)

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.
User avatar
Rava
Contributor
Contributor
Posts: 5424
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#21 by Rava » 10 Mar 2011, 04:40

fanthom wrote: Slackware packages has 'doinst.sh' script which does all required actions. Porteus modules must have /etc/rc.d/initd/xxx.sh scripts which does the same.

as i know the life - users wont be following this rule. that's why i have done my best to get modules with crappy quality to work with porteus.
Are there howtos of how to create a /etc/rc.d/initd/xxx.sh out of a doinst.sh, or can one just copy the doinst.sh to /etc/rc.d/initd/xxx.sh?

Since it might be that I will also create modules for Porteus and I want the quality as best as I can... :wink:

//edit
now the auto-logout struck me as well... when I made the login to be saved with lastpass I activated "stay logged in forever"... but it seems phpBB is picky at times....
So I hope I can recall all I just added...

I could start Porteus from the NTFS/Windows7 partition using NeoGrub and that code in the menu.lst:

Code: Select all

title Porteus 64 bit 1.0 beta Copy2Ram, Always Fresh, Text Mode
rootnoverify (hd0,1)
kernel (hd0,1)/boot/vmlinuz ramdisk_size=6666 max_loop=256 root=/dev/ram0 rw copy2ram lang=de_DE lxde  autoexec=telinit~3
initrd (hd0,1)/boot/initrd.xz
boot
But lang=de_DE won't work, I presumed it might since Porteus gave me the hint with pl_PL

But the NVidia driver and X won't play fair:

Code: Select all

root@porteus:~# activate /tmp/010-nVidia-260.19.36-porteus-v1.0_beta-x86_64.xzm
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.ISO-8859-1)
module file is stored inside the union, moving to /mnt/live/memory/modules first...
Updating shared library links:  /sbin/ldconfig &
/usr/bin/activate: line 131: syntax error near unexpected token `fi'
/usr/bin/activate: line 131: `    fi'
Startx as guest then tells me:

Code: Select all

FATAL: Module nvidia not found.
(EE) NVIDIA: Failed to load the NVIDIA kernel module. Please check your
(EE) NVIDIA:     system's kernel log for additional error messages.
(EE) Failed to load module "nvidia" (module-specific error, 0)
(EE) No drivers available.
I tried both the xorg.conf from Slax Remix V08 and the new created by nvidia-xconfig, but both to no prevail with the same error.

//update
Next time I boot without the LXDE cheatcode, maybe it is some weird error between LXDE and my Nvidia card, or LXDE and the Nvidia driver, who knows...
Last edited by Rava on 10 Mar 2011, 21:03, edited 1 time in total.
Cheers!
Yours Rava

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#22 by Ahau » 10 Mar 2011, 15:41

I’m running 64-bit beta for version 1.0 with service pack 1, KDE always fresh, with toroot cheatcode.

This morning, I came across three minor issues:

1) Firefox 'sdb1'

Now that you’ve fixed the “lazy” devices like mine, my flash drive now shows up properly, at /mnt/sdb1. Yay! However, now when I open a dialog in firefox to save a downloaded file or to open a file in firefox (file->open), I also get an entry for ‘sdb1’ under “places”, which should serve as a shortcut to my flash drive.

When I click on ‘sdb1’, it gives me an error, saying that sdb1 is busy, and that /dev/sdb1 is already mounted on /mnt/sdb1. This is a minor issue, really. An inconvenience—but now that we’re in beta, I’m getting more picky ;)

2) Nouveau screen flashes

During the boot-up procedure, my screen flashes once (with a little bit of garbage) and resizes the text. This seems to happen just before magic folders are mounted. I thought maybe you had removed the blacklist.KMS file from /etc/modprobe.d, and it turns out, I was right. I didn’t see this one in the changelog, but correct me if I’m wrong. Not a big issue unless and until we bring back a bootsplash image (or maybe we already have, and I’m not seeing it because I’m using a custom boot).

Anyway, I copied the blacklist.KMS file to my rootcopy in beta, and that slowed my booting process way down, gave me a weird flash just before going into KDE, and then an error that popped up as soon as KDE started, saying: “Unable to save bookmarks in /root/.local/share/usre-places.xbel. Reported error was: Insufficient permissions in target directory….[snip]…most likely a full hard drive.” An odd error, given that I am root, have 1GB of ram available, am not using a hard drive, and my flashdrive has almost a gig free as well.

Again, this is a small issue (not having blacklist.KMS)—but it led me to my next problem:

Rootcopy: I’m not sure if this is really a bug, it’s more like an issue. I’m going to title this issue, “Rootcopy Wars, Episode 1: The Phantom Menace”. Here’s the problem: I removed the directory and file, /modprobe.d/blacklist.KMS from my rootcopy, to resolve the issue above. Upon restarting, everything went fine through the startup procedure, but KDE was slow to startup, and I got the same “unable to save bookmarks” error message. I checked to make sure I had enough space in my RAM and flashdrive, and everything was OK, so I rebooted again, and had the same problem. What I figured out is that when I deleted /modprobe.d/blacklist.KMS, it got moved to my flashdrive’s /.Trash file, and was still interfering with KDE. I purged it from .Trash, and the issue went away. I'm guessing that some kind of metadata is stored, linking the file in .Trash to it's original location, and the system picks up on that for some reason.

Again, I wouldn’t call this a bug, but I think folks do need to be aware that they should clear their trash after deleting something from rootcopy.

Overall, very nice! It was great to activate my gimp module, and then see it in the menu :D
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5667
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#23 by fanthom » 10 Mar 2011, 21:30

@Ahau
"1) Firefox 'sdb1'"
this is probably a bug in firefox (or gtk?). when you click on a device listed in 'places' it gets mounted somewhere (media? - can't check now) and you have an access to it. error appears when you click on a device from which you are booting as it's mounted already.
i have this issue under gentoo so it's not "porteus only" related. cant do much about it :(

"2) Nouveau screen flashes"
yes - all drivers blacklisted by default are gone in BETA. we wont have 'bootsplash' in v1.0 so i have removed this file.
there is a little hope for 'plymouth' as seems that it works with 'UVESA' driver now (doesn't depend on KMS so can be used for all GPU's, also fglrx and nvidia binary)
but i need to find a time to implement it first :)
also - since BLACKLIST-KMS file is gone all nvidia binary builders must use 'nomodeset' cheatcode to be able to build this driver successfully. i think they are aware of it :)

".Trash"
dolphin has an option for 'DELETE with skipping trash' but it's not listed in the 'right mouse click menu' by default. i have done it for a safety purpose as it's very hard to recover files from journaled linux filesystems. users must enable it in dolphin's config themselves.

in general, i see that BETA is in a pretty good shape :)
Thanks for the feedback.
Please add [Solved] to your thread title if the solution was found.

User avatar
Rava
Contributor
Contributor
Posts: 5424
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#24 by Rava » 10 Mar 2011, 21:38

fanthom, no idea why X won't start for me?

Like I said, I will boot it up again in KDE mode, but also without starting X by itself... but now I have a bit work to do and Slax Remix V08 is the only real OS running on that machine.
But hopefully the reason why it won't work will be eliminated...
Cheers!
Yours Rava

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5667
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#25 by fanthom » 10 Mar 2011, 22:01

@Rava
sorry - missed your updated post completely :)
1) get rid of 'ramdisk_size=6666 root=/dev/ram0 rw' cheatcodes, they are hardcoced in the kernel and no longer required in bootloader config anymore.
2) 'lang=de_DE' wont work until you use 'LST' (which wont be updated before FINAL). you should be able to use locales module from older porteus (slax-remix) versions. conversion to xzm required.
3) '/usr/bin/activate: line 131: syntax error near unexpected token `fi'' are you using SP1? may be a small issue with 'activate' script. will check this out.
4) nvidia problems - put nvidia xzm in /porteu/modules and reboot with telinit~4. make sure that nouveau is not loaded. post /var/log/Xorg.0.log in case of troubles.

UPDATE
'/usr/bin/activate: line 131: syntax error near unexpected token `fi''
i have used 'for; do; fi' instead of 'for; do; done' :)
it's a small issue so will be fixed in SP2 - thanks!
Please add [Solved] to your thread title if the solution was found.

User avatar
Rava
Contributor
Contributor
Posts: 5424
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#26 by Rava » 11 Mar 2011, 02:00

1) Okay...
fanthom wrote:2) 'lang=de_DE' wont work until you use 'LST' (which wont be updated before FINAL). you should be able to use locales module from older porteus (slax-remix) versions. conversion to xzm required.
If X still gives me issues, is there a lzm2xzm for console in 1.0beta?
4) nvidia problems - put nvidia xzm in /porteu/modules and reboot with telinit~4. make sure that nouveau is not loaded. post /var/log/Xorg.0.log in case of troubles.
It is already in /porteus/modules. Does nvidia-xconfig not complain when the nouveau is still loaded?
Seems it might be easier to setup a VirtualBox for Remix V08 and check out Porteus in there first. :P
'/usr/bin/activate: line 131: syntax error near unexpected token `fi''
i have used 'for; do; fi' instead of 'for; do; done' :)
it's a small issue so will be fixed in SP2 - thanks!
Fun fact: we had the same bug in Slax Remix V08.
Cheers!
Yours Rava

User avatar
ponce
Contributor
Contributor
Posts: 89
Joined: 28 Dec 2010, 10:15
Location: IT
Contact:

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#27 by ponce » 11 Mar 2011, 08:40

I'm just done building LXDE and deps on porteus: I had to downgrade udisks and upower because of the polkit thingie and that forced me to build on the released iso. ;)

I installed expat (needed) and linuxdoc-tools (only for compiling time), but build was still failing because of the state of /usr/lib64/{libpng*,libjpeg*}: it looks there are only the libs there and no pkgconfig stuff or stuff in /var/log/packages.
I had to remove those and installpkg libpng and libjpeg from current and all went well after...
well, not exactly, I had to patch some slackbuilds to not build man pages because xsltproc segfaulted for those, but it's everything in this tarball :pardon: :beer:

http://ompldr.org/vN3JiMA/lxde-porteus-beta.tar.gz

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5667
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#28 by fanthom » 12 Mar 2011, 12:23

@Rava
yes - cli 'lzm2xzm' is there

"Does nvidia-xconfig not complain when the nouveau is still loaded?"
probably. just use 'nomodeset' cheatcode.

@ponce
you are my hero!
all works just perfect with you new LXDE package set :) only 'kde timezone set' bug left, but we can live with it...

btw- libjpeg and libpng are not in the porteus by default. mentioned libs are part of 'aaa_elflibs' package. headers are needed for developers only :wink:

Posted after 1 day 2 hours 25 minutes 58 seconds:
another bug just hit the BETA. this time it's very serious and no workaround for it.

the STORY:
deactivation of a modules hangs the system completely.

HOW TO RECREATE:
boot into lxde -> go to /mnt/xxx/porteus/base
now we have 2 scenarios (order of deactivation/activation is very important):
1) 'deactivate 005-kdeapps' -> 'deactivate 004-kde' -> 'activate 005-kdeapps' -> 'activate 004-kde' -> 'deactivate 005-kde' -------- you have 100% chances to get a hang.
2) 'deactivate 005-kdeapps' -> 'deactivate 004-kde' -> 'activate 004-kde' -> 'activate 005-kdeapps' -> 'deactivate 005-kdeapps' -> 'deactivate 004-kde' ---------- you have 50% chances to get a hang.

i believe that it's a problem with aufs branches so module which is activated earlier, cant be deactivated as first.
if you preserve correct order then you still have 50% chance on hang (didn't find out why).

i have tried everything to get it fixed:
- used aufs utils
- commented out workarounds for 'kmenu missing icon' and 'lxde menu not getting updated' bugs
- commented out other changes introduced in BETA (like ldconfig &, update-mime-database, etc..)

still no joy.
if it wont be fixed before FINAL then i'll go with 2.6.37.x + lzma instead of xz :(

BTW: i have used 'activate/deactivate/xactivate/xdeactivate/ from v01 BETA in v09 and problem does not exist. you can activate/deactivate kde modules as many times as you want despite of module insertion order.
Please add [Solved] to your thread title if the solution was found.

User avatar
Rava
Contributor
Contributor
Posts: 5424
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#29 by Rava » 13 Mar 2011, 09:35

@fanthom

Oh, that sounds like no fun with the deactivate/activate bug... :cry:
_______________________________

I included the file from Slax_remix that not loads the nouveau and X runs fine.

Just one issue left: I used the LDXE cheatcode, but still when running startx KDE is started. :(
Cheers!
Yours Rava

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#30 by Ahau » 13 Mar 2011, 17:03

rava, do not run startx to get LXDE running. startx is configured to run KDE. remove startx from your APPEND line in porteus.conf. /etc/rc.d/rc.4 searches for lxde in the APPEND line and runs lxdm instead of kdm if 'lxde' is present. should be 'autoexec=lxde;xconf;telinit~4'.
Please take a look at our online documentation, here. Suggestions are welcome!

Burninbush
Power user
Power user
Posts: 53
Joined: 29 Dec 2010, 01:46
Location: Near SF, CA

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#31 by Burninbush » 13 Mar 2011, 18:03

rava, do not run startx to get LXDE running. startx is configured to run KDE. >ahau

+++++++++++++++++

Ahhh ... but isn't xwmconfig still there and working?

It isn't necessary to go all the way back to a reboot to run a different gui. Startx starts X with whatever gui you have told it to run in xwmconfig.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#32 by Ahau » 13 Mar 2011, 21:11

yes, bb, you are right. What I meant to say is that the default configuration for startx in porteus is to start KDE, and it will do so unless configured otherwise. I haven't tried in a while, but I believe it will start LXDE if KDE has been removed from the system.

Thus, if you have KDE and LXDE both installed, and run startx from the append line (without configuring it to run LXDE first), and you also have 'lxde' in the append line, porteus will have commands to start both desktop environments. (KDE through startx and LXDE via lxdm through /etc/rc.d/rc.4). I believe that is what is happening in Rava's setup, but we'll need more information from Rava to determine that for sure.

btw Rava-- I was able to get the nVidia driver to run instead of nouveau in v1 beta, by either adding the 'nomodeset' cheatcode per fanthom's instructions, or by blacklisting nouveau in /etc/modeprobe.d/blacklist.conf.
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5667
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#33 by fanthom » 13 Mar 2011, 21:50

@all
you have 3 ways of starting GUI in Porteus:
1) through 'startx' command
2) through display managers (kdm, lxdm)
3) through runlevels (4 in our case).

First case base on /etc/X11/xinit/xinitrc symlink. when this file is linked with xinitrc.kde then kde is started, when is linked with xinitrc.lxde then lxde. you can change symlinks by using 'xwmconfig' utility or just do it manually - same effect.
003-lxde has this symlink set to xinitrc.lxde so when no KDE is present - this desktop is started. if 004-kde is there, then xinitrc form 003 is overrided with xinitrc from 004 (which obviously point to xinitrc.kde) and KDE is started by default.

why i dont like 'startx' way of initializing X11 environment?
- you need to be logged in to issue this command
- kde is short of 'reboot, shutdown, hibarnate, etc..' functions - only 'logout' is present
- when GUI is started by guest then there is no way to reboot or shutdown without 'su'

Second case is better than 'startx' as:
- you have configuration (/etc/lxdm/lxdm.conf and /usr/share/config/kdm/kdmrc) files where you can set plenty of things like who: should be logged in by default, what to do with numlock, etc.
- when logged in as guest, you still have possibility to do a reboot, shutdown, hibernate, etc....

Third case is the best as it gives you flexibility how to start GUI (startx or display managers) but also starts/stops all scripts while switching between runlevels (S* and K* scripts in /etc/rc.d/rc3.d and /etc/rc.d/rc4.d). Just have a look on /etc/rc.d/rc.4 for more info.

Porteus uses runlevel 4 by default to start GUI (telinit~4) and kdm/lxdm to manage X11 session.

Trust me - it's the best way :wink:

Cheers
Please add [Solved] to your thread title if the solution was found.

User avatar
Rava
Contributor
Contributor
Posts: 5424
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#34 by Rava » 14 Mar 2011, 14:47

@fanthom
I get it now. I wrote a script that changed the /etc/X11/xinit/xinitrc symlink either to start KDE or LXDE.

I think I will just put the wanted symlink in my 100-local. module then, just like with remix. :D

Verfasst after 2 minutes 34 seconds:
Ahau,
I want telinit~3 for a reason, since I need to log in into console at the beginning prior starting X so that some kind of backed up data is copied into the union (but I could stop that when some reason exist to not want that)
I use the "Always Fresh" mode but back up some program by myself, and with the above technique it gets resored (like I said, unless I don't want it restored)
It also keeps the most resent "store" and also 3 backups of that data that I could restore instead of the recent one that is done by just pressing enter or waiting 4 seconds...

I tweaked startx with Remix V08, and I just can do the same now, like putting a symlink to startlxde or what's it called (I again run remix right now since at the beginning there is more to integrate when having a new system since I run it with "always fresh"...)

I am just weird like that, but I prefer it and to me it is a more secure system that way... *shrug*


///EDIT

The forum is acting weird right now.
I wanted to answer to a post by Ahau that I got reminded of by email with the URL of http://forum.porteus.org/viewtopic.php? ... 2020#p2020 and the text of
rava, do not run startx to get LXDE running. startx is configured to run KDE. remove startx from your APPEND line in porteus.conf. /etc/rc.d/rc.4 searches for lxde in the APPEND line and runs lxdm instead of kdm if 'lxde' is present. should be 'autoexec=lxde;xconf;telinit~4'.
But for some reason phpBB messes up this thread... and instead the post by Ahau disappears (unless I use the above link) and instead my new post got added to my old reply...
:no: Just letting you know, maybe it is the result of yet another hacking attempt?
Last edited by Rava on 01 Apr 2011, 22:34, edited 1 time in total.
Cheers!
Yours Rava

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: Porteus-v1.0-beta-x86_64 is ready :)

Post#35 by Ahau » 14 Mar 2011, 14:53

Sorry rava -- that was my fault. I didn't see that you were trying to boot into telinit 3. Sorry for the confusion!
Please take a look at our online documentation, here. Suggestions are welcome!

Locked