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
ponce
Contributor
Contributor
Posts: 89
Joined: 28 Dec 2010, 10:15
Location: IT
Contact:

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

Post#16 by ponce » 09 Mar 2011, 07:58

X should load the .Xresources file in the xinitrc, executed at X start, it doesn't get loaded dinamically: I tried with the default .xinitrc generated by xwmconfig for lxde.

yes, the ntp package is big, I thought (if possible) about the inclusion of the ntpdate binary only (works fine alone): looks like it's needed too for the kde clock to set the time automatically with a time server :)
while doing that I spotted that the kde clock still has problems setting the timezone: running manually timeconfig to set it by a dialog interface seems to fix it.

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

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

Post#17 by fanthom » 10 Mar 2011, 00:41

@ponce
".Xresources"
hmmm... will dig into it.

"kde clock still has problems setting the timezone"
ok you got me :) need to confess something - i have downgraded polkit to older version then in slackware-current to fix annoying KDE bug:
https://bugs.kde.org/show_bug.cgi?id=258916
polkit-agent get fixed but caused 3 other bugs:
- lxde automount in pcmanfm is gone
- 'suspend' option for lxde logout is gone
- user is not able to change the time in KDE through systemsettings.
i have just tried newly released polkit-0.101-x86_64-1.txz: all bugs are fixed except polkit-agent one.
didn't want to bother you right now, but before 1.0 FINAL i may ask you to recompile LXDE against older version of polkit.
Other option is to bump KDE to 4.6.x branch (polkit-agent issue is not there) but as per today it's not a good idea (2 other bugs are still opened for KDE-4.6.x).

SP1 for BETA will be released Today. should fix 'lxde menu - missing icon' bug.

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

User avatar
Rava
Contributor
Contributor
Posts: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: Germany

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

Post#18 by Rava » 10 Mar 2011, 01:35

fanthom, could you please add the md5sum to the post where you link to the download?

By doing this we remind less experienced Porteus users to check the md5sum after download. I also suggest we put that small detail into some kind of "rulebook" for the Porteus forum "how to post links to Porteus ISO or forks of Porteus or modules for Porteus" or similar... :)

Since in the past I remember more than once an issue when something did not work with a Slax Remix and it was just a messed up download and all the troubleshooting could have been avoided by using and promoting md5sum.

About "sq4 / xzm"

Is xzm the new sq4?
I tried searching the forum for these terms but so far it seems I found not the right post giving me more details...
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#19 by Ahau » 10 Mar 2011, 02:14

xzm is the new lzm. It's still squashed using squashfs4 before being compressed further with LZMA2 (xz).

EDIT\\
more info:
viewtopic.php?f=53&t=231

Edited by fanthom.
Please take a look at our online documentation, here. Suggestions are welcome!

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

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

Post#20 by fanthom » 10 Mar 2011, 04:22

Service Pack 1 for 64 bit BETA:
http://www.mediafire.com/file/9hnbjy9l2 ... ta-SP1.xzm
put in /porteus/base and reboot :)

fixes:
- 'lxde menu icon not showing up' bug
- adds empty file in place of /usr/lib64/xorg/modules/drivers/modesetting_drv.so to fix nouveau issue
- removes one extra entry of 'Porteus-Network-Setup-Tool' in kmenu/lxde menu. xpns-tool is now the default one as it needs some testing

Activation script has some extra functions copied from rc.S and rc.M.
(this is only a proposition and can be rejected if brokenman wont agree)

- /sbin/ldconfig & is run at each insertion. Falcony was asking for it some time ago :)
- 'depmod -a' is run when new kernel modules are found
- new modules are modprobed on the fly so user wont heave to restart porteus or do it manually
- mime cache is rebuilt at each insertion/deactivation

i have left more function commented out:
#echo "Updating X font indexes: /usr/bin/fc-cache -f &"
#/usr/bin/fc-cache -f &

#if find /usr/share/icons 2> /dev/null | grep -q icon-theme.cache; then
# for theme_dir in /usr/share/icons/* ; do
# if [ -r ${theme_dir}/icon-theme.cache ]; then
# echo "Updating icon-theme.cache in ${theme_dir}..."
# /usr/bin/gtk-update-icon-cache -t -f ${theme_dir} > /dev/null 2>&1 &
# fi
# done
#fi
#echo "Updating desktop database: /usr/bin/update-desktop-database &"
#/usr/bin/update-desktop-database &

# Update gtk specific stuff
#/usr/bin/update-pango-querymodules &
#/usr/bin/update-gtk-immodules &
#/usr/bin/update-gdk-pixbuf-loaders &

as was getting hangups during insertion (probably too many processes in the background). we can uncomment them if necessary.

The whole idea is to have modules with full functionality after insertion, despite of their quality. the only thing which i was not able to cover is a 'custom action' which is required to get certain package to work.
for example:
squid application needs a user 'squid' existing in the system. this user must be added through /etc/rc.d/initd/squid.sh file and proper symlink to /etc/rc.d/rc3.d/
more info: http://www.slax.org/documentation_creat ... _rules.php

Slackware packages have '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 extended functionality of 'activate' script to get modules even with crappy quality to work with porteus.
This costs only one thing: slower insertion of modules to the live system.

brokenman - what you think about it?
should we force users to create xzm's the right way (with /etc/rc.d/initd/xxx.sh) or make their life easier with activate script posted above?
Please add [Solved] to your thread title if the solution was found.

User avatar
Rava
Contributor
Contributor
Posts: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: 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
Site Admin
Site Admin
Posts: 4623
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
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: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: 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
Site Admin
Site Admin
Posts: 4623
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
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: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: 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
Site Admin
Site Admin
Posts: 4623
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
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: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: 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!

Locked