Thanks, I thought so, and haven't touched it. Strange that these directories are created despite setting the security=none kernel parameter. What about /sys/module/apparmor?

$ dpkg -S apparmor
libapparmor1:arm64: /usr/share/doc/libapparmor1/copyright
libapparmor1:arm64: /usr/share/doc/libapparmor1
man-db: /etc/apparmor.d/usr.bin.man
libapparmor1:arm64: /usr/lib/aarch64-linux-gnu/libapparmor.so.1.8.4
isc-dhcp-client: /etc/apparmor.d/sbin.dhclient
libapparmor1:arm64: /usr/lib/aarch64-linux-gnu/libapparmor.so.1
libapparmor1:arm64: /usr/share/doc/libapparmor1/changelog.Debian.gz
man-db, isc-dhcp-client: /etc/apparmor.d

That prompted me to take a look. After nearly a decade of silence there was a new release of xfce4-mixer last year (4.18), with a massive changelog. Not sure what that means in terms of being able to use it with Daedalus & ALSA, but perhaps we've been missing out!?

Just to contribute another data point, for me Firefox 115.7.0 ESR audio "just works" in Devuan Daedalus with Pulseaudio removed and ALSA as the only sound subsystem. And a tip to anyone who misses having a GUI volume control & mixer: install QasMixer:

This hasn't been updated for a year and does not appear to work on Devuan Daedalus:

$ source sdk
-bash: typeset: -U: invalid option
typeset: usage: typeset [-aAfFgiIlnrtux] name[=value] ... or typeset -p [-aAfFilnrtux] [name ...]
-bash: typeset: -U: invalid option
typeset: usage: typeset [-aAfFgiIlnrtux] name[=value] ... or typeset -p [-aAfFilnrtux] [name ...]
-bash: typeset: -U: invalid option
typeset: usage: typeset [-aAfFgiIlnrtux] name[=value] ... or typeset -p [-aAfFilnrtux] [name ...]
-bash: typeset: -U: invalid option
typeset: usage: typeset [-aAfFgiIlnrtux] name[=value] ... or typeset -p [-aAfFilnrtux] [name ...]
-bash: zmodload: command not found
-bash: zmodload: command not found
-bash: zmodload: command not found
-bash: zmodload: command not found
-bash: autoload: command not found
-bash: colors: command not found
-bash: /home/ola/Sources/arm-sdk/lib/zuper/zuper: line 115: syntax error near unexpected token `say'
-bash: /home/ola/Sources/arm-sdk/lib/zuper/zuper: line 115: `function _message say act() {'
-bash: typeset: -h: invalid option
typeset: usage: typeset [-aAfFgiIlnrtux] name[=value] ... or typeset -p [-aAfFilnrtux] [name ...]
-bash: typeset: -U: invalid option
typeset: usage: typeset [-aAfFgiIlnrtux] name[=value] ... or typeset -p [-aAfFilnrtux] [name ...]
-bash: func: command not found
-bash: func: command not found
-bash: func: command not found
-bash: func: command not found
-bash: sdk: line 141: syntax error: unexpected end of file

All requirements installed, I think:

$ sudo apt-get install curl git wget qemu-user-static build-essential rsync gcc-arm-none-eabi gcc-multilib lib32z1 u-boot-tools device-tree-compiler lzop dosfstools vboot-utils vboot-kernel-utils libftdi-dev libfdt-dev swig libpython3-dev bc bison flex libssl-dev zsh sudo cgpt parted xz-utils

Any other options?

Edit: I'm looking for the equivalent of a mini.iso for the Pi 3A+, or if it's a complete system image one without any cruft (no Xorg, XFCE etc). Also: trust is an issue. Debian? Might as well go with Raspbian then. It's Systemd I want rid of.

This prompted me to have a look at the bug tracker, but I can't even figure out how to find any relevant bug reports, which perhaps disqualifies me before I even started. All the packages I looked at simply say "There is no maintainer for [package]. This means that this package no longer exists (or never existed). Please do not report new bugs against this package." - and the reports say (correctly) that the error is upstream with Debian. I imagine this will be the case with the vast majority of bugs. Is there a list of bugs that are actually with Devuan, and where it's worth looking to see if one can help?

Seriously though

Would be interesting to hear what the Devuan gods say about this?

No cookie :'(

Ha! I think I found the problem - and by the smell only. Something smelled wrong with the xfpm_manager_inhibit_sleep_systemd(): Inhibiting systemd sleep: handle-lid-switch messages in the xfce-power-manager --debug output, so I started digging in that spot. I soon found some interesting bug reports on the Xfce bug tracker, including this one:

Not quite the same issue I was experiencing, but close enough to be potentially relevant. At first I was disappointed that the proposed solution didn't seem to have any effect (xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s false), but in comment #10 on that bug report someone says

He suggests

sudo xfconf-query -c xfce4-power-manager -n -t 'bool' -p /xfce4-power-manager/logind-handle-lid-switch -s false

but since xfce4-power-manager runs in the user context (started from Sessions and Start Up > Application Autostart) I ran the command without sudo - expecting to see a warning that the key already existed. But I got no such warning - and when I closed the lid afterwards the laptop suspended and locked. Multiple tests on battery & on AC, with multiple reboots, confirms that this indeed fixed the problem.

So the lessons learned are 1) xfce4-power-manager handles suspend and locking without involving any scripts in /etc/acpi - as indicated by the CheckPolicy condition in lid.sh 2) the acpi-support package is not needed (for this functionality anyway). 3) the issue appears to relate to a hand-off from xfce4-power-manager to systemd/logind, which is controlled by a hidden xfconf property that didn't exist on this machine (possibly because it does not have systemd installed). Adding that property and setting it to "false" hands back control to xfce4-power-manager and everything works as it should. Perhaps something for the devs to look into; maybe Devuan should set this property by default?

Edit: Just to be clear, I now only have two acpi events/scripts defined, one of which is my home made mic-mute function:

$ ls /etc/acpi
events  powerbtn-acpi-support.sh  thinkpad_micmute.sh

$ ls /etc/acpi/events
powerbtn-acpi-support  thinkpad_micmute

So the whole suspend & lock on lid close process takes place elsewhere (i.e. xfce4-power-manager), and all that digging in /etc/acpi only turned up a red herring. Smelly, but red.

No that didn't work - or at least not while xfce4-power-manager is running. I noticed that if I kill it then light-locker will lock the screen when I close the lid (because CheckPolicy now returns false in the acpi lid script). If xfce4-power-manager is running nothing at all happens when I close the screen. xfce4-power-manager --debug shows nothing when the lid is closed and opened.

Oh and I realised I made a mistake earlier; I shouldn't have run xfce4-power-manager --dump as root, this will give misleading results since it normally runs as the user.

So I noticed something odd, on my X230 I have installed the acpi-support package (or something has pulled it in as a dependency), but this was not installed on the T410. It's really just a bunch of event definitions and handler scripts for /etc/acpi - including things like volume up/down, and lid close. So this is the mechanism my X230 uses to control the volume for example, which is why I don't need to add them as Application Shortcuts on that machine. BUT. Now that I have installed acpi-support on the T410, it still doesn't work without the Application Shortcuts, despite the event looking identical on the two systems (e.g. button/volumedown VOLDN 00000080 00000000 K). So something else is missing or getting in the way.

There's more. The acpi-support package also installs an event and support script for "lid" events - and this does get triggered when I open/close the lid (I moved my hommade acpi lid event handler out of the way first, of course), but it exits on the first condition:

/etc/acpi/lid.sh:

if { CheckPolicy || HasLogindAndSystemd1Manager; }; then
        exit
fi

Ok, so we don't have SystemD, it must be CheckPolicy which returns true then. Turns out CheckPolicy is just a list of power management utilities - including xfce4-power-manager - which, if present on the system, should handle the lid events.

/usr/share/acpi-support/policy-funcs:

...
CheckPolicy() {
        local PMS

        getXconsole
        PMS="/usr/bin/xfce4-power-manager /usr/bin/mate-power-manager /usr/lib/dalston/dalston-power-applet"
        pidof -x $PMS > /dev/null ||
        PowerDevilRunning ||
        GnomeSettingsDaemonPowerRunning
}
...

Or so the acpi script expects and happily exits. So I come back to xfce4-power-manager and not acpi as the likely culprit; hence the output of sudo xfce4-power-manager --dump above.

Seems I'm not alone experiencing a blank screen after resume: https://www.reddit.com/r/xfce/comments/ … umes_to_a/