Porteus-v5.01 bug reports

[Rapha_]

It is not new, but on v5.01 and LXQT Desktop :

PCManFM-QT quit when I unmount a drive
No problem, I can restart PCMan

if PCMan is open on a disk (e.g. /mnt/sda4) :

• In the command line (root) I do 'umount /mnt/sda4'. it close the PCManFM-QT Windows !

• If PCMan is open on another disk (e.g. /mnt/sda1), I can umount sda4 in the command line without without closing PCMan

from .xsession-errors log :

folder unmount
operation finished: 0x0
delete MountOperation

[Rapha_]

in Porteus boot menu

if there are many characters in Cheatcodes
the display (after the tab key) is blurred by repeating lines when the cursor is moved
which makes it difficult to edit on the fly

[Rava]

in Porteus boot menu

if there are many characters in Cheatcodes
the display (after the tab key) is blurred by repeating lines when the cursor is moved
which makes it difficult to edit on the fly

Have you tried using a different screen resolution in the boot menu?
I think the cheatcodes for changing that are generic Linux kernel cheatcodes and thus not mentioned in our Porteus cheatcodes.txt

[Rapha_]

Have you tried using a different screen resolution in the boot menu?

how can i change that ?

[Rava]

how can i change that ?

I looked it up and it seems that depends on the boot loader you use.

e.g. syslinux
https://unix.stackexchange.com/question ... resolution

e.g. grub2
https://askubuntu.com/questions/127851/ ... resolution

Via DuckDuckGo I first searched for
"different screen resolution in the boot menu linux"
and then for
"syslinux screen resolution boot menu linux"

[donald]

Have you tried using a different screen resolution in the boot menu?

how can i change that ?

Hi Rapha
may be this will help:
Regarding boot screen image and brightness (Post by donald #76990)

[Rava]

As you might know, you can use mc to open and browse archive files, like .tar, .zip and so on as long as they are unencrypted.

I now wanted to browse one such file for the first time using Port 5.01. I never encountered an issue using Port 5.0 but I rarely ever try it on .zip files, more often I encounter some .tar.* or .rar or .7z

This time it is a zip file and all I get is this error message from mc:

(I was not able to capture that error as text to simply quote it via [ code ] or [ quote ])

I presume the following happened: mc is a newer version, and they used to use bash or sh scripts to handle what they call virtual filesystems for opening such archive files.
But in this version they switched to perl.

strike-through'd since my below assumption has been proven wrong compared to Port5.0 001-core.xzm:20221211 at least. (Could be true for older Port 5.0 001-core.xzm)
Of course it would be overkill to install perl just to get that functionality of mc working again.
If my presumption is correct and it is indeed due to changes in mc, what do you thing about only reverting the parts that handle what they call virtual filesystems for opening such archive files back to the way mc handled it previously?
When I do recall correctly, these scripts are found vanilla as text files somewhere in the folders mc sets up and have been in the older versions at least not created by the compiled mc binary itself.

Info on mc as be part of 5.01

Code: Select all

root@rava:/# mc --version
GNU Midnight Commander 4.8.27
Built with GLib 2.70.1
Built with S-Lang 2.3.2 with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

According to lsxzmgrep mc is part of 001-core.xzm

Code: Select all

root@rava:/mnt/sda1/Porteus_5.0.1/porteus/base# lsxzmgrep . usr/bin/mc$
lsxzmgrep V2020-12-19
>./001-core.xzm
/usr/bin/mc

But… I mloop'd Port 5.0's 001-core.xzm and executed that version of mc:

Code: Select all

root@rava:/mnt/loop/usr/bin# ./mc --version
GNU Midnight Commander 4.8.27
Built with GLib 2.70.1
Built with S-Lang 2.3.2 with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

and it's the same version. But maybe it is because of an updated 5.0 001-core.xzm.

I now try finding the original non-updated 5.0 001-core.xzm and see if that mc differs in its version.

updated 5.0 001-core.xzm and my current 5.01 001-core.xzm /usr/bin/mc are the very same:

Code: Select all

root@rava:~# md5sum /mnt/loop/usr/bin/mc /usr/bin/mc
f28a17ff41d81b4e9f072d1014b9e3f8  /mnt/loop/usr/bin/mc
f28a17ff41d81b4e9f072d1014b9e3f8  /usr/bin/mc

and here the /etc/porteus/001-core.ver I compared:

Code: Select all

root@rava:~# head /mnt/loop/etc/porteus/001-core.ver /etc/porteus/001-core.ver
==> /mnt/loop/etc/porteus/001-core.ver <==
001-core.xzm:20221211

==> /etc/porteus/001-core.ver <==
001-core.xzm:20230922

Anyone any idea how to fix that without adding perl to my (or anyone else's) system?

Added in 8 minutes :
The culprit so to speak:

Code: Select all

root@rava:~# file /usr/libexec/mc/extfs.d/uzip 
/usr/libexec/mc/extfs.d/uzip: Perl script text executable

Some are indeed Perl script text executables while others are POSIX shell scripts, ASCII text executables:

Code: Select all

root@rava:~# file /usr/libexec/mc/extfs.d/*
/usr/libexec/mc/extfs.d/README.extfs: ASCII text
/usr/libexec/mc/extfs.d/a+:           Perl script text executable
/usr/libexec/mc/extfs.d/apt+:         Perl script text executable
/usr/libexec/mc/extfs.d/audio:        POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/bpp:          POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/changesetfs:  POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/deb:          Perl script text executable
/usr/libexec/mc/extfs.d/deba:         Perl script text executable
/usr/libexec/mc/extfs.d/debd:         Perl script text executable
/usr/libexec/mc/extfs.d/dpkg+:        Perl script text executable
/usr/libexec/mc/extfs.d/gitfs+:       POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/hp48+:        POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/iso9660:      POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/lslR:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/mailfs:       Perl script text executable
/usr/libexec/mc/extfs.d/patchfs:      Perl script text executable
/usr/libexec/mc/extfs.d/patchsetfs:   POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/rpm:          POSIX shell script, Unicode text, UTF-8 text executable
/usr/libexec/mc/extfs.d/rpms+:        Perl script text executable
/usr/libexec/mc/extfs.d/s3+:          Python script, ASCII text executable
/usr/libexec/mc/extfs.d/trpm:         POSIX shell script, ISO-8859 text executable
/usr/libexec/mc/extfs.d/u7z:          POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/uace:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/ualz:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/uar:          POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/uarc:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/uarj:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/uc1541:       Python script, ASCII text executable
/usr/libexec/mc/extfs.d/ucab:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/uha:          POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/ulha:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/ulib:         Perl script text executable
/usr/libexec/mc/extfs.d/unar:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/urar:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/uwim:         POSIX shell script, ASCII text executable
/usr/libexec/mc/extfs.d/uzip:         Perl script text executable
/usr/libexec/mc/extfs.d/uzoo:         POSIX shell script, ASCII text executable
root@rava:~# 

Added in 1 minute 50 seconds:
I wonder if out there there already exist replacements for these perl scripts: be it via python, or via POSIX shell script.

Added in 4 minutes 35 seconds:
uzip perl script is amazingly complex, I not quote it here (you can look into it on your own system if you want), I just let wc do an overview:

Code: Select all

root@rava:~# wc /usr/libexec/mc/extfs.d/uzip 
  482  2219 15263 /usr/libexec/mc/extfs.d/uzip

482 lines of code. For only opening and browsing zip-files.

Compared to a mere 135 lines ("mere" is relatively here) for the POSIX shell script that handles opening and browsing 7z files:

Code: Select all

root@rava:~# wc /usr/libexec/mc/extfs.d/u7z
 135  674 4880 /usr/libexec/mc/extfs.d/u7z

Added in 13 minutes 20 seconds:
I am not even sure what method mc uses for opening tar files but it works.

Looking for "tar " in the scripts folder:

Code: Select all

root@rava:/usr/libexec/mc/extfs.d# grep "tar " *
deb:#         (to handle new tar format)
deb:#         (to handle both new and old tar formats)
deb:#         (deal with change in tar format)
deb:			if($_[3] =~ /^\d\d\d\d\-/) { # New tar format
deb:		system("dpkg-deb --fsys-tarfile $qarchive | tar xOf - $qfilename ./$qfilename > $qdestfile 2>/dev/null");
rpm:#	2013: tar payload support.
root@rava:/usr/libexec/mc/extfs.d# 

Downloaded a small sample non compressed tar file (I was just too lazy to create one for my own, don't judge me )

Code: Select all

guest@rava:/tmp$ wget https://getsamplefiles.com/download/tar/sample-1.tar
--2023-10-27 10:33:57--  https://getsamplefiles.com/download/tar/sample-1.tar
Resolving getsamplefiles.com (getsamplefiles.com)... 68.183.46.179, 64:ff9b::44b7:2eb3
Connecting to getsamplefiles.com (getsamplefiles.com)|68.183.46.179|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1101824 (1.1M) [application/x-tar]
Saving to: ‘sample-1.tar’

sample-1.tar        100%[===================>]   1.05M  1.16MB/s    in 0.9s    

2023-10-27 10:33:58 (1.16 MB/s) - ‘sample-1.tar’ saved [1101824/1101824]

guest@rava:/tmp$ file sample-1.tar 
sample-1.tar: POSIX tar archive
guest@rava:/tmp$ mc . .

and navigated into that sample tar file:

Code: Select all

  Left     File     Command     Options     Right
╔←═ sample-1.tar/utar://sample-1 ═•[↓]→╗╔←═ /tmp ═════════════════════════•[↓]→╗
║↓n     Name      │ Size  │Modify time ║║↓n     Name      │ Size  │Modify time ║
║/..              │UP--DIR│Dec 31  2022║║/..              │UP--DIR│Oct 27 03:56║
║*sample-1.webp   │ 361666│Dec 30  2022║║/.ICE-unix       │     60│Oct 27 00:53║
║*sample-1_1.webp │ 361666│Dec 30  2022║║/.X11-unix       │     60│Oct 27 00:53║
║*sample-5 (1).jpg│ 214895│Dec 31  2022║║/basilisk_guest  │     60│Oct 27 05:43║
║*sample-5.webp   │ 159068│Dec 30  2022║║/basilisk_root   │     60│Oct 27 04:13║
║                 │       │            ║║/interlink_guest │     60│Oct 27 03:13║
╟──────────────────────────────────────╢╟──────────────────────────────────────╢
║UP--DIR                               ║║UP--DIR                               ║
╚══════════════════════════════════════╝╚════════════════════ 197M/387M (50%) ═╝
guest@rava:/tmp$                                                             [^]
 1Help   2Menu   3View   4Edit   5Copy   6RenMov 7Mkdir  8Delete 9PullDn10Quit

mc calls browsing tar files "utar" but no utar script in any of /usr/libexec/mc

Code: Select all

root@rava:/usr/libexec/mc# find . -iname "*utar*"
root@rava:/usr/libexec/mc# 

or in all of 001-core

Code: Select all

root@rava:/mnt/live/memory/images/001-core.xzm# find . -iname "*utar*"
root@rava:/mnt/live/memory/images/001-core.xzm# 

Seems mc handles tar files differently. Not that that's any helpful for solving the "mc cannot open and browse zip files" issue.

[Rapha_]

Thanks Rava and donald for the 'syslinux screen resolution boot menu' ...

Now I have to deal with the image that reduces in size when washed !

[Rava]

Now I have to deal with the image that reduces in size when washed !

You mean the background image of your bootloader?
you should be able to use one with larger resolution when you switched to a larger screen resolution. E.g. from 640x? to 1280x?
But once more, that depends on your bootloader, and what image resolutions yours supports.

Added in 5 minutes 46 seconds:
And finally a bug report
System XFCE 4.16 Porteus-v5.01:

Code: Select all

root@rava:/# cat /etc/porteus/*
001-core.xzm:20230922
002-xorg.xzm:20231001
002-xtra.xzm:20230922
003-xfce.xzm:20230922
06-man.xzm:20230915
initrd.xz:20220928

lsmodules

Code: Select all

root@rava:/# lsmodules
Traceback (most recent call last):
  File "/usr/local/bin/lsmodules", line 359, in <module>
    win = MainWindow()
  File "/usr/local/bin/lsmodules", line 158, in __init__
    self.set_modules_model()
  File "/usr/local/bin/lsmodules", line 310, in set_modules_model
    sub_dirs = next(os.walk(self.portdir_env_dir + "/optional/"))[1]
StopIteration
root@rava:/# echo $?
1
root@rava:/# head /usr/local/bin/lsmodules
#!/usr/bin/python3

## Porteus Module Activation Status
## Author: jssouza

import os
import glob
import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GdkPixbuf, Gio, GLib
root@rava:/# 

Added in 3 minutes 29 seconds:
md5sum

Code: Select all

3ade29ac512255f4be9552cdc6882ed5  /usr/bin/lsmodules

I checked it and that is the same md5sum checksum as /usr/bin/lsmodules from my 003-xfce-4.16-20230922.xzm module ( I rename my XFCE modules since there are: v4.12, v4.16 and v4.18 variants. )

[donald]

XFCE 4.16 Porteus-v5.01-x86_64

Code: Select all

guest@porteus:~$ cat /etc/porteus/*
001-core.xzm:20230922
002-xorg.xzm:20231001
002-xtra.xzm:20230922
003-xfce.xzm:20230922
initrd.xz:20230923

I don't have the issue Rava is reporting . but a different one:
Porteus Modules (lsmodules) run from (applications/system/) menu asks for authentication, but
lsmodules runs in a terminal (as guest) without auth.

3ade29ac512255f4be9552cdc6882ed5 /usr/bin/lsmodules

[Rava]

I don't have the issue Rava is reporting . but a different one:
Porteus Modules (lsmodules) run from (applications/system/) menu asks for authentication

"Porteus Modules" started like so works as intended (displaying in a GUI window the loaded modules) after asking for authentication

3ade29ac512255f4be9552cdc6882ed5 /usr/bin/lsmodules

We have the very same /usr/bin/lsmodules
I try again, once as root in terminal, once as guest in terminal.

Both result in the same errors:
as guest

Code: Select all

guest@rava:~$ lsmodules
Traceback (most recent call last):
  File "/usr/local/bin/lsmodules", line 359, in <module>
    win = MainWindow()
  File "/usr/local/bin/lsmodules", line 158, in __init__
    self.set_modules_model()
  File "/usr/local/bin/lsmodules", line 310, in set_modules_model
    sub_dirs = next(os.walk(self.portdir_env_dir + "/optional/"))[1]
StopIteration
guest@rava:~$ 

And as donald reported above: my lsmodules when started as guest in terminal also not asked for authentication.

as root

Code: Select all

root@rava:~# lsmodules
Traceback (most recent call last):
  File "/usr/local/bin/lsmodules", line 359, in <module>
    win = MainWindow()
  File "/usr/local/bin/lsmodules", line 158, in __init__
    self.set_modules_model()
  File "/usr/local/bin/lsmodules", line 310, in set_modules_model
    sub_dirs = next(os.walk(self.portdir_env_dir + "/optional/"))[1]
StopIteration
root@rava:~#

Could be that my activated 021-libgtk+libgdk-x11-2.0.so.0.2400.33.xzm is causing an issue here?

[donald]

"Porteus Modules" started like so works as intended (displaying in a GUI window the loaded modules) after asking for authentication

IMO it should ask for authentication when one actually activate a module,
not when launching the GUI.
Could be that I just want to have an overview of what modules are currently running -
So why to auth at this stage?

I try again, once as root in terminal, once as guest in terminal.
Both result in the same errors
Could be that my activated 021-libgtk+libgdk-x11-2.0.so.0.2400.33.xzm is causing an issue here?

Could be, try in 'always fresh'

[Rava]

IMO it should ask for authentication when one actually activate a module,
not when launching the GUI.

I agree.

Could be, try in 'always fresh'

would that work when I shove all my modules into base/ not just the typical base/ ones?

[donald]

Could be, try in 'always fresh'

would that work when I shove all my modules into base/ not just the typical base/ ones?

That's a rhetorical question,no? - I assume you know what 'always fresh' means.

....at least my gtk2-debs-x86_64.xzm [ description here: ]
[Solved] Scrollbar hardly visible: GTK2 program in XFCE 4.16 and Port 5.0 or 5.0.1 and standard dark theme (Post by donald #96365)
does not cause those errors.

[Rava]

That's a rhetorical question,no? - I assume you know what 'always fresh' means.

I know in theory, but the cheatcodes text is vague:

Code: Select all

nomagic

   ... Do not bind "magic folders" during boot time. Useful when
       something went wrong with your Porteus configuration and you
       want to boot into true 'Always Fresh' mode.

Since all my always used modules are in base/ and not in modules/ or /optional - would nomagic load these or not?
BTW, "magic folder" is only mentioned in the above quote and nowhere else to be found in cheatcodes.txt (that I renamed into cheatcodes5.01.txt)

and grep -iC 3 "Always fresh" cheatcodes5.01.txt not reveals anything more helpful.

Added in 3 minutes 44 seconds:
and search for base_only:

Code: Select all

base_only

   ... This cheatcode will prevent the system from loading any
       modules at startup other than the 'base' modules included
       with the default ISO (000-kernel.xzm, 001-core.xzm, etc).
       This is useful in debugging to see if problems you are
       having are associated with some module you've added to the
       system.

Will that load all that is in base/ - in my case, all the modules?
Or just e.g 001-* 002-* 003-* modules from base/ ?

Or only modules like 000-kernel.xzm 001-core.xzm 002-xorg.xzm 002-xtra.xzm 003-xfce.xzm

In which case I would end up with a non-existing DE since I renamed my xfce module into 003-xfce-4.16-20230922.xzm

Added in 1 day 7 hours 35 seconds:
Just one minor thingy:
Why does 006-man.xzm not contain an offline version of the notify-send manpage?
Instead the online version is loaded even when 006-man.xzm is activated.