Porteus 5.0 RC2 bug reports

[Blaze]

otan,

-> Searching for conflicting X files:
-> done.
-> Searching for conflicting OpenGL files:
-> done.
-> Installing 'NVIDIA Accelerated Graphics Driver for Linux-x86_64' (304.137):
executing: '/sbin/ldconfig'...
executing: '/sbin/depmod -aq'...
depmod: WARNING: Ignored deprecated option -q
-> done.
-> Driver file installation is complete.
-> Running post-install sanity check:
-> done.
-> Post-install sanity check passed.
-> Shared memory test passed.
-> Running runtime sanity check:
-> done.
-> Runtime sanity check passed.
-> Would you like to run the nvidia-xconfig utility to automatically update your X configuration file so that the NVIDIA X driver will be used when you restart X? Any pre-existing X configuration file will be backed up. (Answer: Yes)
-> Your X configuration file has been successfully updated. Installation of the NVIDIA Accelerated Graphics Driver for Linux-x86_64 (version: 304.137) is now complete.

all seems good. After this yiu must run this script:

Code: Select all

./nvidia.sh

[fulalas]

@Blaze, I guess you're building Nvidia drivers newer than 304.xx, right? I'm telling this because 304.xx is totally different from the others (340.xx, 390.xx), and I remember seeing some cases where 304.xx was failing while 340.xx was not, and vice-versa! Nvidia drivers are all such a mess!

[ncmprhnsbl]

https://nvidia.custhelp.com/app/answers ... a_id/3142/
as donald pointed out: 304.xx needs xorg 1.19 or earlier and according to that link, kernels up to 4.13 (with no further releases planned)
so, if your card can't use 340.xx+, your choices are: downgrade xorg to 1.19 and kernel to 4.13 or nouveau.

Regarding ping

thanks donald, this is the firewall advice i've been looking for

[roadie]

Porteus-CINNAMON-v5.0rc2-x86_64.iso........obviously applies to all.

For Elan touchpads.

Code: Select all

# CONFIG_HID_ELAN is not set

[nanZor]

Mouse droppings in XFCE RC 2 ..

Noticed that on my modern uefi-only system if I hover over the filesystem icons, or any of the icons in the upper left, and move around, I'll notice some small video menu/icon degradation, most notably multiple / partial mouse icons getting left behind.

The quick cure was to drop to a virtual terminal, and then come back to the gui desktop. I could actually see the partial mouse icons getting cleaned up and I can use my mouse again. So it's minor, but could get annoying later.

I have only tested this with XFCE. Nice job on the RC so far!

[ncmprhnsbl]

Mouse droppings in XFCE RC 2 ..

what do you think this might be? video driver? is compositing on? turning it off help?

[nanZor]

Turning compositing OFF fixed it! Thanks!

Of course, I didn't try your suggestion first. Instead, I changed mice, changed ports, changed computers from an inexpensive hockey-puck pc to an Intel NUC (where there is no problem - and set specifically for uefi-only)

Moral: take the advice of the devs first!

So compositing was just a tad too much for the little box. I wouldn't have even thought of it if you moved slowly and hadn't drunk a cup of coffee before firing up the rc....

Thanks again - I never would have thought of that.

[Ed_P]

Minor note, Cinnamon's dates not the same.

Code: Select all

~#  uname -a
Linux porteus.example.net 5.4.57-porteus #1 SMP Sun Aug 9 09:03:28 UTC 2020 x86_64 Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz GenuineIntel GNU/Linux

~#  cat /etc/porteus/*
001-core.xzm:20200807
002-xorg.xzm:20200803
002-xtra.xzm:20200803
003-cinnamon.xzm:20200325
initrd.xz:20200404

~#  ls -l /mnt/live/memory/images
000-kernel.xzm : Aug 9 09:22
001-core.xzm : Aug 7 08:54
002-xorg.xzm : Aug 3 08:28
002-xtra.xzm : Aug 3 06:15
003-cinnamon.xzm : Jul 20 17:02

ISO: /ISOs/Porteus-CINNAMON-v5.0rc2-x86_64.iso

[donald]

Sudo now wants the root password.
Then what is the purpose of sudo?
I vote that we have no sudo at all.

[babam]

I vote that we have no sudo at all.

I use sudo a lot more than su.

[donald]

babam - What's the benefit if you need the root Pw for both?

[babam]

donald, sudo is simpler to use

Code: Select all

$ sudo mousepad /path/to/file
$ su -c "mousepad /path/to/file"

Sudo is more powerful

Code: Select all

$ echo "toor" | sudo -S command
$ script.sh

script.sh:

Code: Select all

#!/bin/bash

export SUDO_ASKPASS="/opt/bin/sudo_askpass.sh"

sudo -A command

/opt/bin/sudo_askpass.sh:

Code: Select all

#!/bin/bash

echo "toor"

[donald]

donald, sudo is simpler to use

..nope..

su:
# ls > /root/file.txt...no problem
sudo:
$ sudo ls > /root/file.txt..won't work, you need:
$ sudo sh -c "ls > /root/file.txt"

However, sudo is supposed to be configured to allow a certain set of people to run a very limited set
of commands.

Porteus is not a multi-user system.

[babam]

su:
# ls > /root/file.txt...no problem

Sudo:

Code: Select all

$ ls | sudo tee /root/file.txt...no problem

Or

Code: Select all

$ sudo -i
# ls > /root/file.txt...no problem

[donald]

Still not an easier use when you have to run a login shell first..

EDIT
(My) Conclusion
Sudo for root (Pw) is superfluous - use su.
Sudo for guest is dangerous if not properly/restrictive configured.

-- Scripts executed with sudo execute any command in them
with root privileges.
-- sudo cat /etc/NetworkManager/system-connections/<name of file>
reveal the (wifi) Pw to users.
No user should be able to read this file (-rw------- 1 root root)
-- sudo /bin/bash -- etc.