Thanks, I'll try that, but I just had a minor break through: I found this old issue on Xfce's old bugtracker: https://bugzilla.xfce.org/show_bug.cgi?id=11488 Reading a bit further down, there are details of a patch that has been applied to xfce4-power-manager, the description of which is:

"Aha" I thought, and tried setting lid close to "Lock Screen" in the power management applet, and hey presto, the computer now suspends and locks when I close the lid. If I remove the pm-suspend command from my acpi script it only locks, so this is still needed. And when it resumes the screen blinks multiple times before going to DPMS-off; I have to press a key on the keyboard to turn it back on. So it's not a perfect solution, but I'm definitely getting closer!

Edit: dconf-gsettings-backend is already installed.

Yeah, but the power management applet also has suspend and screen blanking timeouts, so I just use those, which works fine. I managed to get the microphone mute button working, complete with LED, by adding an acpi event that listens to the button press:

/etc/acpi/events/thinkpad-micmute:

event=button/micmute MICMUTE 00000080 00000000 K
action=/etc/acpi/thinkpad-micmute.sh

/etc/acpi/thinkpad-micmute.sh:

amixer sset Capture toggle

then:

sudo chmod +x /etc/acpi/thinkpad-micmute.sh
sudo service acpid restart

I actually remember doing this on my X230 as well. Now only volume mute LED and lid suspend left on my list.

Thanks. laptop-mode-tools was not installed. Unfortunately the only obvious difference after installing it is that the machine now hangs for ~20s when a reboot is requested. I saw that there's a "Mic Mute LED-Mode" in alsamixer, which is set to "Follow Mute", but there is no equivalent for "Master" (and I did press F5 to see all devices). More frustratingly it turns out that for some reason I cannot add an Application Shortcut for the mic mute button like I could for the master mute button; the button press is not registered by the Application Shortcut applet, though it does show up as button/micmute with acpi_listen. I have removed my attempts at lid switch control from /etc/acpi , and I've uninstalled xscreensaver, rebooted a few times, all issues remain.

Oh and there's really nothing of note in .xsession-errors, I see volume change events there when I press the volume buttons, but there are no errors when I do this, or close the lid (which adds nothing to the log), or press the power button (also adds nothing to the log). Xsession/dbus init looks completely normal.

Thanks. This is stock "Cinnabar" XFCE4 with the Slim DM. Beyond /home/user encryption (sshhh!) I haven't changed much. Had to mess around with the swap partition's UUID but that's now working (yes, encrypted - ssshhh!). Added xserver-xorg-input-synaptics to get clicks working on the touch pad (which enables an extra tab in the control panel app). Enabled unattended-upgrades and set up root emails to actually go somewhere. And yes, I got rid of pulseaudio, and got the volume control buttons (and mute) working as XF86 "Application Shortcuts", but yes, the mute LED does not come on. It does on my X230, and did on the X220 I had previously, and on neither did I have to add any "Application Shortcuts"; it just worked once I got all the desktop bits installed. And checking my X230 now I can see none have been created for me - it clearly uses some other mechanism (note: both systems run Devuan, ASCII on the X220 and ASCII upgraded to Beowulf on the X230 - neither has pulseaudio installed).

Edit: I am also still looking for a fix for the non-working power button, and a way to suspend and lock screen when the lid is closed.

Edit2: I should add, for the record, and in case anyone ends up here because they're searching for how to set up eCryptFS home directory encryption, that the required packages were pulled from the Buster release (and hence Beowulf) due to a critical bug which hadn't been fixed in time for the release. This has long since been fixed however, so I grabbed the latest debs from packages.debian.org and installed from there. The two packages you need are "ecryptfs-utils" and "libecryptfs1" ("libtspi1" and "cryptsetup" are also required but present in the Beowulf repos).

Massively irrelevant rant

Ok, so I think we can move on from the encryption stuff - but what about the other issues I encountered? I have searched for info about the non-working power button, and I've had partial success getting the volume buttons to work - albeit in a way that doesn't seem quite right. No luck with the lid close suspend, despite messing around with scripts in /etc/acpi/. I have never needed to fiddle with any of this stuff previously; it's always just worked - what am I doing wrong here?

Edit: Oh and I must apologise; I was indeed thinking of the "Expert install" flow in the ncurses set-up - I don't think I've ever used the other option. It's not as "expert" as it sounds though, I find it really quite easy to use, with sensible defaults for most things.

No I did it after installing a minimal system, and it's eCryptFS - a stacked filesystem that can be mounted on any directory and on top of the main file system.

sudo apt-get install ecryptfs-utils cryptsetup

Then, while logged in as a different sudo user to the one you want to encrypt /home for

sudo ecryptfs-migrate-home -u user

Where "user" is your username. When the command completes you must log out and back in as "user", before rebooting. Then you should generate a recovery passphrase and write this down somewhere safe (I typically just take a picture of it with my phone - which is also encrypted, with LUKS in fact).

ecryptfs-unwrap-passphrase

Finally, to make the system fully secure, you should also encrypt /swap

sudo ecryptfs-setup-swap

And that's pretty much all there is to it.

Umm... That's not quite true; the text based set-up does default to a UK keyboard layout after you've chosen UK as your locale. And It doesn't put 100s of items in a drop-down list. And it doesn't force you to choose "Other" if you happen to be a non-US user.

I respectfully beg to differ. Sudo is easier to audit, easier to administrate (by adding removing users from /etc/sudoers), and it will time out the escalated privileges after a certain interval, reducing the risk of leaving a machine unlocked with a root shell by accident. And if you really do need a root shell, sudo -i is your friend. I didn't come here to argue about that though - to each their own - but I wanted to mention that even when I chose the middle option on the first screen that said "use sudo / disable root account" I was still asked for a root password on the next screen, with another two checkboxes relating to root locking. The wording and function of these (five) checkboxes was pretty confusing.

Also, the installer died whenever I did something it didn't expect, like close a window or Ctrl+C a long running write of /dev/random to disk. The text based installer does not behave like this;  at any point you can go back and redo earlier steps, and cancelling the current step simply takes you back to the menu. Furthermore, as each step is completed it helpfully moves to the next item in the menu, skipping those steps which your choices have made redundant. It's always clear where you are, and what is left to do, and a lot of the time all you need to do is confirm the sensible defaults by pressing return. You also get a lot of options that were missing from the GUI installer, such as configuring the network, setting up NTP, fetching latest packages, choosing what to install...

Oh thousands I'm sure. But they all talk about how to make them work with Pulseaudio. I'll have another look though, now that I have some idea where this is configured - thanks for that! It is odd that I haven't needed to do this on the Thinkpad X220 and X230 laptops I've previously installed Devuan on - maybe because I've built them from netinstall and up, maybe because there's some difference in how the hardware hotkeys work on the T410. 

You forgot the option I like to go with; use the user's login to decrypt /home. I'm not 100% sure how this bolts together (pam + ecryptfs?), but it certainly doesn't involve storing the decryption key in plain text on the machine, nor does /home need to be on a separate partition - I have to enter my (strong) password to decrypt and mount the directory as /home, but this is done seamlessly from the Slim login window. One login, two actions. And yes, I do think that's secure enough; it would take a pretty determined hacker to brute force my password, or to hijack my locked session if I left my laptop unattended in suspend somewhere - and if they can do that then it doesn't really matter how my data has been encrypted; if you're in you're in. It's not as if I'm storing the next Panama Papers or anything.

Ok, thanks, I'll take a look!

Yeah, that was one of the first things I tried - I inserted a card and waited a good while (in case of logging being delayed by caching) but absolutely nothing happens.

Thanks! I thought adding CRYPTSETUP=y to /usr/share/initramfs-tools/conf-hooks.d/cryptsetup was how to "manually add it" to initramfs, but since the warning persisted that's probably not correct. How should I do it? I don't have encrypted root, only swap partition and home directory. Home directory isn't decrypted at boot of course, and a missing swap partition should be easy to get around - but I'd still need to fix it...

Edit: Just saw your edited post.

Excellent, then it is as I thought, and the warning is misleading. Thank you!

That was easily fixed by simply doing

apt-get install libelogind0

I now get a clean upgrade plan in aptitude.

12:50 Press return.