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.
User avatar
Rava
Contributor
Contributor
Posts: 2682
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 5.0rc1 x86-64 XFCe
Location: Forests of Germany

Porteus v5.0rc1 problems

Post#196 by Rava » 04 Nov 2020, 00:19

Porteus 5.0rc1 x86-64 XFCe

Code: Select all

guest@porteus:/$ mpv "/sound/S.aac"
[ffmpeg/demuxer] aac: Estimating duration from bitrate, this may be inaccurate
 (+) Audio --aid=1 (aac 2ch 44100Hz)
AO: [pulse] 44100Hz stereo 2ch float
A: 00:00:56 / 00:02:29 (37%) Cache: 91s/3MB
All is well.

Code: Select all

guest@porteus:/$ mpg123 "/sound/Fischer-Z Luton To Lisbon.mp3"
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
	version 1.25.13; written and copyright by Michael Hipp and others
	free software (LGPL) without any warranty but with best wishes

Directory: /sound/

Terminal control enabled, press 'h' for listing of keys and functions.

Playing MPEG stream 1 of 1: Fischer-Z Luton To Lisbon.mp3 ...

MPEG 1.0 L III vbr 44100 j-s

Title:   luton to lisbon                 Artist: Fischer-Z                      

[1:56] Decoding of Fischer-Z Luton To Lisbon.mp3 finished.
All is well.

Code: Select all

root@porteus:/# sudo -u guest mpg123 "/sound/Fischer-Z Luton To Lisbon.mp3"
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
	version 1.25.13; written and copyright by Michael Hipp and others
	free software (LGPL) without any warranty but with best wishes
Segmentation fault
Always segfault when trying to run it via sudo -u guest; always working okay when running native as guest.

Code: Select all

root@porteus:/# sudo -u guest mpv "/sound/S.aac"
[ffmpeg/demuxer] aac: Estimating duration from bitrate, this may be inaccurate
 (+) Audio --aid=1 (aac 2ch 44100Hz)
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused

[ao/alsa] Playback open error: Connection refused
[ao/oss] Can't open audio device /dev/dsp: No such file or directory
[ao] Failed to initialize audio driver 'oss'
Could not open/initialize audio device -> no sound.
Audio: no audio


Exiting... (Errors when loading file)
"Failed to initialize audio driver 'oss' -- Could not open/initialize audio device -> no sound." Fails when trying sudo -u guest mpv

native guest mpv working okay.

Why is that? sudo -u guest should run the program as if guest ran it natively. Still, it always fails when trying it the sudo -u guest way, either by segfault, or by claiming "Failed to initialize audio driver 'oss' -- Could not open/initialize audio device -> no sound." even when in both cases the exact same program and sound file ran natively by guesting work okay.

Me thinks that must be some kind of setup issue with the 5.0rc1 sudo.
Cheers!
Yours Rava

User avatar
clarkjohannes
Ronin
Ronin
Posts: 3
Joined: 31 Oct 2020, 12:58
Distribution: Porteus

Porteus v5.0rc1 problems

Post#197 by clarkjohannes » 08 Nov 2020, 03:13

Bad news, my 4GB SD card won't boot Porteus 5.0rc1 anymore. Downgrade to Porteus 4.0 LX QT Pi and it works like a charm. Hope this project is doing well! :D :Bravo:

User avatar
Ed_P
Contributor
Contributor
Posts: 5797
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 & 5.0rc2 Cinnamon 64 ISOs
Location: Western NY, USA

Porteus v5.0rc1 problems

Post#198 by Ed_P » 08 Nov 2020, 06:09

Thanks for the update clark. 4.0 is a good release. It is my main one still.
Ed

User avatar
Rava
Contributor
Contributor
Posts: 2682
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 5.0rc1 x86-64 XFCe
Location: Forests of Germany

Porteus v5.0rc1 problems

Post#199 by Rava » 08 Nov 2020, 11:36

No one got any idea how to proceed debugging my no mpv / no mpg123 for root via su, even when the native ran by guest mpv/mpg123 works fine as described here: Porteus v5.0rc1 problems (Post by Rava #79417)

I cannot simple add a 4.0 to my sda1: (about dx see [1] below)

Code: Select all

root@porteus:/mnt/sda1# dx  /mnt/sda1
08.11.2020 12:24:50 ____________________________________________________________
Filesystem     Type    1M-blocks  Used Available Use% Mounted on
/dev/sda1      fuseblk      1500  1408        93  94% /mnt/sda1
I presume I could remove /mnt/sda1/Porteus_4.0/porteus and replace it with a symlink. The 4.0 kernels would still be on sda1, but all the rest elsewhere. That would work, yes?

_________________
[1]
dx is basically /bin/df -Tm $* | grep -vE 'tmpfs|/mnt/live/run|squashfs' plus the date+time separator line. Main goal is, since it is dfree giving all the squashfs modules as results, when none ever can hold even a single additional bit, is quite contra-intuitive for why folks use df (e.g. to see which partitions runs out of space on an what partition I still can download the Live-Linux DVD to)
Cheers!
Yours Rava

User avatar
Rava
Contributor
Contributor
Posts: 2682
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 5.0rc1 x86-64 XFCe
Location: Forests of Germany

Porteus v5.0rc1 problems

Post#200 by Rava » 18 Nov 2020, 01:43

less a problem, more an observation I am curious about:

I changed the way youtube-dl is put into the base/ folder.
I was tired of the need to create a new symlink every time yt-dl got updated.

So I created on the Linux partition that holds the modules and also is the place where I create these (since sda1 is NTFS due to its being the SM-Witless-7 hidden boot partition but I use it to host all my real grown-ups OS like Porteus and Puppy)
So instead on sda1 is a symlink linking to the ext3 partition symlink named simply 031-youtube-dl-recent.xzm, which is also a symlink pointing to the most recent yt-dl version.
You might ask, why is that easier to handle? Easy, since I am already in that very folder on the ext3 Partition creating the most recent yt-dl module, so also doing a

Code: Select all

ln -sf 031-youtube-dl-2020.11.18-noarch-rava.xzm 031-youtube-dl-recent.xzm
is a quick fix - since alternately I would have to go to the correct sda1 Porteus base folder and also add the full path to 031-youtube-dl-2020.11.18-noarch-rava.xzm there.

Sadly, I still got no answer to my question where to find the yt-dl update-script from 5.0rc2 so I still manually update yt-dl and manually create the most recent version.
After deactivating the activated yt-dl module from /mnt/live/memory/images I moved back to the ext3 folder via root terminal and manually activated the 031-youtube-dl-recent.xzm symlink.
Checking the results in /mnt/live/memory/images I was astonished that the activate script saw through my symlink shenanigans and there the yt-dl module is named as its real name:

Code: Select all

root@porteus:/mnt/live/memory/images# file 031-youtube-dl-2020.11.18-noarch-rava.xzm/
031-youtube-dl-2020.11.18-noarch-rava.xzm/: directory
Was this "resolving symlinks to its physical real named module" always part of Porteus or is that a new feature since 5.0rc1?
Cheers!
Yours Rava

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

Porteus v5.0rc1 problems

Post#201 by donald » 18 Nov 2020, 17:06

^
Hmmm...wait,what?...and why?
I store youtube-dl in /usr/local/bin/
and run its upgrade command from time to time [youtube-dl -U]
...done.

User avatar
Rava
Contributor
Contributor
Posts: 2682
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 5.0rc1 x86-64 XFCe
Location: Forests of Germany

Porteus v5.0rc1 problems

Post#202 by Rava » 18 Nov 2020, 21:05

donald wrote:
18 Nov 2020, 17:06
I store youtube-dl in /usr/local/bin/
and run its upgrade command from time to time [youtube-dl -U]
...done.
that only works when your system auto-saves changes I presume.
Cheers!
Yours Rava

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

Porteus v5.0rc1 problems

Post#203 by donald » 18 Nov 2020, 23:32

Rava wrote:
18 Nov 2020, 21:05
that only works when your system auto-saves changes I presume.
Generally yes.

My system doesn't save changes automatically.
Once configured, it is read-only. [changes-ro]
When I want to save changes that have been found useful,
I am temporarily removing the cheat code on the splash screen [TAB] for this task.

I don't know if changes-ro work on port_5 -- I'm not using it
because of the NVIDIA drama - you know what I'm talking about.

Another approach could be to make use of rootcopy.

User avatar
Rava
Contributor
Contributor
Posts: 2682
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 5.0rc1 x86-64 XFCe
Location: Forests of Germany

Porteus v5.0rc1 problems

Post#204 by Rava » 19 Nov 2020, 12:39

donald wrote:
18 Nov 2020, 23:32
I don't know if changes-ro work on port_5 -- I'm not using it
because of the NVIDIA drama - you know what I'm talking about.
Do I? I use 5.0rc1 with changed kernel and 010-nvidia-340.108-k.5.4.30-porteus-v5.0-x86_64_rava.xzm driver.
donald wrote:
18 Nov 2020, 23:32
Another approach could be to make use of rootcopy.
That is my approach, but most my stuff is in a module called 991-usr_local_binV2020-03-20.xzm which I update from time to time, meaning I move stuff from rootcopy into a updated 991-usr_local_bin module and rename the date name part accordingly.
Cheers!
Yours Rava

User avatar
Rava
Contributor
Contributor
Posts: 2682
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 5.0rc1 x86-64 XFCe
Location: Forests of Germany

Porteus v5.0rc1 problems

Post#205 by Rava » 19 Nov 2020, 19:20

update-chrome fails in rc1:

Code: Select all

# update-chrome --target .
 Starting checks ... 
[OK] User is root.
[OK] Distro is Porteus
Downloading live script ...
Downloading: update-chrome-live  DONE
/usr/local/bin/update-chrome-live: line 429: shift: 2: shift count out of range
Makeself version 2.4.2
 1) Getting help or info about /usr/local/bin/update-chrome-live :
  /usr/local/bin/update-chrome-live --help   Print this message
  /usr/local/bin/update-chrome-live --info   Print embedded info : title, default target directory, embedded script ...
  /usr/local/bin/update-chrome-live --lsm    Print embedded lsm entry (or no LSM)
  /usr/local/bin/update-chrome-live --list   Print the list of files in the archive
  /usr/local/bin/update-chrome-live --check  Checks integrity of the archive

 2) Running /usr/local/bin/update-chrome-live :
  /usr/local/bin/update-chrome-live [options] [--] [additional arguments to embedded script]
  with following options (in that order)
  --confirm             Ask before running embedded script
  --quiet               Do not print anything except error messages
  --accept              Accept the license
  --noexec              Do not run embedded script (implies --noexec-cleanup)
  --noexec-cleanup      Do not run embedded cleanup script
  --keep                Do not erase target directory after running
                        the embedded script
  --noprogress          Do not show the progress during the decompression
  --nox11               Do not spawn an xterm
  --nochown             Do not give the target folder to the current user
  --chown               Give the target folder to the current user recursively
  --nodiskspace         Do not check for available disk space
  --target dir          Extract directly to a target directory (absolute or relative)
                        This directory may undergo recursive chown (see --nochown).
  --tar arg1 [arg2 ...] Access the contents of the archive through the tar command
  --ssl-pass-src src    Use the given src as the source of password to decrypt the data
                        using OpenSSL. See "PASS PHRASE ARGUMENTS" in man openssl.
                        Default is to prompt the user to enter decryption password
                        on the current terminal.
  --cleanup-args args   Arguments to the cleanup script. Wrap in quotes to provide
                        multiple arguments.
  --                    Following arguments will be passed to the embedded script
Running it without --target also fails:

Code: Select all

# update-chrome
 Starting checks ... 
[OK] User is root.
[OK] Distro is Porteus
Downloading live script ...
Downloading: update-chrome-live  DONE
Verifying archive integrity...  100%   MD5 checksums are OK. All good.
Uncompressing update-chrome-live  100%  
Work will be done in:  /tmp 
 There's not enough space to run this script 
Even running the just downloaded update-chrome-live itself fails:

Code: Select all

# update-chrome-live  --target .
Verifying archive integrity...  100%   MD5 checksums are OK. All good.
Uncompressing update-chrome-live  100%  
Work will be done in:  /tmp 
 There's not enough space to run this script 
The script help says

Code: Select all

  --target dir          Extract directly to a target directory (absolute or relative)
so "." for current directory on an ext3 partition with enough free space should work… but sadly does not.


Is there a fix?

Update
My feeble attempt in hacking update-chrome-live by copying it to update-chrome-live2 and exchanging

Code: Select all

TMPROOT=${TMPDIR:=/tmp}
into

Code: Select all

TMPROOT=/ext3/folder/with-enough-free-space
sadly utterly failed: it still tries to use /tmp :cry:

Any idea why that is?
Is the plain text code overwritten by the binary part?
Cheers!
Yours Rava

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

Porteus v5.0rc1 problems

Post#206 by ncmprhnsbl » 19 Nov 2020, 22:11

Rava wrote:
19 Nov 2020, 19:20
update-chrome fails in rc1:
(if lacking ram space)
use the -d option(with no args) and it will ask you where you want the work to be done. this was the simplest (for me) workaround for the makself packed scripts(chrome and chromium).
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
Rava
Contributor
Contributor
Posts: 2682
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 5.0rc1 x86-64 XFCe
Location: Forests of Germany

Porteus v5.0rc1 problems

Post#207 by Rava » 20 Nov 2020, 03:32

ncmprhnsbl wrote:
19 Nov 2020, 22:11
use the -d option(with no args) and it will ask you where you want the work to be done. this was the simplest (for me) workaround for the makself packed scripts(chrome and chromium).
Could you then please change the help text for chrome and chromium that it no longer states --target dir Extract directly to a target directory (absolute or relative)? That would be great.

And once again: thanks a bunch for the amazing work you do with these scripts/makeself.

Code: Select all

# update-chrome -d
 Starting checks ... 
[OK] User is root.
[OK] Distro is Porteus
Downloading live script ...
Downloading: update-chrome-live  DONE
Unrecognized flag : -d
Seems my update-chrome from 5.0rc1 is not up to date.

What do you think of adding version numbering to all update-* scripts/makeselves?
A simple V2020-11-19 would do the trick.

And such version numbering could even implemented automatically via scripting. :) (Unless you would release more than one version of one script per day.)

UPDATE

Code: Select all

root@porteus:/1/Porteus_5.0rc2/porteus/base# ls
000-kernel.xzm
001-core.xzm
002-xorg.xzm
002-xtra.xzm
003-xfce.xzm
009-pscripts-RC2-20201116.xzm
root@porteus:/1/Porteus_5.0rc2/porteus/base# lsxzm * |grep update-chrome
Why no results for update-chrome in all of 5.0rc2 modules? O__o

By the same lsxzm * |grep update-chrome technique there is also no update-chrome to be found in 5.0rc1, but the script is definitely there.
Is there a bug in lsxzm?
Or is lsxzm only processing the first file?

UPDATE 2
Seems the above 2nd reason is true:

Code: Select all

root@porteus:/mnt/live/memory/images# find .|grep update-chrome
./002-xorg.xzm/opt/porteus-scripts/update-chrome
./002-xorg.xzm/usr/bin/update-chrome
UPDATE 3

Code: Select all

root@porteus:/# cd /1/Porteus_5.0rc2/porteus/base/
root@porteus:/1/Porteus_5.0rc2/porteus/base# lsxzm 002-xorg.xzm |grep update-chrome
root@porteus:/1/Porteus_5.0rc2/porteus/base# lsxzm 002-xtra.xzm |grep update-chrome
root@porteus:/1/Porteus_5.0rc2/porteus/base# lsxzm 009-pscripts-RC2-20201116.xzm |grep update-chrome
root@porteus:/1/Porteus_5.0rc2/porteus/base# cd /1/Porteus_5.0rc1/porteus/base/
root@porteus:/1/Porteus_5.0rc1/porteus/base# lsxzm 002-xorg.xzm |grep update-chrome
/opt/porteus-scripts/update-chrome
/usr/bin/update-chrome
Where is the update-chrome hidden in 5.0rc2?
Last edited by Rava on 20 Nov 2020, 03:53, edited 2 times in total.
Reason: update
Cheers!
Yours Rava

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

Porteus v5.0rc1 problems

Post#208 by ncmprhnsbl » 20 Nov 2020, 04:14

Rava wrote:
20 Nov 2020, 03:32
Could you then please change the help text for chrome and chromium that it no longer states --target dir Extract directly to a target directory (absolute or relative)? That would be great.
no, because when you run update-chrome/chromiun-live --help directly, like you did, you get the makeself help, not anything i've scripted.
Rava wrote:
20 Nov 2020, 03:32
Seems my update-chrome from 5.0rc1 is not up to date.
yep.. remember this conversation? RIAA has done a dmca takedown on youtube-dl source.. (Post by ncmprhnsbl #79805)
or change line 64 of update-chrome to: /usr/local/bin/update-chrome-live -- $1
Rava wrote:
20 Nov 2020, 03:32
Where is the update-chrome hidden in 5.0rc2?
remember this conversation? RIAA has done a dmca takedown on youtube-dl source.. (Post by ncmprhnsbl #79805)

Code: Select all

mnt/sdb1/porteus/base# lsxzm 002-xorg* | grep update-browser
/opt/porteus-scripts/update-browser
/usr/bin/update-browser
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
Rava
Contributor
Contributor
Posts: 2682
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 5.0rc1 x86-64 XFCe
Location: Forests of Germany

Porteus v5.0rc1 problems

Post#209 by Rava » 20 Nov 2020, 18:23

Code: Select all

update-browser -c -d
wrong.


correct syntax:

Code: Select all

update-browser -d -c
:D

Added in 1 hour 10 minutes 51 seconds:
chromium has locales for de and en-GB,
while gøøgle-chrøme seems to lack both:

Code: Select all

Choose a locale from the list.
All other locales will be removed.
1) am	    10) es	19) hr	    28) ml	37) ru	    46) tr
2) ar	    11) es-419	20) hu	    29) mr	38) sk	    47) uk
3) bg	    12) et	21) id	    30) ms	39) sl	    48) vi
4) bn	    13) fi	22) it	    31) nb	40) sr	    49) zh-CN
5) ca	    14) fil	23) ja	    32) nl	41) sv	    50) zh-TW
6) cs	    15) fr	24) kn	    33) pl	42) sw
7) da	    16) gu	25) ko	    34) pt-BR	43) ta
8) el	    17) he	26) lt	    35) pt-PT	44) te
9) en-US    18) hi	27) lv	    36) ro	45) th
#? 
WTF gøøgle-chrøme? No German aka de locale?

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

Porteus v5.0rc1 problems

Post#210 by ncmprhnsbl » 20 Nov 2020, 21:42

Rava wrote:
20 Nov 2020, 19:33
WTF gøøgle-chrøme? No German aka de locale?
apparently not , when the script was written :D .. there is now: de, en-GB, and fa(farsi) ... fixed on our server, mirrors will update some time later...
thanks for reporting :)
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

Post Reply