Porteus v5.0rc1 problems

[nanZor]

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.

[quotaholic]

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]

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...

[nanZor]

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!

[nanZor]

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.

[nanZor]

..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?

[nanZor]

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.

[nanZor]

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.

[nanZor]

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.

[nanZor]

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.

[ncmprhnsbl]

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

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..

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..

[donald]

Can we get checksums please?

[fulalas]

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
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;

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]

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]

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

This may helps: SSD Slow boot (solved)

Yes, haveged might be a good workaround if low entropy is the reason. Thanks AcnapyxoB.