Porteus v5.0rc1 problems

Please reproduce your error on a second machine before posting, and check the error by running without saved changes or extra modules (See FAQ No. 13, "How to report a bug"). For unstable Porteus versions (alpha, beta, rc) please use the relevant thread in our "Development" section.
nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#16 by nanZor » 17 Jun 2019, 20:49

SAVEFILE.dat creation at end of process..

Using the built-in savefile tool, at the end of the process it just brings up mousepad with an empty file...

I know where to put my cheatcodes so it isn't a problem, but just a heads up.
That's a UNIX book - cool. -Garth

quotaholic
Black ninja
Black ninja
Posts: 75
Joined: 15 May 2011, 16:20
Location: denver
Contact:

Porteus v5.0rc1 problems

Post#17 by quotaholic » 17 Jun 2019, 20:51

root@porteus:/home/guest/dkms# installpkg /tmp/usm/dkms-2.2.0.3-x86_64-1_slack.txz
Verifying package dkms-2.2.0.3-x86_64-1_slack.txz.
xz: (stdin): File format not recognized
Unable to install /tmp/usm/dkms-2.2.0.3-x86_64-1_slack.txz: tar archive is corrupt (tar returned error code 2)
root@porteus:/home/guest/dkms#

nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#18 by nanZor » 17 Jun 2019, 21:07

Wireless Connection Notification

LOVE 5.0 RC1, just picking off the low-hanging fruit ...

When a wireless connection is made, there is no notification that it has done so if the system is set to automatically connect. Or upon manual disconnect and reconnect.

Probably not a bug, but a cosmetic decision? No biggie, just picking off slight changes from before...
That's a UNIX book - cool. -Garth

nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#19 by nanZor » 17 Jun 2019, 21:11

Intel Atom cpu idle states ..

More of a non-bug! Formerly with earlier kernels, I had to use the cheatcode intel_idle.max_cstate=0/1 to prevent a frequent system lockup at boot.

Not any more. System boots stable and that cheatcode isn't necessary - just a tip for Intel Atom users who have this cheatcode memorized. With RC1, you may not need it. Thanks guys!
That's a UNIX book - cool. -Garth

nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#20 by nanZor » 17 Jun 2019, 21:34

Busybox VI editor bugs / solution

Ok, so not truly a Porteus bug, BUT since we rely on the vi editor from it - the latest version of BB 1.31.0 has fixed a few bugs in the vi editor (amongst other utils).

While widescale adoption of the latest BB may not be in the cards, one can pick off the latest vi as an applet (or create just that one). Currently 1.31.0 is in the unstable category, but stable usually follows rather quickly.

Something to keep an eye on. Not a showstopper as I can always run BB as a user with the latest if I so wish.
That's a UNIX book - cool. -Garth

nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#21 by nanZor » 17 Jun 2019, 22:29

brokenman wrote:
17 Jun 2019, 18:37
..snip..
@nanZor you can invoke a su GUI by using pkexec. Even better use our own script.
/opt/porteus-scripts/org/psu /usr/bin/gparted (psu is porteus su)
..snip..
Oops - the script for the live-usb complains with: "Error: Illegal ISO File"

when I try to burn the 5.0 RC1 iso to a usb stick. Maybe because the rc iso is now a hybrid?
That's a UNIX book - cool. -Garth

nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#22 by nanZor » 17 Jun 2019, 23:07

XFCE4 - sluggish external volume mounting

Noticed that after boot, if an sda device like a vfat usb stick is inserted into the system, XFCE4 recognizes the device, but will take up to 20 seconds or so to actually mount it once your initiate a mount with a right click.

Also noticed that this non-bootable stick will also cause a major delay when displaying the beautiful boat background image if booted up with it inserted. Tested the same with other sda / sticks.

Commandline mounting? - no delay.
That's a UNIX book - cool. -Garth

nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#23 by nanZor » 18 Jun 2019, 00:48

USM GUI - Duplicate Ponce settings / conflict

XFCE4 here - noticed that when you run the USM gui, i noticed TWO setups for editing the Ponce repo. USM > Settings > Edit Ponce Mirror

The first one is correct, but the second Ponce entry points to Slackonly. You don't want to comment that out, since it will affect Slackonly. Not sure if this is a conflict or cosmetic thing.
That's a UNIX book - cool. -Garth

nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#24 by nanZor » 18 Jun 2019, 01:29

Porteus Modules inactive in XFCE4

Running System > Porteus Modules and then authenticating as toor results in nothing happening.

I'm not picking on anyone, just hitting up the low-hanging stuff.
That's a UNIX book - cool. -Garth

nanZor
Samurai
Samurai
Posts: 169
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

Porteus v5.0rc1 problems

Post#25 by nanZor » 18 Jun 2019, 02:04

Porteus Updater via Settings Centre

Hi - me again. :)

This is only RC, but the following may not be a good idea right now...

Porteus Updater > Porteus Settings Centre > Update Porteus Now icon

For me, this results in 001-core-xzm and 002-core.xzm being candidates for update. If you allow the updater to finish, and reboot the machine (savefile or other filesystem active of course), I'm not sure if these are truly updates to the RC.

Even so, when you run the updater utility again just for kicks, it wants to update 001 and 002-core.xzm all over again.

I might back these updates out since we're rc, but wanted to point out the behaviour of it.
That's a UNIX book - cool. -Garth

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2054
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

Porteus v5.0rc1 problems

Post#26 by ncmprhnsbl » 18 Jun 2019, 04:07

nanZor wrote:
17 Jun 2019, 23:07
Noticed that after boot, if an sda device like a vfat usb stick is inserted into the system, XFCE4 recognizes the device, but will take up to 20 seconds or so to actually mount it once your initiate a mount with a right click.

Also noticed that this non-bootable stick will also cause a major delay when displaying the beautiful boat background image if booted up with it inserted. Tested the same with other sda / sticks.

Commandline mounting? - no delay.
and i've noticed that fat32 partitions, that are already mounted at boot, take a while to come up in the filemanager(any) the first time(after that they are quick)
suspects: udev ,udisks, or my favourite: gvfs
nanZor wrote:
17 Jun 2019, 22:29
Oops - the script for the live-usb complains with: "Error: Illegal ISO File"
it has a function:

Code: Select all

checkISO()
{
if [ -n "$ISONOCK" ]
then
	return 0
fi
file $ISO_FILE | grep -q -e 'ISO 9660 CD-ROM'
}
file <ISO> returns:

Code: Select all

$ file Porteus-OPENBOX-v5.0rc1-x86_64.iso
Porteus-OPENBOX-v5.0rc1-x86_64.iso: DOS/MBR boot sector; partition 1 : ID=0x17, active, start-CHS (0x0,0,1), end-CHS (0x125,63,32), startsector 0, 602112 sectors
so fails..
i don't think there's any reason the hybrid iso can't be used by the script, since it's just loop mounted and the files are copied to the target usb partition..
nanZor wrote:
18 Jun 2019, 02:04
Porteus Updater > Porteus Settings Centre > Update Porteus Now icon
For me, this results in 001-core-xzm and 002-core.xzm being candidates for update. If you allow the updater to finish, and reboot the machine (savefile or other filesystem active of course), I'm not sure if these are truly updates to the RC.
yeah, that's a bug i think, since the 'updates' on the server are from may, the updater should figure that they're not updates..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

donald
Full of knowledge
Full of knowledge
Posts: 1511
Joined: 17 Jun 2013, 13:17
Distribution: Porteus 3.2.2 XFCE 32bit
Location: Germany

Porteus v5.0rc1 problems

Post#27 by donald » 18 Jun 2019, 07:43

Can we get checksums please?

fulalas
DEV Team
DEV Team
Posts: 1380
Joined: 26 Oct 2016, 15:34
Distribution: Porteus
Location: Brazil

Porteus v5.0rc1 problems

Post#28 by fulalas » 18 Jun 2019, 12:37

nanZor wrote:
17 Jun 2019, 07:44
Video just stays black until I move and click the mouse
I can reproduce this issue in one of my machines. In my case I found out somethings:

1- reverting kernel module to Porteus 4 this doesn't happen;
2- my Porteus is running from a SSD; if I boot from a USB stick this doesn't happen;
3- using LXDE this doesn't happen :unknown:
4- I read that you suspect that this is related to the wireless card, and, yes, I'm using one but I haven't tried booting without it;
nanZor wrote:
17 Jun 2019, 07:44
Running System > Porteus Modules and then authenticating as toor results in nothing happening.
Thanks. It's fixed for the final release. We're not providing Porteus Modules app anymore.

AcnapyxoB
White ninja
White ninja
Posts: 21
Joined: 24 Dec 2014, 10:15
Distribution: 4.0 XFCE x64
Location: Bulgaria

Porteus v5.0rc1 problems

Post#29 by AcnapyxoB » 18 Jun 2019, 14:49

nanZor wrote:
17 Jun 2019, 07:44
Video just stays black until I move and click the mouse - only on one box out of the 4 I am testing with.

I noticed that the video autoconfiguration takes a bit longer than usual on my 4 machines. But on one older Intel computestick that used to run Win 8.1 (circa 2015), after the initial boot, the screen stays dark forever.

UNTIL, I click and move the mouse to make it start thinking. After that, the screen gets autoconfigured and works. Again, only one machine, the older computestick, exhibits this seemingly endless black video delay until I tickle the mouse.

Note: This is unrelated to the older known issue of Intel Atom cpu's needing the special intel_idle.max_cstate=1 cheatcode.
This may helps: SSD Slow boot (solved)

jssouza
DEV Team
DEV Team
Posts: 961
Joined: 09 Jul 2015, 14:17
Distribution: Porteus x86 arm
Location: Liechtenstein

Porteus v5.0rc1 problems

Post#30 by jssouza » 19 Jun 2019, 01:02

nanZor wrote:
17 Jun 2019, 07:44
Video just stays black until I move and click the mouse
Moving the mouse increases the kernel's entropy. Check from a VT (before moving the mouse) if the available entropy is low.

Code: Select all

cat /proc/sys/kernel/random/entropy_avail
AcnapyxoB wrote:
18 Jun 2019, 14:49
This may helps: SSD Slow boot (solved)
Yes, haveged might be a good workaround if low entropy is the reason. Thanks AcnapyxoB.

Post Reply