On 2020-04-18 at 21:59:35, Ben Hutchings wrote: > Control: tag -1 wontfix > > On Sat, 2020-04-18 at 18:50 +0000, brian m. carlson wrote: > > Package: src:linux > > Version: 5.5.17-1 > > Severity: important > > > > By default, Debian ships kernels such that when booted with Secure Boot, > > that a user cannot hibernate their computer. However, the combination > > Alt-SysRq-x is documented in the wiki (which is linked to from the > > kernel) to lift these restrictions and allow the user to hibernate. > > > > However, in this kernel version that does not work, and the user must > > either disable secure boot or forego hibernation. When pressing > > Alt-SysRq-x, the following is printed: > > > > sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffer(z) > [...] > > This was an intentional change listed in the changelog, fixing bug > #947021. Thanks for mentioning the wiki; I'll update that to reflect > current reality. It looks like Ubuntu allows people physically present to use the key still with their proposed patch. Is there a reason that patch can't be applied here? > If you can't live with the restrictions of Secure Boot, you'll have to > turn it off. Can you explain why this restriction is required in the first place? Other operating systems use Secure Boot and allow hibernation, so it can't be that it's an intrinsic limitation. I'd like to have the behavior where I know that my boot process hasn't been tampered with, but I don't need to be locked out of my system or have important features turned off. Surely that's a valid use case that should be supported. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature