I've never tried to log in to a government website but it certainly renders well in text browsers.

Any web page that doesn't render reasonably in a terminal-based web browser is fundamentally broken IMO.

The UK government website is tested with elinks and so is perfectly usable in all browsers.

The script on GitHub does actually have the backticks, you must have missed them when you copied it.

The original script used bash but didn't contain anything that actually needed bash. The tests ([[...]]) were the bash version but the /bin/sh (POSIX) test ([...]) works just as well. I always prefer /bin/sh over /bin/bash because it's faster, lighter and less buggy. The Debian developers also prefer /bin/sh for the same reasons and went to quite some effort replacing all of the bash system scripts with /bin/sh versions. Ubuntu also did this: https://wiki.ubuntu.com/DashAsBinSh

Use https://www.shellcheck.net/ to test scripts. That would have identified the problem along with several other issues.

Better version:

#!/bin/sh
 
if [ $# -gt 1 ] || [ "$1" != enable ] && [ "$1" != disable ]; then
         echo "Usage: $0 <enable|disable>"
         exit 1
fi

if [ "$1" = enable ]; then
        TOGGLE=$(grep '\*disabled' /proc/acpi/wakeup | cut -d ' ' -f1)

else

        TOGGLE=$(grep '\*enabled' /proc/acpi/wakeup | cut -d ' ' -f1)

fi

for DEV in $TOGGLE ; do
        echo "$DEV" 
        echo "$DEV" > /proc/acpi/wakeup

done

POSIX sh ftw!

It can be simplified further if all you want to do is disable everything:

#!/bin/sh

dev=$(awk '/*enabled/{print $1}' /proc/acpi/wakeup)

for i in $dev ; do
   echo "$i" > /proc/acpi/wakeup
done

Well the systemd unit files supplied by the upstream developers load the module at boot (ie, before the DE starts) so I presume that is the expected behaviour.

At the risk of treading on fsmithred's toes (sorry):

You should probably post the actual content of the file(s) rather than a vague description.

aptitude search '?narrow(?archive(experimental), mesa)'

You don't need to pin experimental packages (unless you want them to be updated from that repository) because experimental has a default pin value of 1 (one).

For a guide see https://www.debian.org/doc/manuals/debi … al_literal and read apt_preferences(5).

What was the actual command you used? There are several packages that provide Mesa.

Whonix has a DKMS .deb package for LKRG:

https://www.whonix.org/wiki/Linux_Kerne … ource_Code

Their current version is 0.8.1 but the git repository has a debian/watch file so it can be updated with uscan.

The .deb only supplies the systemd unit files but the same effect can be achieved by adding this line to /etc/modules (or in it's own file under /etc/modules-load.d/):

p_lkrg

And also add this line to /etc/sysctl.conf (or in it's own file under /etc/sysctl.conf.d/):

lkrg.clean_message = 0

No need for lkrg.sh or any additions to /etc/sudoers

The maintainer of the X codebase described it as such himself: https://ajaxnwnk.blogspot.com/2020/10/o … erver.html

X has been maintained by Red Hat almost exclusively because nobody else has bothered. Now they can't be bothered either. It's not a case of "trying to sink it", much as the conspiracy theorists would like to convince themselves otherwise.

But this is all off-topic for this thread so we should probably continue any discussion in your other thread.

Probably. See https://www.phoronix.com/scan.php?page= … ble-Atomic

There are fixes for the atomic modesetting glitches but X is now abandonware so they are unlikely to ever be applied.

EDIT: is there anything printed in the X.Org log when you experience the problem?

The default configuration supplies a mandatory access control framework to confine some but not all programs. This confinement prevents compromised software from altering your system even if it has root privileges. It is actually very useful, which is why it is enabled by default. There are extra profiles available if you want to extend the protection and you can also write your own profiles to specify the exact level of confinement.

See also https://wiki.debian.org/AppArmor/HowToUse & https://debian-handbook.info/browse/sta … armor.html

Yes, I think so.

But I would just use the size option described in logrotate(8) to control how big the files get before being rotated.

EDIT: and I would delete ~/.xsession-errors at the start of every X session because there doesn't seem much point keeping error logs from old sessions.

To wit:

echo 'rm ~/.xsession-errors' >> ~/.xsessionrc

See also https://wiki.debian.org/Xsession