Page 14 of 15
Porteus v5.0rc1 problems
Posted: 04 Nov 2020, 00:19
by Rava
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.
Porteus v5.0rc1 problems
Posted: 08 Nov 2020, 03:13
by clarkjohannes
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!
Porteus v5.0rc1 problems
Posted: 08 Nov 2020, 06:09
by Ed_P
Thanks for the update clark. 4.0 is a good release. It is my main one still.
Porteus v5.0rc1 problems
Posted: 08 Nov 2020, 11:36
by Rava
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 d
free 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)
Porteus v5.0rc1 problems
Posted: 18 Nov 2020, 01:43
by Rava
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?
Porteus v5.0rc1 problems
Posted: 18 Nov 2020, 17:06
by donald
^
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.
Porteus v5.0rc1 problems
Posted: 18 Nov 2020, 21:05
by Rava
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.
Porteus v5.0rc1 problems
Posted: 18 Nov 2020, 23:32
by donald
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.
Porteus v5.0rc1 problems
Posted: 19 Nov 2020, 12:39
by Rava
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.
Porteus v5.0rc1 problems
Posted: 19 Nov 2020, 19:20
by Rava
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
into
Code: Select all
TMPROOT=/ext3/folder/with-enough-free-space
sadly utterly failed: it still tries to use /tmp
Any idea why that is?
Is the plain text code overwritten by the binary part?
Porteus v5.0rc1 problems
Posted: 19 Nov 2020, 22:11
by ncmprhnsbl
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).
Porteus v5.0rc1 problems
Posted: 20 Nov 2020, 03:32
by Rava
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.)
UPDATECode: 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?
Porteus v5.0rc1 problems
Posted: 20 Nov 2020, 04:14
by ncmprhnsbl
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
Porteus v5.0rc1 problems
Posted: 20 Nov 2020, 18:23
by Rava
wrong.
correct syntax:
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?
Porteus v5.0rc1 problems
Posted: 20 Nov 2020, 21:42
by ncmprhnsbl
Rava wrote: ↑20 Nov 2020, 19:33
WTF gøøgle-chrøme? No German aka de locale?
apparently not , when the script was written
.. there is now: de, en-GB, and fa(farsi) ... fixed on our server, mirrors will update some time later...
thanks for reporting