Magic SysRq key not mapped on native Chromebook keyboards/ USB Keyboards works perfect

[scofieldbrks]

My Asus C202SA (and Samsung 3 CB) has no print-screen/sysrq key and the media/ key binding charts on the Gallium website do not mention the sysrq key or the bindings to start magic sysrq (ALT+Sysrq key on regular computers). I have added a USB keyboard and Magic SysRq works great on the USB keyboard. There are no correct bindings for Magic SysRq for native Chromebook keyboards. Alt+Volume Up has been mentioned as a possible mapping, but it does not work. The only key that does anything with that schema is "r" and that should unraw the Keyboard from X. Instead it instantly shuts down the computer and corrupts the filesystem. GalliumOS developers need to fix the Magic SysRq system mappings on the native keyboards. I suspect the lack of Magic SysRq is universal across Chromebooks without a Print-screen key. Pressing MagicSysRq (ALT + Volume up) + "r" should not kill system with file corruption. The fact that MagicSysRq works with a USB keyboard and an edited /etc/sysctl.d/10-magic-sysrq.conf demonstrates GalliumOS supports MagicSysRq, but the GalliumOS team have not correctly mapped the print-screen key to enable MagicSysRq on native Chromebook keyboards.

OLD INFORMATION*GalliumOS 2.* fails to poweroff after 18-24 hours (GUI-simply logs off and back on again and Terminal-all poweroff commands are "destructive") and a buggy system like GalliumOS needs MagicSysRq with the absolute highest priority.*** FIXED- Gallium 3.0

NEW : Gallium 3.0 magic SysRq on-board keyboard mapping on Chromebooks still not addressed. alt+VolUp+r forces INSTANT shutdown-down and immediate re-boot, instead of changing keyboard mode from raw to XLATE. - 5 May 2020

[ghost]

I agree that we should have some implementation of the magic SysRq key but I've never encountered the failure to poweroff issue. Where exactly did you get the idea that terminal poweroff commands aren't safe? I shut down and reboot my system with sudo systemctl poweroff and sudo systemctl reboot respectively all the time.

[scofieldbrks]

I never said anything about safe or not. The system(**OLD- Gallium 2.1) responds with "This action is destructive. Not Allowed" and returns command prompt and refuses to shut-down. I haven't seen this error since 3.0, but kernel panics still require a need to implement correct mapping (this post is 2 years old and still no fix!)
The penultimate purpose of the magic SysRq is for a kernel panic. Every linux box I have ever had that experiences a kernel panic, you can't type sudo s. I mean, blasting your system off without a proper shutdown is actually unsafe, if you expect it to work without fail on re-start....

[scofieldbrks]

The one time I did have a kernel panic with Gallium 3 with the USB keyboard active, it failed to respond to the USB keyboard. On-board keyboard mapping for magic SysRq would be needed to address these Chromebook keyboard shortcomings of missing keys. GalliumOS is truly unique in that magic SysRq cannot be invoked in linux despite being properly configured, due to hardware. during a kernel panic. USB keyboard and normal OPS, No problem. magic SysRq works as normal. 176 or 1. No prob.

[scofieldbrks]

Let's have a Gallium OS guru address this issue. Anyone??

[reynhout]

@scofieldbrks Well, since you asked so nicely...

The GalliumOS kernel includes the required settings for SysRq:

CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_MAGIC_SYSRQ_SERIAL=y

Keyboard mappings can vary significantly by model. We use a combination of ChromeOS mappings plus some customizations. Not all models are fully or uniformly covered.

FWIW, I have also never experienced a natural kernel panic on GalliumOS.

Edit: I just re-read the issue history and realized that you are also the initial reporter. It sounds like you understand this issue fully, so what kind of help can we offer to add SysRq to your keyboard mapping?

[scofieldbrks]

Hi, I checked my /boot/config-4.16.18-galliumos file, and the required settings you listed are correct and present. And as I previously mentioned, magic SysRq works fine on a USB keyboard during normal operations. My magic SysRq works fine when things are fine ONLY on a USB keyboard. What I would like is some key combination (alt+Vol Up??) to invoke magic SysRq to properly run magic SysRq r-e-i-s-u-o or b on the native Chromebook keyboard. Currently alt+Vol Up + r blasts the system off and on in a millisecond. That is not proper magic SysRq behavior. r should only switch the keyboard mode from raw to XLATE, not nuke the system. That's awesome you have never had a kernel panic, that's not my experience.

It seems like an improper line of code is missing up the magic SysRq implementation on the native keyboard. I suspect the Gallium developers have used a faulty build of the magic SysRq module for the Chromebook keyboard layout.

[scofieldbrks]

Update: I just re-verified the USB keyboard on GalliumOS and it works perfectly. It is just the native Chromebook keyboards on my ASUS and Samsung Chromebooks that the magic SysRq does not work.

[reynhout]

@scofieldbrks I agree that this is a worthwhile effort, but I don't have a solution for you. Hopefully someone will prioritize and fix, if you are not able to do so yourself.

[reynhout]

Note: OP failed rule 0, so I've locked the topic for now, and deleted non-substantive comments.

Leaving this issue open, because original support request is valid and a good project for future development.

[ghost]

Even if we mapped SysRq in the xkb-data package, wouldn't it only work when the user is looking at an Xorg session? In other words not during a kernel panic or whatever other bad situation would lead one to desire using that particular button.

[reynhout]

@coltondrg Yes, I think the keypress event is caught in the kernel (kbd driver) itself. I'm not sure how much flexibility there is with modifier key masks to create a mapping that fits Chromebook hardware options.

But I've never looked into it -- it might be a simple fix.

[doug445]

Well reynhout, if it's so simple, let's fix it and get on board with every real distro of linux. How difficult can be correct keyboard mapping be for a programmer???

[sunaku]

ProTip: :tipping_hand_person: Here is the workaround I use on my Samsung Chromebook Pro (CAROLINE):

#                        _        ____            ____         _
#  _ __ ___   __ _  __ _(_) ___  / ___| _   _ ___|  _ \ __ _  | | _____ _   _
# | '_ ` _ \ / _` |/ _` | |/ __| \___ \| | | / __| |_) / _` | | |/ / _ \ | | |
# | | | | | | (_| | (_| | | (__   ___) | |_| \__ \  _ < (_| | |   <  __/ |_| |
# |_| |_| |_|\__,_|\__, |_|\___| |____/ \__, |___/_| \_\__, | |_|\_\___|\__, |
#                  |___/                |___/             |_|           |___/
#
# bind VolumeUp/F10 key at top-right corner of Chromebook keyboard as SysRq
#
# https://www.reddit.com/r/GalliumOS/comments/4eb81n
# https://royal.pingdom.com/troubleshooting-sysrq/
# https://www.kernel.org/doc/html/v4.10/admin-guide/sysrq.html
#
setkeycodes 44 99

As a bonus, this also works outside of GalliumOS: I've used it successfully on Void Linux.

[travankor]

FWIW, I have also never experienced a natural kernel panic on GalliumOS.

Kernel panics rarely happen on chromebook hardware these days. sysrq is really useful outside of kernel panics, such as when userland programs misbehave.

I have my xkb keyboard model set to "chromebook" and alt+volup+r seems to reboot the system, but alt+volup+x does nothing. https://sites.google.com/a/chromium.org/dev/chromium-os/how-tos-and-troubleshooting/debugging-hangs

@reynhout I wonder if this problem could be fixed via firmware, too.