Porteus-1.1-rc1-x86_64 is ready for testing

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
fanthom
Site Admin
Site Admin
Posts: 4547
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Porteus-1.1-rc1-x86_64 is ready for testing

Post#1 by fanthom » 19 Oct 2011, 18:28

As promised i have uploaded 64bit rc1 for testing. You can find the ISO with usual set of drivers in following folder:
http://ponce.cc/porteus/x86_64/testing/ ... -v1.1-rc1/

ISO contains linux kernel 3.1-rc10, updated graphic stack and various packages (still comaptible with Slackware-13.37).
Init scripts are optimized to maximum so you will experience fastest booting possible. We have switched to UTF-8 by default. Kde-4.7.2 is stripped down from nepomuk and rebuilt with new gcc flags so memory usage measured straight after boot went down from 340MB (Porteus 1.0) to 250MB (Porteus 1.1 rc1). libraries and utilities from initrd are compiled against uClibc insted of glibc to get smaller size and extra speed. We have latest version of "Porteus Package Manager" by brokenman and "Porteus Settings Centre" by Hamza - thanks guys for the contribution. Many other improvements are mentioned in detailed changelog:
viewtopic.php?f=44&t=747&sid=bbc39bfadf ... c33dc210ae

Give it a shot and let me know about any issues you find.
Tomorrow i'm going to send all updates to brokenman so 32bit release should follow very soon.

KNOWN BUGS
- ndiswrapper did not compile with 3.1-rc10 kernel so is not present, need to find a patch before final
- LXDE: xarchiver still segfaults when creating uncompressed tar archives
- LXDE: raw qt apps (smplayer, qmmp) looks ugly when started after any KDE app (kpaint, dolphin, etc..). qt theme issue? i have no idea how to fix it - help is welcome. (SOLVED - as per Ahau findings)
- LXDE: sometimes after relogin, transparency set on the taskbar messes up whole bottom bar. the only fix is to disable transparency completely. will do for FINAL if users finds it annoying.
- KDE-4.7.2: battery applet is always hidden. shows up only when battery is charging, discussion:
http://www.mail-archive.com/plasma-deve ... 15890.html
- KDE-4.7.2: kickoff "return" bar is missing
https://bugs.kde.org/show_bug.cgi?id=274489
- KDE-4.7.2: sometimes "smooth-tasks" plasmoids does not remove icons of the applications which are closed. upstream bug.

Regards,
fanthom
Last edited by fanthom on 29 Nov 2011, 20:00, edited 2 times in total.
Reason: new release rc2
Please add [Solved] to your thread title if the solution was found.

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

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#2 by Hamza » 19 Oct 2011, 19:48

There is an issue in this version of Porteus Settings Centre.

Please, don't reset or generate a new porteus.cfg file.

I written the generate's to works with Porteus v1.0 final
The next version will be compatible with Porteus v1.1

The issue;
This version include the autoexec=xconf (already removed telinit~4)
but fanthom removed it to avoid mistakes in boot configuration when an user to edit his boot config with text editor.
NjVFQzY2Rg==

User avatar
BlackRider
Black ninja
Black ninja
Posts: 70
Joined: 13 Jul 2011, 11:04
Location: Nowhere
Contact:

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#3 by BlackRider » 19 Oct 2011, 21:02

I will have a look at it when possible.

Can I ask how the issue with the loop device encryption has been dealt with?

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-1.1-rc1-x86_64 is ready for testing

Post#4 by Ahau » 20 Oct 2011, 06:03

WooHoo! Just got it downloaded, and now up and running. Looking good! Seems to boot even faster! I like the wallpaper and theme, and can't wait to get into it a little deeper :)

One issue that came up -- pns-tool.sh had some weird behavior for me. xpns-tool worked fine, but I kinda like the old text version. While testing the connection, it scrolled 0's very slowly (one or two per second):

Code: Select all

If you have trouble please paste this debug info on the Porteus forum:
dhcpcd[3347]: version 5.2.12 starting
dhcpcd[3347]: wlan0: rebinding lease of 192.168.1.108
dhcpcd[3347]: wlan0: acknowledged 192.168.1.108 from 192.168.1.1
dhcpcd[3347]: wlan0: checking for 192.168.1.108
dhcpcd[3347]: wlan0: leased 192.168.1.108 for 86400 seconds
dhcpcd[3347]: forked to background, child pid 3438
0
0
0
0
0
0
0
0
0
0

Many thanks, fanthom, for all your hard work in putting this together!
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
Blaze
Moderator
Moderator
Posts: 1333
Joined: 28 Dec 2010, 11:31
Distribution: ⟰ Porteus 3.2 Cinnamon x86_64
Location: ☭ Russian Federation, Lipetsk region, Dankov
Contact:

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#5 by Blaze » 20 Oct 2011, 12:19

Hello.

The X of Porteus-1.1-rc1-x86_64 does not start with my video card NVIDIA GeForce 8600.
[ 115.832] (++) using VT number 7 and [ 128.077] (II) NOUVEAU(0): Closed GPU channel 2

My Xorg.0.log

BTW `fonts.dir' not found (or not valid) in "/usr/share/fonts/TTF".
Linux porteus 4.12.7-porteus #1 SMP PREEMPT Sun Aug 13 17:38:30 x86_64 Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz GenuineIntel GNU/Linux
MS-7A12 » [AMD/ATI] Tobago PRO [Radeon R7 360 / R9 360 OEM] (rev 81) » Vengeance LPX 16GB DDR4 K2 3200MHz C16

Tonio
Contributor
Contributor
Posts: 266
Joined: 28 Dec 2010, 16:37
Distribution: Slackware,porteus,FreeBSD,Slax
Location: 127.0.0.1

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#6 by Tonio » 20 Oct 2011, 12:21

Testing it :) So far no problems to report. Was looking forward to testing new release(s)/release candidates :)

Code: Select all

root@porteus:~# uname -r
3.1.0-rc10-porteus
root@porteus:~# cat /etc/porteus-version 
Porteus-v1.1

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-1.1-rc1-x86_64 is ready for testing

Post#7 by Ahau » 20 Oct 2011, 13:06

Found another issue with network connection, this time with xpns-tool.sh, and I'd imagine it applies to pns-tool as well.

The module created by xpns-tool includes a script, S-pns, and places it in /etc/rc.d/rc3.d. Now that init 4 is our default runlevel, I think the scripts in this folder are no longer run at startup. So, xpns-tool works to connect me to the internet and it creates a module, but when I reboot (this is in always fresh mode), I am not connected to the internet.

Copying the script to /porteus/rootcopy/etc/rc.d/rc.4/S-pns resolves this issue.

I started up lxde as well, I really like the new wallpaper and how the taskbar blends into it. It's a very clean, cool look, and might make me replace KDE with lxde as my default :)
Please take a look at our online documentation, here. Suggestions are welcome!

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

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#8 by fanthom » 20 Oct 2011, 13:17

@BlackRider
Can I ask how the issue with the loop device encryption has been dealt with?
i have removed this feature completely. forgotten to mention this in the changelog - my bad.

@all
please shout if you want this feature back so i'll start playing with cryptoloop + luks.

@Ahau
One issue that came up -- pns-tool.sh had some weird behavior for me. xpns-tool worked fine, but I kinda like the old text version.
could be a random hang in pns-tool.sh - could you try once again to confirm?
if the issue persist then i'll remove pns from next release. i see no point in digging into old code while we have working xpns and wicd.
The module created by xpns-tool includes a script, S-pns, and places it in /etc/rc.d/rc3.d. Now that init 4 is our default runlevel, I think the scripts in this folder are no longer run at startup.
good job :good:
i'll fix it for rc-2

@Blzae
to be sure:
a) did you try "always fresh" mode ?
b) please add 'autoexec=xconf" cheatcode to generate /etc/X11/xorg.conf during startup
c) i think it's the same bug which we had in 32bit Porteus-1.0 rc2:
viewtopic.php?f=53&t=535&hilit=blaze+no ... t=30#p4026
for some reason new nouveau driver does not play nice with older Nvidia cards. please downgrade to xf86-video-nouveau-git_20110417 and confirm that it works for you. if yes then i'll downgrade it too.

@Tonio
glad to hear it :)

@all
added KNOWN BUGS section to initial post - please read it.

more reports please :)
Please add [Solved] to your thread title if the solution was found.

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-1.1-rc1-x86_64 is ready for testing

Post#9 by Ahau » 20 Oct 2011, 14:48

fanthom wrote: could be a random hang in pns-tool.sh - could you try once again to confirm?
if the issue persist then i'll remove pns from next release. i see no point in digging into old code while we have working xpns and wicd.
I tried it a few times to confirm before I posted -- and tried it again. I've not resolved it entirely due to my remedial scripting skills, but I think something has changed in the way my device (maybe others?) displays it's info under the 'route -nee' command in V1.1.

Here's the section of code from pns-tool that is causing the hang (starting at line 259):

Code: Select all

    echo -e "${r}Wait a few seconds for dhcpcd, which needs to acquire all details for your device."$e
    echo -e "${c}If you have trouble please paste this debug info on the Porteus forum:"$e
    GAT=`route -nee | grep $dev | tail -n1 | awk '{print $2}' | cut -d '.' -f1`
    while [ "$GAT" = "" ]; do
	sleep 1
	unset $GAT > /dev/null 2>&1
	GAT=`route -nee | grep $dev | tail -n1 | awk '{print $2}' | cut -d '.' -f1`
    done
    RTE=`route -nee | grep $dev | tail -n1 | awk '{print $2}' | cut -d '.' -f1`
    while [ $RTE = 0 ]; do
	sleep 1
	unset $GAT > /dev/null 2>&1
	RTE=`route -nee | grep $dev | tail -n1 | awk '{print $2}' | cut -d '.' -f1`
	echo $RTE
    done
You can see that 0 will be echoed as long as the $RTE variable remains 0. Here's the output of 'route -nee':

Code: Select all

root@porteus:~# route -nee
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface    MSS   Window irtt
0.0.0.0         192.168.1.1     0.0.0.0         UG    303    0        0 wlan0    0     0      0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo       0     0      0
192.168.1.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0    0     0      0
root@porteus:~#
When you tail -n1 and awk print $2, you get the 0.0.0.0 Gateway from the bottom listing of wlan0. I could get out of this loop (I would imagine) by using awk '{print $1}' to pull from the Destintation instead of the Gateway, but I'm not really sure why this is happening differently in V1.1. The thing is, the internet connection works while it's printing 0's, so it truly is just a loop issue associated with the $RTE variable and how it's stored. Further, I don't know if this is only an issue on my machine or not. I imagine this is easy for someone with your knowledge to fix :)

Thanks!

EDITED TO ADD: Ok, I checked this in V1.0 and...it does the same thing (prints 0's instead of creating a module and exiting the script). I don't really know what to make of it lol.

Posted after 40 minutes 19 seconds:
@fanthom, I can't reproduce the QT bug -- smplayer and qmmp look the same to me before and after starting KDE apps. Any more details on how to reproduce it? Could you take some screenshots of it to show the difference?

I tried it as root, guest, with and without changes, and also in VESA mode. Do you have anything running besides the modules in the default ISO?

I did notice a string of error messages related to kbuildsycoca4 after pns-tool finished running while in lxde; running kbuildsycoca4 by itself also generated a lot of errors.
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
Blaze
Moderator
Moderator
Posts: 1333
Joined: 28 Dec 2010, 11:31
Distribution: ⟰ Porteus 3.2 Cinnamon x86_64
Location: ☭ Russian Federation, Lipetsk region, Dankov
Contact:

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#10 by Blaze » 20 Oct 2011, 15:39

fanthom wrote:b) please add 'autoexec=xconf" cheatcode to generate /etc/X11/xorg.conf during startup

Code: Select all

APPEND initrd=/boot/initrd.xz vga=791 autoexec=xconf changes=/mnt/sda3/changes/
This advice has helped me so much so thanks!
A new style of Porteus is very cool :good:

When i run Language Selection Tool i have seen this message:

Code: Select all

cat: /opt/porteus-scripts/language-selection-tool: No such file or directory
Last edited by Blaze on 20 Oct 2011, 16:07, edited 3 times in total.
Linux porteus 4.12.7-porteus #1 SMP PREEMPT Sun Aug 13 17:38:30 x86_64 Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz GenuineIntel GNU/Linux
MS-7A12 » [AMD/ATI] Tobago PRO [Radeon R7 360 / R9 360 OEM] (rev 81) » Vengeance LPX 16GB DDR4 K2 3200MHz C16

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-1.1-rc1-x86_64 is ready for testing

Post#11 by Ahau » 20 Oct 2011, 15:42

Might this be applicable in some way, to the QT issue?

https://wiki.archlinux.org/index.php/KD ... ow_manager
Please take a look at our online documentation, here. Suggestions are welcome!

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

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#12 by Hamza » 20 Oct 2011, 17:09

Hello everyone,

I made an "update" version of PSC.

Some changes:
  1. Compatible with Always Fresh
  2. Added On the fly function in default process
  3. Fixed Loop execution at end of process
  4. Updated generate function - Compatible with Porteus v1.1
  5. And many other small changes..
So, If someone want to test it.
Download Link

How to use this version ?
  1. Download it with the download link
  2. Give it the execute permission with this command

    Code: Select all

    chmod +x /path/to/script.sh
    Note : You need to replace the "/path/to" with your downloads folder.
  3. Open a terminal, and type

    Code: Select all

    bash /path/to/script.sh
  4. That is not difficult. Enjoy! :Yahoo!:
Cheers
NjVFQzY2Rg==

Tonio
Contributor
Contributor
Posts: 266
Joined: 28 Dec 2010, 16:37
Distribution: Slackware,porteus,FreeBSD,Slax
Location: 127.0.0.1

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#13 by Tonio » 21 Oct 2011, 00:47

Automounting of Disk drives is not working :(
I noticed this with windows machines, got an ntfs-3g error that flew by quickly :(

Code: Select all

root@porteus:~# fdisk -l

Disk /dev/sda: 500.1 GB, 500106780160 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976771055 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x90909090

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63   154009295    77004616+  a5  FreeBSD
/dev/sda2       154009600   162398207     4194304   82  Linux swaproot@porteus:~# cat /etc/fstab 
# System mounts
aufs / aufs defaults 0 0 # AutoUpdate
proc /proc proc defaults 0 0 # AutoUpdate
sysfs /sys sysfs defaults 0 0 # AutoUpdate

# Device partitions
/dev/sda1 /mnt/sda1 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda3 /mnt/sda3 ext3 auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda5 /mnt/sda5 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda7 /mnt/sda7 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda8 /mnt/sda8 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda9 /mnt/sda9 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sdb1 /mnt/sdb1 ntfs auto,noatime,users,suid,dev,exec,locale=utf8 0 0 # AutoUpdate
/dev/sdb2 /mnt/sdb2 ntfs auto,noatime,users,suid,dev,exec,locale=utf8 0 0 # AutoUpdate

# Swap partitions
/dev/sda2 none swap auto,sw,pri=1 0 0 # AutoUpdate

/dev/sda3       162398208   976769023   407185408   83  Linux

Disk /dev/sdb: 160.0 GB, 160040803840 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312579695 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe735389b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048      612351      305152    7  HPFS/NTFS/exFAT
/dev/sdb2          612352   157681663    78534656    7  HPFS/NTFS/exFAT
root@porteus:~# ls /mnt/
live/
root@porteus:~# cat /etc/porteus-version 
Porteus-v1.1
root@porteus:~# uname -a
Linux porteus 3.1.0-rc10-porteus #1 SMP PREEMPT Tue Oct 18 23:00:16 UTC 2011 x86_64 AMD Phenom(tm) 8250e Triple-Core Processor AuthenticAMD GNU/Linux
I know that UFS is not supported to automount, but ntfs and ext2/ext3/ext4/xfs/reiserfs are supported, so something is not working, unless I missed something?

Code: Select all

root@porteus:~# cat /etc/fstab 
# System mounts
aufs / aufs defaults 0 0 # AutoUpdate
proc /proc proc defaults 0 0 # AutoUpdate
sysfs /sys sysfs defaults 0 0 # AutoUpdate

# Device partitions
/dev/sda1 /mnt/sda1 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda3 /mnt/sda3 ext3 auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda5 /mnt/sda5 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda7 /mnt/sda7 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda8 /mnt/sda8 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sda9 /mnt/sda9 ufs auto,noatime,users,suid,dev,exec 0 0 # AutoUpdate
/dev/sdb1 /mnt/sdb1 ntfs auto,noatime,users,suid,dev,exec,locale=utf8 0 0 # AutoUpdate
/dev/sdb2 /mnt/sdb2 ntfs auto,noatime,users,suid,dev,exec,locale=utf8 0 0 # AutoUpdate

# Swap partitions
/dev/sda2 none swap auto,sw,pri=1 0 0 # AutoUpdate

Thanks

cchuang
Black ninja
Black ninja
Posts: 33
Joined: 03 Jan 2011, 06:55
Location: Taiwan

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#14 by cchuang » 21 Oct 2011, 09:16

Hi,

Can't wait to download and test. It's great to speed up the boot time and much less size. Ii has a minor error:
libfreetype.so.6.6.2 is duplicated in 001-core and 002-xorg xzm modules.

Thanks
cch

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

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#15 by fanthom » 21 Oct 2011, 11:47

@Ahau
1) seems that i have fixed pns-tool, check out this version:
http://www.mediafire.com/?yvdutc24x3857kv
2) thanks again for Qt tip - works like a charm now

@Blaze
1) this is apparently not a good news.
need to find out why automatic detection fails in your case. could you upload /etc/X11/xorg.conf for me, please.
2) as usual for every alpha/beta/rc version LST is not ready yet. will be for FINAL.

@Hamza
new psc fails at the start:

Code: Select all

root@porteus:/home/guest/Downloads# sh psc-final_v1.1.sh 
psc-final_v1.1.sh: line 10018: `firewall-manager': not a valid identifier
@Tonio
could you post exac error or screenshot?
open pcmanfm -> Edit -> Preferences -> Volume Management -> thick on "Mount removable media when they are inserted"
does it help?
it's not enabled by default as i'm not happy with this behaviour after going back from sleep (drives gets different letters sdb becomes sdc, etc). i may enable it for rc2 - need to investigate further.

@cchuang
libfreetype.so.6.6.2 (and many other libs) are duplicated in aaa_elflibs package which belongs to 001-core.xzm.
i have writed a script which searches for duplicates across all modules so this wont be the case for next release (we can save 1MB, not much but still...)
thanks for inspiration :)

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

Locked