Porteus-v5.01 bug reports

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: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Porteus-v5.01 bug reports

Post#136 by Rava » 19 Nov 2023, 13:19

ncmprhnsbl wrote:
19 Nov 2023, 12:41
if you already use a custom rc.FireWall, be sure to compare and combine.
I do, but I am not sure what the differences from lines 49c49 and 62c62 and 84x87 are about.
Via

Code: Select all

diff -y /mnt/loop/etc/rc.d/rc.FireWall /mnt/live/memory/images/001-core.xzm/etc/rc.d/rc.FireWall
these lines are marked with a "|" but man diff not tells me what a "|" in diff -y mode (aka side-by-side-comparison) is meant to mean.

I think in one version, there is also either a tab or several whitespaces inserted at that line, and in the other version there is/are not.
Basically, the differences with these 3 lines ( 49c49 and 62c62 and 84x87 ) can all be ignored, correct?

Code: Select all

root@rava:~# diff /mnt/loop/etc/rc.d/rc.FireWall /mnt/live/memory/images/001-core.xzm/etc/rc.d/rc.FireWall 
49c49
< 
---
>    
62c62
< 
---
>    
75a76,78
>    
>    # ssh?
>    $IPTABLES -A OUTPUT -p tcp --sport 1024:65535 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
84c87
< 
---
>    
root@rava:~# 
Added in 6 minutes 47 seconds:
There is still one nitpick:
it still states

Code: Select all

# usage: rc.firewall start|stop|status
when that should read:

Code: Select all

# usage: rc.FireWall start|stop|status
:)

Added in 30 minutes 43 seconds:
Another thing, is /opt/porteus-scripts/gtk-firewall only able to be started when activated via a module? Or copied to /opt/porteus-scripts/
Because my mloop'd version fails:

Code: Select all

root@rava:~# /mnt/loop/opt/porteus-scripts/gtk-firewall 
checkbox was turned on
Traceback (most recent call last):
  File "/mnt/loop/opt/porteus-scripts/gtk-firewall", line 167, in on_button5_toggled
    self.status_bar_on()
  File "/mnt/loop/opt/porteus-scripts/gtk-firewall", line 90, in status_bar_on
    return self.status_bar.push(1, "FIREWALL STATUS: ON | MODE: " + self.fw_mode())
AttributeError: 'GtkFireW' object has no attribute 'status_bar'
Traceback (most recent call last):
  File "/mnt/loop/opt/porteus-scripts/gtk-firewall", line 177, in <module>
    win = GtkFireW()
  File "/mnt/loop/opt/porteus-scripts/gtk-firewall", line 74, in __init__
    self.status_bar_on()
  File "/mnt/loop/opt/porteus-scripts/gtk-firewall", line 90, in status_bar_on
    return self.status_bar.push(1, "FIREWALL STATUS: ON | MODE: " + self.fw_mode())
  File "/mnt/loop/opt/porteus-scripts/gtk-firewall", line 106, in fw_mode
    return fmode
UnboundLocalError: local variable 'fmode' referenced before assignment
root@rava:~# 
Nothing GKTK-y popped up. Is gtk-firewall not meant to be started by root via a terminal?

Added in 2 minutes 37 seconds:
The original from Port 5.01 also fails for me:

Code: Select all

root@rava:~# /opt/porteus-scripts/gtk-firewall 
checkbox was turned on
Traceback (most recent call last):
  File "/opt/porteus-scripts/gtk-firewall", line 162, in on_button5_toggled
    self.status_bar_on()
  File "/opt/porteus-scripts/gtk-firewall", line 88, in status_bar_on
    return self.status_bar.push(1, "FIREWALL STATUS: ON | MODE: " + self.fw_mode())
AttributeError: 'GtkFireW' object has no attribute 'status_bar'
Traceback (most recent call last):
  File "/opt/porteus-scripts/gtk-firewall", line 172, in <module>
    win = GtkFireW()
  File "/opt/porteus-scripts/gtk-firewall", line 72, in __init__
    self.status_bar_on()
  File "/opt/porteus-scripts/gtk-firewall", line 88, in status_bar_on
    return self.status_bar.push(1, "FIREWALL STATUS: ON | MODE: " + self.fw_mode())
  File "/opt/porteus-scripts/gtk-firewall", line 104, in fw_mode
    return fmode
UnboundLocalError: local variable 'fmode' referenced before assignment
I never started /opt/porteus-scripts/gtk-firewall since I always edit /etc/rc.d/rc.FireWall directly, so I cannot say if that is a recent bug.
My system info:

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
Cheers!
Yours Rava

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 3914
Joined: 20 Mar 2012, 03:42
Distribution: v5.0-64bit
Location: australia
Contact:

Porteus-v5.01 bug reports

Post#137 by ncmprhnsbl » 19 Nov 2023, 23:56

Rava wrote:
19 Nov 2023, 13:59
I think in one version, there is also either a tab or several whitespaces inserted at that line, and in the other version there is/are not.
Basically, the differences with these 3 lines ( 49c49 and 62c62 and 84x87 ) can all be ignored, correct?
yes, just some trailing whitespaces removed
Rava wrote:
19 Nov 2023, 13:59
There is still one nitpick:
it still states
will fix
and, yes there's some instability with gtk-firewall (generally meant to be started via porteus-settings-centre) which i haven't quite figured out, sometimes it works properly, sometimes not at all
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Porteus-v5.01 bug reports

Post#138 by Rava » 20 Nov 2023, 00:04

ncmprhnsbl wrote:
19 Nov 2023, 23:56
and, yes there's some instability with gtk-firewall (generally meant to be started via porteus-settings-centre) which i haven't quite figured out, sometimes it works properly, sometimes not at all
I opened porteus-settings-centre and went to security, but clicking on "Porteus Firewall" gives no results. Since I started it via the main menu I also not see any error messages.
All other entries I clicked open a new window but "Porteus Firewall" is not. Image

Either gtk-firewall doesn't like me, or doesn't like my 003-xfce 4.16 module.
Cheers!
Yours Rava

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 3914
Joined: 20 Mar 2012, 03:42
Distribution: v5.0-64bit
Location: australia
Contact:

Porteus-v5.01 bug reports

Post#139 by ncmprhnsbl » 23 Nov 2023, 05:25

Rava wrote:
20 Nov 2023, 00:04
gtk-firewall doesn't like me,
nah, just bad scripting :)
new version:
firewall_patch.xzm md5sum e361bee37ab3bbdd0f6a5f23b32d254a
the problem was that the 'status' (normal|strict|blockall) relied on the number of ports specified to be open and if you modified it with extra ports this would break the test.
so instead of == , used >= to allow for added ports (for 'normal' at least) for now, until a better way of determining the status is found.
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Porteus-v5.01 bug reports

Post#140 by Rava » 24 Nov 2023, 05:17

ncmprhnsbl wrote:
23 Nov 2023, 05:25
new version:
firewall_patch.xzm md5sum e361bee37ab3bbdd0f6a5f23b32d254a
Thanks.
I presume, when I already included (and altered to my interlink email app needs) the new version of rc.FireWall (new as in, your "firewall_patch.xzm" version from a few days ago) - I only need to add the new version of gtk-firewall, correct?

Added in 13 minutes 49 seconds:
Copied the new version into the system path to test it (after I mloop'ed the firewall_patch.xzm module):

Code: Select all

root@rava:/# cp /mnt/loop/opt/porteus-scripts/gtk-firewall /opt/porteus-scripts/
/bin/cp: overwrite '/opt/porteus-scripts/gtk-firewall'? y
root@rava:/# 
then started it from the terminal:

Code: Select all

root@rava:/# /opt/porteus-scripts/gtk-firewall
checkbox was turned on
Traceback (most recent call last):
  File "/opt/porteus-scripts/gtk-firewall", line 167, in on_button5_toggled
    self.status_bar_on()
  File "/opt/porteus-scripts/gtk-firewall", line 90, in status_bar_on
    return self.status_bar.push(1, "FIREWALL STATUS: ON | MODE: " + self.fw_mode())
AttributeError: 'GtkFireW' object has no attribute 'status_bar'
Mousepad-Message: 06:21:16.147: Plugin directory '/usr/lib64/mousepad/plugins' not found

(editor:4015): GLib-CRITICAL **: 06:21:16.147: g_dir_read_name: assertion 'dir != NULL' failed

(editor:4015): GLib-CRITICAL **: 06:21:16.147: g_dir_close: assertion 'dir != NULL' failed
It looks like it loads up okay, and he error messages when starting mousepad as root are the same procedure as last year as always when in 003-xfce (4.16) mousepad was started as root…
Since I never used gtk-firewall before, does it work by altering rc.FireWall and restarting rc.FireWall?
If so, on can (should) make a backup of rc.FireWall prior using gtk-firewall and after use diff to see the changes gtk-firewall make in rc.FireWall.
Cheers!
Yours Rava

i3slkiller
Black ninja
Black ninja
Posts: 32
Joined: 03 Feb 2020, 18:51
Distribution: Porteus XFCE v5.0rc2 x86_64
Location: Poland

Porteus-v5.01 bug reports

Post#141 by i3slkiller » 28 Nov 2023, 19:45

In Porteus 5.01 there is a bug which cause inability to open Windows share in file manager (like Thunar).
However, it's possible to browse list of Windows shares on remote PC by typing smb://ip_address, but attempt of opening any share results nothing or throws that error:

Code: Select all

Failed to mount Windows share: Invalid argument.
Attempt of opening share by typing smb://ip_address/share results in the same error.

I noticed that downgrading Samba to 4.15.5 fixes the bug, but I don't consider it for obvious reasons. Mounting share in terminal, though it's doable and works, isn't an option either.

Building and installing gvfs version 1.48.2 (or maybe newer) fixes this bug.
In KDE no matter if do anything of what I wrote above except mounting share in terminal, it looks like that's loading forever.

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Porteus-v5.01 bug reports

Post#142 by Rava » 03 Dec 2023, 07:06

My system

Code: Select all

001-core.xzm:20230922
002-xorg.xzm:20231001
002-xtra.xzm:20230922
003-xfce.xzm:20230922
06-man.xzm:20230915
initrd.xz:20220928

Code: Select all

guest@rava:/$ lynx -version
Lynx Version 2.9.0dev.10 (11 Aug 2021)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 1.1.1w, ncurses 6.3.20211021(wide)
Built on linux-gnu (Dec  3 2021 13:03:23).

lynx - browsing a site that would give me too much issues browsing it with my main Pale Moon browser
I want to access the lynx help but when pressing "h" all I get is this:

Code: Select all

Alert!: Unable to access document.
What document or maybe documents is lynx missing, and how do I insert it in my system?

Code: Select all

guest@rava:~$ grep help/. /var/lib/pkgtools/packages/lynx-2.9.0dev.10-x86_64-1|wc
     28      28    1478
guest@rava:~$ 
28 documents listed. Neat, that as regex a literal dot (".") is seen as this: any character except newline and by thus it excludes the line with just /lynx_help/ at the end and only lists documents but not that folder

Code: Select all

guest@rava:~$ grep help/. /var/lib/pkgtools/packages/lynx-2.9.0dev.10-x86_64-1
usr/share/lynx/lynx_help/Lynx_users_guide.html.gz
usr/share/lynx/lynx_help/about_lynx.html.gz
usr/share/lynx/lynx_help/alphatoc.html.gz
usr/share/lynx/lynx_help/body.html.gz
usr/share/lynx/lynx_help/cattoc.html.gz
usr/share/lynx/lynx_help/keystrokes/
usr/share/lynx/lynx_help/keystrokes/alt_edit_help.html.gz
usr/share/lynx/lynx_help/keystrokes/bashlike_edit_help.html.gz
usr/share/lynx/lynx_help/keystrokes/bookmark_help.html.gz
usr/share/lynx/lynx_help/keystrokes/cookie_help.html.gz
usr/share/lynx/lynx_help/keystrokes/dired_help.html.gz
usr/share/lynx/lynx_help/keystrokes/edit_help.html.gz
usr/share/lynx/lynx_help/keystrokes/environments.html.gz
usr/share/lynx/lynx_help/keystrokes/follow_help.html.gz
usr/share/lynx/lynx_help/keystrokes/gopher_types_help.html.gz
usr/share/lynx/lynx_help/keystrokes/history_help.html.gz
usr/share/lynx/lynx_help/keystrokes/keystroke_help.html.gz
usr/share/lynx/lynx_help/keystrokes/movement_help.html.gz
usr/share/lynx/lynx_help/keystrokes/option_help.html.gz
usr/share/lynx/lynx_help/keystrokes/other_help.html.gz
usr/share/lynx/lynx_help/keystrokes/print_help.html.gz
usr/share/lynx/lynx_help/keystrokes/scrolling_help.html.gz
usr/share/lynx/lynx_help/keystrokes/test_display.html.gz
usr/share/lynx/lynx_help/keystrokes/visited_help.html.gz
usr/share/lynx/lynx_help/keystrokes/xterm_help.html.gz
usr/share/lynx/lynx_help/lynx-dev.html.gz
usr/share/lynx/lynx_help/lynx_help_main.html.gz
usr/share/lynx/lynx_help/lynx_url_support.html.gz
guest@rava:~$
Would all these documents be needed to get basic help or can some be omitted?

Added in 4 minutes 37 seconds:
And hopefully my last question on that topic:
where I to put these documents in a "lynx_2.9.0dev.10_help.xzm" module, can I gunzip these files prior creating the module, or is lynx only able to handle these files when they are the compressed *.gz variants?

Added in 1 hour 39 minutes 27 seconds:
Answer: it has to be the gzipped versions. (and you cannot use slapt-get nor slapt-mod since both claim I already have the complete install of lynx-2.9.0dev.12-x86_64-1; searched it via https://slackware.nl/slakfinder/ and manually downloaded via guest's wget http://ftp.osuosl.org/pub/slackware/sla ... 6_64-1.txz )

I made two modules mainly containing the help files in /usr/share/lynx/lynx_help and /usr/share/lynx/lynx_help/keystrokes

The smaller one has the gunzipped files:

Code: Select all

155648 bytes lynx-2.9.0dev.12-x86_64-1_help.xzm    (152.00 KB)
The larger one has the gzipped files intact and is thus larger:

Code: Select all

196608 bytes lynx-2.9.0dev.12-x86_64-1_help_gz.xzm  (192.00 KB)
Only the larger version with the gzipped files work. Oh well. :P
Cheers!
Yours Rava

User avatar
Ed_P
Contributor
Contributor
Posts: 8280
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Porteus-v5.01 bug reports

Post#143 by Ed_P » 03 Dec 2023, 15:52

This option doesn't require a module:

Code: Select all

#!/bin/sh
lynx https://lynx.invisible-island.net/lynx_help/lynx_help_main.html
Ed

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Porteus-v5.01 bug reports

Post#144 by Rava » 03 Dec 2023, 18:50

Ed_P wrote:
03 Dec 2023, 15:52
This option doesn't require a module:

Code: Select all

#!/bin/sh
lynx https://lynx.invisible-island.net/lynx_help/lynx_help_main.html
Indeed, and usually one can go online when one uses a browser.
I wish the above could be somehow included into lynx setup: "when you do not find the help file locally, look in the web for them and the URL is https://lynx.invisible-island.net/lynx_ ... _main.html "…

Added in 5 minutes 3 seconds:
What I found on https://invisible-island.net/
vile
text editor (vi like emacs)
Combining vi and emacs, who would have seen that coming?

i3slkiller
Black ninja
Black ninja
Posts: 32
Joined: 03 Feb 2020, 18:51
Distribution: Porteus XFCE v5.0rc2 x86_64
Location: Poland

Porteus-v5.01 bug reports

Post#145 by i3slkiller » 19 Dec 2023, 13:20

In Porteus XFCE and GNOME lxdm allows logging in to account without entering valid password (accepts any password, not only valid one). Adding this line

Code: Select all

auth        include     system-auth
just under #%PAM-1.0 in /etc/pam.d/lxdm fixes this issue.

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Porteus-v5.01 bug reports

Post#146 by Rava » 01 Jan 2024, 19:53

About the newest updates to 5.01:

What XFCE version is porteus/x86_64/Porteus-v5.01/updates/core/20231228/003-xfce.xzm ?
v4.16? v4.18?

Added in 18 minutes 26 seconds:
Answering myself: I looked into my current 003-xfce module what is there to be found with the file name part of '4\.16' (the \. is there to search for a literal ".") and did the same searches on the newest 003-xfce.xzm module:

Code: Select all

guest@rava:/mnt/sda2/tmp/20231228$ lsxzm 003-xfce.xzm |grep '4\.16'|wc
     25      25    1336
guest@rava:/mnt/sda2/tmp/20231228$ lsxzm 003-xfce.xzm |grep '4\.18'|wc
      0       0       0
guest@rava:/mnt/sda2/tmp/20231228$ lsxzm 003-xfce.xzm |grep '4\.12'|wc
      0       0       0
Obviously, the provided 003-xfce.xzm (md5sum f2c5f81b5d64d7d89af07c1f43636a7a) is v4.16. :celebrate14:
Cheers!
Yours Rava

Buurman
White ninja
White ninja
Posts: 25
Joined: 28 Oct 2019, 18:00
Distribution: ver5

Porteus-v5.01 bug reports

Post#147 by Buurman » 09 Jan 2024, 20:07

Going from 5.18.8 to 6.5.5 keyboard layout and numlock are acting up

even though i call numockx in home/.config/autostart .. it is off again after boot reaches desktop

keyboard layout is wrong too, never had to set it before and was right (euro sign alt-5 and " above o or " above a -when continuing typing -- us intl with dead keys)
now even after setting keyboard in settings-center/keyboard or via language-setup/locals .. it works directly after setting but after boot ..all gone again (although the written locals xzm' s are there)
-did some default settings (setxkbmpa or lx-keyboard) change with some updates ?

-- there is SO ridiculously much stuff about numlock and linux
just WHY ? why does ANY distribution have to meddle with it by default ? just DON'T
if one has it set in bios to ON .. leave it ON for fu** sake
next there are a gazillion solutions (which most don't work and/or are way to complicated) for a "problem" that should not exist

rych
Warlord
Warlord
Posts: 617
Joined: 04 Jan 2014, 04:27
Distribution: Porteus 5.0 x64 OpenBox
Location: NZ
Contact:

Porteus-v5.01 bug reports

Post#148 by rych » 15 Jan 2024, 07:43

ncmprhnsbl, not a bug but a request: for the next update could you please update smartmontools (smartctl) inside 001-core.xzm to a more recent version found in https://builds.smartmontools.org/ for example? I had to make my own smartmontools-linux-x86_64-static-7.5-r5579.xzm overshadowing because the old smartctl didn't recognize my new USB NVME controller and didn't let me see the SMART temperatures of my disk in Booting from NVMe USB enclosure (Post by rych #98033)

User avatar
Ed_P
Contributor
Contributor
Posts: 8280
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Porteus-v5.01 bug reports

Post#149 by Ed_P » 22 Jan 2024, 19:57

Updates needed:
USB_INSTILLATION.txt wrote:If you do so, you need to add the from=/mnt/sdb2 cheatcode to the porteus-v4.0-x86_64.cfg file.
v4.0 should be v5.0 and it should be noted sdb2 might be sda2 if the pc has a nvme0 drive.

I also think the cfg file to be updated should be the /boot/syslinux/ file especially if /porteus is on a different drive.
Ed

emfer
Ronin
Ronin
Posts: 1
Joined: 16 Feb 2024, 04:20
Distribution: Porteus-LXDE-v5.01-x86_64
Location: Canada

Porteus-v5.01 bug reports

Post#150 by emfer » 16 Feb 2024, 05:15

Hi I've been trying out the 'Porteus as a PXE server' boot option. I was able to get it working after a couple of fixes.
This is on Porteus-LXDE-v5.01-x86_64. I used two VM's created in VirtualBox for testing.

Scenario:
First VM boots fine from the ISO image with the 'Porteus as a PXE server' option.
Second VM is set up as client to boot over PXE using BIOS.

Issue 1: client VM keeps showing a "/vesamenu.c32: not a COM32R image" message at the boot: prompt.

Eventually I found that this was caused by the pxelinux.0 loader under /srv/pxe/boot on the Porteus PXE server being an old version that was not compatible with the newer vesamenu.c32 module.
I found the newer version of pxelinux.0 available under /mnt/sr0/boot/syslinux on the PXE server so I added links to it and it's dependencies:

Code: Select all

cd /srv/pxe/boot
# rename old pxelinux.0 file
mv pxelinux.0 pxelinux.0.old
# set up symbolic links to required modules
ln -s /mnt/sr0/boot/syslinux/pxelinux.0 .
ln -s /mnt/sr0/boot/syslinux/ldlinux.c32 .
ln -s /mnt/sr0/boot/syslinux/libutil.c32 .
ln -s /mnt/sr0/boot/syslinux/libcom32.c32 .
Issue 2: after the above changes, client VM could load vmlinuz and initrd.xz okay but cannot NFS mount the porteus root image.

I found the root porteus image under /mnt/sr0/porteus on the PXE server but the /etc/exports file shows it as being under /srv/pxe/porteus.
I created another symbolic link and ran exportfs:

Code: Select all

# add symbolic link to porteus root image
ln -s /mnt/sr0/porteus/ /srv/pxe
# re-export NFS dir
exportfs -a
After that, PXE booting works normally.


On another note, this doc seems out of date as it refers to PXE loading over http instead of NFS. It threw me off track when I was trying to get PXE boot working:
http://www.porteus.org/component/conten ... oting.html

Post Reply