Control: tag -1 moreinfo Hi Jonas!
On Tue, 16 Nov 2021 at 17:22:54 +0100, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2021-11-15 18:06:57)
>> cryptsetup-suspend looks promising, but unfortunately failed for me so
>> far on my ARM-based laptop - TERES-I - running an up-to-date bookwork
>> sytem with with the Wayland-based window-manager Sway: Without
>> cryptsetup-suspend, waking up leads to screen being backlit-black
>> where I can either hit ESC and get visual feedback from sway-lock, or
>> CTRL+ALT+F2 and get a text console; with cryptsetup-suspend installed,
>> waking up also leads to screen being backlit-black but not responding
>> to keyboard entry - system is however enough restored that I can power
>> it down and then examine the journal.
>
> Still unresponsive after wakeup without swaylock.
>
> That laptop has an odd builtin keyboard that requires a 2 second delay
> in u-boot or it fails to initialize. But that should not be an issue
> here: I can enter LUKS password succesfully - only afterwards the screen
> switches to a deadlocked state.
Do I understand correctly that:
1/ the system suspends properly (presumably after suspending the LUKS
devices);
2/ waking the system ups yields a cryptsetup prompt and the disk(s) can
be unlocked properly; but
3/ you don't get your window manager as you left it?
?
Does `sudo openvt -ws -c8 -- sh -c 'echo hello; sleep 3'` switch to VT8,
print there, and switch back to the window manager some seconds later?
If not, then the issue is the hardcoded VT-switching logic and we'll
need to find another workaround. If yes, then perhaps adding `set -x`
at the top of /lib/cryptsetup/scripts/suspend/cryptsetup-suspend-wrapper
might shed some light on the execution flow? You'll find the trace at
`journalctl -u systemd-suspend.service`.
Cheers,
--
Guilhem.
signature.asc
Description: PGP signature
