Porteus-v5.1 alpha 1 bug reports

[ncmprhnsbl]

Next, I tried to install some other modules using the new tool "slapt-mod" and this is where things got a bit strange: Slapt-mod starts downloading, but then breaks.

see here: Porteus-v5.1 alpha 1 bug reports (Post by ncmprhnsbl #101552)

[att]

Hello,
I am again writing from the Porteus 5.1 alpha.
Despite my /etc/slapt-get/slapt-modrc seems to look fine, it still does not work for me.

Code: Select all

guest@porteus:/etc$ cd slapt-get/
guest@porteus:/etc/slapt-get$ ls -al
total 6
drwxrwxrwx   2 guest root   60 Feb 19 13:43 ./
drwxrwxrwx 123 root  root  420 Feb 20 10:35 ../
-rw-r--r--   1 root  root 1286 Mar  9  2023 slapt-getrc
-rwxrwxrwx   1 guest root  259 Feb 19 13:43 slapt-modrc*
guest@porteus:/etc/slapt-get$ cat slapt-modrc 
## config file for slapt-mod wrapper for slapt-get
## locale ? 0 or language code eg. de (german) all others will be removed
locale=0
## man pages ? 1 keep or 0 remove
man=0
## headers ? 1 keep or 0 remove
headers=0
## docs ? 1 keep or 0 remove

My workaround for the breaking slapt-mod is still:
find /tmp -iname *.txz -exec tgz2xzm {} \;
find /tmp -iname *.xzm -exec cp {} /tmp \;
which makes all modules and then moves them to /tmp .

I noticed that when using the rootcopy directory from USB-stick, the owner of dirs and files seems to be always wrong and the rights seem to be weird - i.e. the owner is always "guest" and the rights are always "777" , which is probably not really intended behaviour. Thus I have - at the moment - a really strange looking /etc/rc.d/rc.local, which corrects the errors after booting (and, ofcourse, suits my other special needs):

Code: Select all

/usr/bin/loadkeys de		# german keyboard. Still required for text mode to work properly.
chown root /etc			# fix boot errors after rootcopy
chown root /lib
chown root /root
chown root /usr

killall -9 NetworkManager
dhcpcd eth0 -p								# get ip address for eth0
sysctl -w net.ipv6.conf.all.disable_ipv6=1			# disable ipv6

chown root /etc/vsftpd.conf						# fix owner and rights
chmod 600 /etc/vsftpd.conf
/usr/sbin/vsftpd /etc/vsftpd.conf &

chown guest /home/guest

echo "nameserver 1.1.1.1" > /etc/resolv.conf

ntpdate time.metrologie.at

cd /root/VPNS
sh /root/VPNS/rc.local.r01_graz.sh

Also, suddenly the anydesk started to work properly, and gave me a proper ID. I guess it has to do with setting proper timezone parameters in the boot line :

from porteus.cfg:

Code: Select all

APPEND 3 copy2ram kmap=de timezone=Europe/Vienna

What is really strange that in the GUI mode, when I click on the "Logout" button, and select "Lock screen", and then moved the mouse I never got a login screen asking me for login and password. I haven't found a solution for that, either.
Otherwise, Porteus is really blazingly fast and nice to use.

[ncmprhnsbl]

Despite my /etc/slapt-get/slapt-modrc seems to look fine, it still does not work for me.

hmm, i must admit that package management in alpha has been a low priority so far, due to the small pasture of packages for slackware current.
once 15.1 lands and salix repopulate their repos, it'll be a different story.
that said, i'll have to do some testing and get back to you on this.

I noticed that when using the rootcopy directory from USB-stick, the owner of dirs and files seems to be always wrong and the rights seem to be weird - i.e. the owner is always "guest" and the rights are always "777" , which is probably not really intended behaviour. Thus I have - at the moment - a really strange looking /etc/rc.d/rc.local, which corrects the errors after booting (and, of course, suits my other special needs):

what is the filesystem of your usb? for rootcopy to work correctly, it must be used from a POSIX partition. (you can use the cheatcode rootcopy=/some/path to use a POSIX partiton other than a nonPOSIX boot one)

What is really strange that in the GUI mode, when I click on the "Logout" button, and select "Lock screen", and then moved the mouse I never got a login screen asking me for login and password. I haven't found a solution for that, either.

which DE module are you using?

[att]

My USB Stick is just a normal NTFS partition, it came pre-formatted and I didn't change anything.
About the screen saver, I RTFM'ed the message and got to know that this is intended behaviour - I just need to enter the password blindly and then it unlocks the screen. Sorry, that was my mistake. I use LXDE.

[Ed_P]

My USB Stick is just a normal NTFS partition, it came pre-formatted and I didn't change anything.

New USB drives are manufactured formatted as exFAT. Faster & less overhead than the old NTFS and ttbomk it doesn't support POSIX. If your's is NTFS imo it's a used drive.

[ncmprhnsbl]

My USB Stick is just a normal NTFS partition, it came pre-formatted and I didn't change anything.

as Ed says this is nonPOSIX (ie. doesn't support file attributes (beyond full permissions for anybody))
my suggestion for proper rootcopy use:
to make a small(however big you think you'll need for rootcopy) partition (ie. resize existing one and make a new one after) in EXT (ext2 is fine, (no journaling to reduce read/write))
and use the rootcopy=/path/to/partition cheatcode.
or make and use a module/s

About the screen saver,

no worries, slock is pretty basic, and not particularly intuitive (hence the startup message window)

[Ed_P]

as Ed says this is nonPOSIX

Just to be clear, I did not say NTFS is not POSIX, I said exFAT isn't. Actually I believe NTFS does support POSIX.

[ncmprhnsbl]

Actually I believe NTFS does support POSIX.

well, i make no claims of expertise, and while NTFS may have some POSIX compatibility, it doesn't have the required file attribute retention required for porteus rootcopy to work reliably
which is fairly easy to demonstrate: copy a system file to NTFS and compare it's attributes (ls -l) with the original
or simply try to use chmod or chown on a file in NTFS..

[Ed_P]

it doesn't have the required file attribute retention required for porteus rootcopy to work reliably

In that I never use rootcopy I am unaware of it's requirements. But this code from my NTFS harddrive shows you what I see with NTFS.

Code: Select all

guest@porteus:/mnt/nvme0n1p7/porteus5.0$ ls -l
total 93
-rwxrwxrwx 1 guest root   326 Aug  1  2021 !cmd_here.cmd*
-rwxrwxrwx 1 guest root  1761 Nov 20 01:21 Bkup2Q.cmd*
drwxrwxrwx 1 guest root     0 Aug 11  2024 BootModules/
-rwxrwxrwx 1 guest root   176 Feb 23 00:45 Fri13.sh*
drwxrwxrwx 1 guest root 36864 Feb 19 17:28 Guest/
drwxrwxrwx 1 guest root  8192 Feb  4 16:40 ISOModules/
drwxrwxrwx 1 guest root  4096 Feb 20 18:39 Modules/
drwxrwxrwx 1 guest root 20480 Feb  7 17:07 Optional/
drwxrwxrwx 1 guest root  4096 Oct 30 00:44 changes/
drwxrwxrwx 1 guest root     0 Jan  5  2023 i586files/
drwxrwxrwx 1 guest root  4096 Jan 10 14:25 initrd/
drwxrwxrwx 1 guest root  4096 Jan  9 20:37 misc/
drwxrwxrwx 1 guest root  4096 Aug 13  2022 porteus-usb-bkups/
-rwxrwxrwx 1 guest root  2183 Feb  2 17:24 printer.txt*
drwxrwxrwx 1 guest root     0 Apr 10  2022 wifi/
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ 
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ cat Fri13.sh
#!/bin/bash
echo -en "\033]0;Friday 13s in $1\a" && echo

cal -y $1|awk '{print $6,$13,$20}'|grep -o 13|wc -l && echo
# https://forum.porteus.org/viewtopic.php?p=98979#p98979

guest@porteus:/mnt/nvme0n1p7/porteus5.0$ 
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ ./Fri13.sh 2025

1

guest@porteus:/mnt/nvme0n1p7/porteus5.0$ 
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ 
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ chmod Fri13.sh
chmod: missing operand after ‘Fri13.sh’
Try 'chmod --help' for more information.
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ chmod +x Fri13.sh
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ ./Fri13.sh 2025

1

guest@porteus:/mnt/nvme0n1p7/porteus5.0$ 

Does it help answer your concerns?

[ncmprhnsbl]

Does it help answer your concerns?

D: um, i didn't have any concerns ..but now i'm little concerned for you

Code: Select all

-rwxrwxrwx 1 guest root   176 Feb 23 00:45 Fri13.sh*

-rwxrwxrwx means read/write/execute for everbody (which is determined by how the device is mounted btw and all files will have these)

Code: Select all

chmod +x Fri13.sh

you've just attempted to add execute permissions to a file that already has them.. try chmod -x and you might see my point.

[Ed_P]

D: um, i didn't have any concerns ..but now i'm little concerned for you

Code: Select all

guest@porteus:/mnt/nvme0n1p7/porteus5.0$ chmod -x Fri13.sh
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ ./Fri13.sh 2025

1

guest@porteus:/mnt/nvme0n1p7/porteus5.0$ ls -Hon
total 93
-rwxrwxrwx 1 1000   326 Aug  1  2021 !cmd_here.cmd*
-rwxrwxrwx 1 1000  1761 Nov 20 01:21 Bkup2Q.cmd*
drwxrwxrwx 1 1000     0 Aug 11  2024 BootModules/
-rwxrwxrwx 1 1000   176 Feb 23 00:45 Fri13.sh*
drwxrwxrwx 1 1000 36864 Feb 19 17:28 Guest/
drwxrwxrwx 1 1000  8192 Feb  4 16:40 ISOModules/
drwxrwxrwx 1 1000  4096 Feb 20 18:39 Modules/
drwxrwxrwx 1 1000 20480 Feb  7 17:07 Optional/
drwxrwxrwx 1 1000  4096 Oct 30 00:44 changes/
drwxrwxrwx 1 1000     0 Jan  5  2023 i586files/
drwxrwxrwx 1 1000  4096 Jan 10 14:25 initrd/
drwxrwxrwx 1 1000  4096 Jan  9 20:37 misc/
drwxrwxrwx 1 1000  4096 Aug 13  2022 porteus-usb-bkups/
-rwxrwxrwx 1 1000  2183 Feb  2 17:24 printer.txt*
drwxrwxrwx 1 1000     0 Apr 10  2022 wifi/
guest@porteus:/mnt/nvme0n1p7/porteus5.0$ 

[nanZor]

Love 5.1 Alpha so far. But just a quick bug note (not specific to the Alpha release) related to hardware and initial installation runs I caught:

Reboot at least once after initial install

Makes me wonder how many bugs are seen during the very first run after the very first initial install run, compared to one that has had at least ONE reboot - whereby I think some modern machines get things enumerated properly internally after that first reboot from an initial install. May not happen to everyone.

Ie, my own urban legend is to not chase/report ghost-bugs until after a single reboot. Seems like a hardware thing, not Porteus specifically. Sorry, this is a heads up, not a specific 5.1 Alpha bug. (I'm in love with it so far).

[nanZor]

5.1Alpha XFCE Display Power Management issue:

It seems that setting the DPMS display sleep and off slider times are being ignored, and defaulting to only 10 minutes on a DPMS monitor. I suspect the system is using the normal screen blanking intervals instead: (xset q). I believe the values are swapped.

Code: Select all

Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  600    cycle:  600

The slider times that I changed can be invoked (up to 60 min max) by the top panel power icon, or from the menu (menu > settings > power manager > display), but are being ignored. Ie, the display always goes to sleep and shuts down after 10 minutes no matter what.

These slider times can be verified by using xset q :

Code: Select all

DPMS (Display Power Management Signaling):
  Standby: 3480    Suspend: 0    Off: 3600
  DPMS is Enabled
  Monitor is On

TESTED:
I used the standard old blanking intervals to change the time to say 5 minutes, and the DPMS monitor recognized it (instead of using the standby/suspend power management slider values)

Code: Select all

xset s 300 300

The system accordingly shut down the DPMS monitor in 5 minutes. It has swapped the screen saver timeout/cycle times for the DPMS standby/suspend times.

Way way back in the day, I remember coming across these swapped field values before and tore my hair out, so when this happened, I tried it immediately and bingo. Hard to research the swapped fields bug for this in most articles since they assume the normal operation.

Not a showstopper, since a little typing for now with xset at each boot is cool with me.
UPDATE:
Learned a neat way to apply this bandaid automatically for now. Used the XFCE Session&Startup > Application Autostart utility, and added this command for 1 hour DPMS shutdown and saved on logout:

Code: Select all

bash -c 'xset s 3600 3600'

Neat!

[nanZor]

FIXED!! DPMS screen blank XFCE issue is hardware-dependent quirk, so not a bug! I should have known with my pile o' pc's... sorry gang.

On my UEFI only machine, dpms timeouts work perfectly per the xfce sliders as long as we increase the value of the blanking timeout, so that doesn't take over first.

On a legacy-mode only Chromebox - with the same monitor - it ignores the sliders and obeys the older screen blank values as if it were DPMS. Hardware Gotcha!

The really nifty auto-fix in case anyone runs across this is as above, but I have added some sleep to let X get it's act together before doing this tweak:

Menu > Settings > Session and Startup > Application Autostart > ADD

Give a name to your command like "Weedy Hardware DPMS fix" and don't forget the apostrophe's. I checked the box in "General" to automatically save session on logout in the general tab.

Code: Select all

bash -c 'xset sleep 10 && xset s 3800 3800'

Again NOT A BUG, but a hardware quirk on my end. Nifty little fix to know in case anyone is using cranky hardware!

[SEMERENDO.cr]

bluetooth finally work or not?