Hello:

It would seem that acpitool is just an application that writes to /proc/acpi/wakeup, just like you would do by using echo. 

Found a helping hand at Stack Overflow and put this script to execute at boot (in rc.local)

#!/bin/sh
# set /proc/acpi/wakeup to disabled with acpitool

PATH=/sbin:/bin:/usr/sbin:/usr/bin:

for i in $(seq 1 9)
do
    /usr/bin/acpitool -W $i
done
groucho@devuan:~$ 

This is the result, sleep to all input devices seen by acpitool set to disabled:

$ acpitool -w
   Device	S-state	  Status   Sysfs node
  ---------------------------------------
  1. USB0	  S4	*disabled  pci:0000:00:1d.0
  2. USB1	  S4	*disabled  pci:0000:00:1d.1
  3. USB2	  S4	*disabled  pci:0000:00:1d.2
  4. USB5	  S4	*disabled
  5. EUSB	  S4	*disabled  pci:0000:00:1d.7
  6. USB3	  S4	*disabled  pci:0000:00:1a.0
  7. USB4	  S4	*disabled  pci:0000:00:1a.1
  8. USB6	  S4	*disabled  pci:0000:00:1a.2
  9. USBE	  S4	*disabled  pci:0000:00:1a.7
  10. P0P1	  S4	*disabled  pci:0000:00:01.0
  11. P0P2	  S4	*disabled  pci:0000:00:06.0
  12. P0P3	  S4	*disabled  pci:0000:00:1c.0
  13. BR11	  S4	*disabled
  14. BR12	  S4	*disabled
  15. BR13	  S4	*disabled
  16. P0P4	  S4	*disabled  pci:0000:00:1c.4
  17. BR15	  S4	*disabled
  18. P0P5	  S4	*disabled  pci:0000:00:1e.0
  19. GBE	  S4	*disabled  pci:0000:00:19.0
  20. SLPB	  S4	*disabled
$ 

Cheers,

A.

Hello:

There's a post here https://unix.stackexchange.com/question … 417_417965 that may indicate that you are right ...

... but it's over my pay grade, no idea how that works. =-/

Yes, the script is a solution and the one I'm using works but it's awfull.

If I cannot find a way for the command acpitool -W to address multiple entries in /proc/acpi/wakeup at once, I need a more complex script ie: with a minimum of elegance to do it with.

Any idea where I can get a sample script to modify from?

Thanks in advance.

A.

Hello:

You're welcome.

One would tend to, at first sight, agree.
But I have come to think that, to quote George and Ira Gershwin in Porgy and Bess, "It ain't necessarily so."
I have the notion that what is needed is something else and manpower may not be the problem.

A bit OT, but just a few lines:

It seems that it's not possible (and probably won't ever be) to harness the creative work of the countless thousands of programmers, developers and contributors dedicated to this fantastic project started by Linus Torvalds in a way that that they just work together and come up with just 'one' 100% functional and scalable 'distro' instead of generating gadzillionz different flavours, forks of whatever is available out there.

One of the (few) negatives of open source and free licensing is that forking projects just for the sake of having their own project - "look Ma! I rolled my own distro!!!!" - has almost become the norm.

It is highly counter-productive and there is no logical reason for it.

If you do, I'll gradly do the testing.

Cheers,

A.

Muito obrigado.
Mas eu já tenho tudo isso (custom actions) habilitado em Thunar.
O que o plug-in do nautilus-terminal faz no Nautilus aparentemente não é possível fazer em Thunar.

Thank you.
But I already have all that (custom actions) enabled in Thunar.
What the nautilus-terminal does in Nautilus apparently in not possible in Thunar.

AQ.

Hello:

AppArmor is disabled in ASCII.

groucho@devuan:~$ sudo dmesg | grep -i apparmor
[    0.010652] AppArmor: AppArmor disabled by boot time parameter
groucho@devuan:~$ 

I do not have a boot time parameter disabling apparmor (ie: not my doing), so it is probably disabled at a lower level in ASCII and it's not even in the repository.
I'm guessing that there may have been good motive for all that.

When I tried my hand at the newer post-ASCII kernel, AppArmor was installed along with it.

The newer kernel ended up complicating things in my rig so I gave up.
But on uninstalling it, AppArmor was left behind and on reboot threw a few errors in the logs.

AppArmor is a service and as such you could disable it to see what happens with haveged and eventually remove it if it gives you too much trouble.
On the other hand, I guess AppArmor could be configured not to mess with haveged.

I for one am rather weary of AppArmor (or SELinux for that matter) and it's eventual usefulness in a single user installation, where you make every possible effort to run a tight ship. I see it as being more an administrator's tool in a multi-user environment but then, what do I know?

I may well be mistaken and prove to be a god-send instead of a headache.

Cheers,

A.

Hello:

I installed it and have it running in my Devuan ASCII:

groucho@devuan:~$ /etc/init.d/haveged status
[ ok ] haveged is running.
groucho@devuan:~$ 

I cannot remember how I did it.  =-/

But see here:
https://www.techrepublic.com/article/ho … -on-linux/

Then you would get a script in /etc/init.d/haveged

#! /bin/sh
### BEGIN INIT INFO
# Provides:          haveged
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Should-Start:      $syslog
# Should-Stop:       $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Entropy daemon using the HAVEGE algorithm
# Description:         haveged uses HAVEGE (HArdware Volatile Entropy Gathering
#                           and Expansion) to maintain a pool of random bytes used
#                           to fill /dev/random whenever necessary.
### END INIT INFO

Other than default options:

groucho@devuan:~$ sudo haveged --help

Usage: haveged [options]

Collect entropy and feed into random pool or write to file.
  Options:
     --buffer    , -b [] Buffer size [KW], default: 128
     --data      , -d [] Data cache size [KB], with fallback to: 16
     --inst      , -i [] Instruction cache size [KB], with fallback to: 16
     --file      , -f [] Sample output file,  default: 'sample', '-' for stdout
     --Foreground, -F    Run daemon in foreground
     --run       , -r [] 0=daemon, 1=config info, >1=<r>KB sample
     --number    , -n [] Output size in [k|m|g|t] bytes, 0 = unlimited to stdout
     --onlinetest, -o [] [t<x>][c<x>] x=[a[n][w]][b[w]] 't'ot, 'c'ontinuous, default: ta8b
     --pidfile   , -p [] daemon pidfile, default: /var/run/haveged.pid
     --verbose   , -v [] Verbose mask 0=none,1=summary,2=retries,4=timing,8=loop,16=code,32=test
     --write     , -w [] Set write_wakeup_threshold [bits]
     --help      , -h    This help
groucho@devuan:~$ 

Cheers,

A.

Hello:

zram is only available for beowolf and ceres:

https://pkginfo.devuan.org/stage/beowul … 8.1-4.html
https://pkginfo.devuan.org/stage/beowul … 2.1-1.html
https://pkginfo.devuan.org/stage/ceres/ … 8.2-1.html
https://pkginfo.devuan.org/stage/ceres/ … 2.1-1.html

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

Cheers,

A.

Hello:

I really don't know if I need a newer one just yet.

To start, maybe a more compact one, tailored to the specific hardware I use.
There's (what seems to be) a hardware issue I'm troubleshooting and I may also find out more about what's going on with a kernel that has only what I need. 

Yes, that's looks like what I'm needing.
Will have to find the corresponding how-to.

I recall that, when exploring the Mint distribution (a rolling release), I could install other kernels ie: older or newer and then remove them as required.
They were all in the rpm repository but that's not the case with Devuan which is why I'm attempting this.

Once again, thanks for your input.
You've been very helpful.

Best,

A.

Hello:

I see ...

Pluma even more so, as it does not show me anything and then complains when I attempt to open the file.  =-)
On the other hand, Leafpad just refuses to show me the offending "non text".

I'm glad this is not a Leafpad issue as I like it better than Pluma, can't say why.

I installed GHex 3.18.3 and found that between this string:

Mar  4 15:42:46 devuan kernel: [  576.219397] EXT4-fs (sdb1): re-mounted. Opts: (null)

... and this string:

Mar  4 15:45:07 devuan liblogging-stdlog:  [origin software="rsyslogd" swVersion="8.24.0" x-pid="1977" x-info="http://www.rsyslog.com"] start

... there is a long string of .................. which for some reason the editor would not copy into the clipboard.

On the hexadecimal view pane, these .................. are represented as sets of zeroes sepatated by a space just like the rest of the hex strings.

ie: 0000 0000 0000 0000   

These strings are identified as hexadecimal 00, octal 000, binary 00000000.

Yes.

Mar  4 15:42:40 devuan kernel: [  570.124482] sysrq: SysRq : Emergency Sync
Mar  4 15:42:40 devuan kernel: [  570.155699] Emergency Sync complete
Mar  4 15:42:46 devuan kernel: [  576.133524] sysrq: SysRq : Emergency Remount R/O
Mar  4 15:42:46 devuan kernel: [  576.219397] EXT4-fs (sdb1): re-mounted. Opts: (null)

Apparently so, I thought it would not happen because the script includes a previous disk sync and unmount/remount as RO.
Evidently I'm mistaken and yet another sync maybe needed after the u.

Some background to this:
At present I'm attempting to solve a shutdown issue I have with my Ultra 24 WS.

The issue is basically this:

---
On shutdown, the rig will do one of two things:

1. shut down properly
2. freeze during the shutdown at this point ...

e1000e: EEE Tx LPI Timer
Preparing to enter sleep state S5
Reboot: Power Down

... with the fans blowing at full speed.
---

This shutdown problem ocurrs in a totally unpredictable manner, I have not been able to reproduce it or been able to link it to anything in particular.

Unfortunately, unloading the e1000e driver module before shutdown (a well known issue) or inserting a variety of reboot= stanzas in the kernel command line have not worked, even when using reboot=force.

Eventually, it would happen again.

To try to see what was going on, I decided to try shutting down the rig using a script that would (hopefully) isolate each of the stages of the shut down process and give me some feedback, much like I did in my old MS-DOS days by running config.sys and autoexec.bat in steps to weed out start-up issues:

#!/bin/sh
# Shutdown system without the use of shutdownhelper 
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:
for i in s u o; do echo $i | sudo tee /proc/sysrq-trigger; sleep 2; done  # halt

I think that what we are seeing is the same shutdown problem which does not manifest itself in the same manner as when a normal shutdown command is issued.
This because of the o in the script directly powers off the system. ie: does not give it a chance to freeze and start blowing fans.

I'll try adding a second sync and see what happens.

In the meanwhile, do you know a better way to see what is going on during the shutdown process?

The unmount/mount RO and the sync in the script I cobbled up seem to go ahead without any issues.
It would seem that it's just the shutdown part that is acting up.

Thanks in advance,

A.

Hello:

I understand (from my old DOS days) the importance and need for setting the PATH variable in a script.
But my *.bat days are long gone and I have no bash skills worth mentioning.

Undoubtedly, it is best practise to do so.

But this script works and has the same result whether I add the line you suggested to it or not.
I expect it is so because it (the needed PATH) is already set elsewhere:

groucho@devuan:~$ printenv | grep -i path
GLADE_CATALOG_PATH=:
GLADE_MODULE_PATH=:
GLADE_PIXMAP_PATH=:
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
groucho@devuan:~$ 

In any case, I will start adding the PATH to every script I attempt to write.

Thanks for your input.

A.