My family just recently switched to Ubuntu Mate 16.04 LTS on our matching Thinkpad 11e’s. I’ve been running mine for about two weeks or so without issue, but just today my Dad’s froze. I’ve experienced two other Linux freezes before (at Fedora) and recovered by holding down the power button, but I’ve heard that it’s better to avoid a hard restart.
I had heard that the key combination alt + SysRq + reisub will gracefully restart, and that SysRq is usually the same as PrtSc. I tried it and it didn’t seem to work. I ran the command cat /proc/sys/kernel/sysrq to see if SysRq is enabled on my computer. According to this, this will show 1 if it is activated on 0 if not. But I got the number 176 instead, not sure what this means?
$ cat /proc/sys/kernel/sysrq
176
So is this command available in 16.04? What options do I have to recover from an unresponsive system? We ended up doing a hard restart, and I’m not at all sure that was the healthiest thing for the system.
It is available and from Ubuntu 12.10 up the control of sysrq is more finegrained and the settings are in:
/etc/sysctl.d/10-magic-sysrq.conf
the default being 176. Take a look at the file, it's self documented in the comments (/proc/sys/kernel/sysrq gets its value from this file).
Some things to keep in mind: Some keyboards don't like 4 keys being pressed at the same time, so unless you do some reconfiguring, the magic is not happening. Some laptops require Fn key to be pressed to activate the SysRq key. Some laptops have reassigned the SysRq key, so it's not in the same key as PrintScreen (could be End - or some other key). Some work with only the right Alt being pressed. And so on. So you may need to do some investigative work (and google with the laptop's model!).
SysRq assumes QWERTY. If you use some other keyboard layout, please see alternative key assignments for the "magic sequence":
Thanks for all your help, but I'm coming to the conclusion that there probably isn't a fix. My graphics card is about 12 years old. Ubuntu has a note on their webpage USN-3173-1: NVIDIA graphics drivers vulnerability
that the driver for my particular card has 44 new bugs. I could be wrong, but I don't foresee a high level of priority being attached to ironing out the driver bugs for graphics cards the age of mine.
That being the case, it seems that I have only two choices:
1. get another graphics card, or
2. recognize that the occasion crashes/lockups I get are the result of this graphics driver incompatibility and just deal with it using Alt+SysRq+REISUB
Sometimes all I can get my laptop to do is switch to the console with Control-Alt-F1 (+Fn on my laptop). From there I can at least log in and then run the shutdown command. Open programs’ data is lost, but a little safer for the disk.
Thanks for the link, but we’re not having any driver issues (thankfully!). : ) It was an apparently random freeze, and two other 11e’s have been running Ubuntu Mate 16.04 LTS without issue. I just wanted to figure out this “magic sysrq key” for the next time I have to deal with a frozen Linux system. I’ll probably have to research my particular brand of laptop to find the right keys.
Thanks so much! I peeked in that file, the settings are there. The comments say to add up the numbers next to the various options to enable them—what does 176 enable, exactly? I’m trying to add up various number combos in my head but I’m not getting anything. If this answer is in the docs somewhere just leave a link.
And yeah, I got the impression the keyboard is an important factor. I’m not sure where the SysRq is on my keyboard, I’ll have to google that. I’ve got the US English keyboard layout so all the key assignments are ordinary. I tried pressing the Fn key but it didn’t work. I think I was pressing the left Alt key, though. So some googling is definitely in order!
And thanks again for the combo to restart X. I found the settings easily, it’s in System-> Preferences-> Keyboard-> Layout -> Options on my computer. BTW, why is it not enabled by default? Is it a security thing? Is it always worth enabling it or should I leave it alone if I’m not experiencing issues?
That setting allows using the REISUB sequence (see Wikipedia for more info on what REISUB does).
As for the Ctrl+Alt+Backspace combo: I have no idea why it’s not enabled by default. I don’t think it has any security implications. I always switch it on, just in case. If never needed, all the better.
@ouroumov Thanks for the link, this does seem to be the issue for me. My 11e has an Intel Celeron N2940, and I have experienced random freezes twice now (once at Fedora 25, and today at Ubuntu Mate 16.04).
This is a horrible bug IMO, it’s like a Linux BSOD. Also, people always say Linux is a good choice for lower end hardware—which is what this bug affects. I have lost work over it before. Fortunately it seems to happen fairly rarely on my 11e, but I sure hope it’s fixed soon. I don’t really want to disable CPU power saving because I run my 11e on battery often.
But since this does happen, is it possible to recover using Ctrl + Alt + Backspace or the magic SysRq key combo? The only way I know how to recover now is holding down the power button. When Ubuntu freezes, nothing works, not the mouse, nor Alt+F2. I can’t switch to another tty either. I hadn’t enabled Ctrl+Alt+Backspace, but I have now. I hope it doesn’t happen again, but if it does I’ll try that first.
Thanks for explaining, makes sense now. :^) So REISUB is enabled when I tried to use it, either I don’t know the SysRq key or the system wasn’t responding. I enabled Ctrl+Alt+Backspace after having a freeze on my 11e just today. :^(
The issue seems to be Bug 109051 - intel_idle.max_cstate=c1, which I found listed as item number 3 in the Ubuntu Mate known bugs page. My 11e has an Intel Celeron N2940, one of the processors affected by the bug. Not a nice bug.
Oh, so it’s a bit different now? Should I only use the new systemctl command or will the old one work still? I was reading a guide on recovering from a freeze that listed the old one, but it is several years out of date. I have noticed that often deprecated commands are kept as aliases for the new ones, though.
Unfortunately, I just experienced two freezes in a row. :^( I was forced to use hard restart again because none of the other options worked. First I tried Ctrl+Alt+Backspace, but it didn’t work. I couldn’t switch to another tty, either. Then I tried to do the SysRq key but nothing happened—this could be because I’m still not entirely sure where the SysRq key is on my keyboard. Some web hits said to hold down Alt+Prtsc, another said press Alt+Fn+S, release S, then go through the reisub sequence. Neither seemed to do anything.
For those of you who have used the SysRq key in the past, what exactly is supposed to happen? Shouldn’t the X session terminate after sending the signal to kill remaining processes? I was just pressing these keys without anything happening.
Second, have those of you who are affected by Bug #3 on the 16.04 known bugs thread succeeded in recovering by restarting X or the SysRq key combo? Every time it has been a COMPLETE freeze, and no keypresses have worked. Is hard reboot really the only option with this bug?
From my experience (had the bug on a machine with Intel J1900), yes. It's a complete kernel crash. I suspect Magic SysRq needs basic functionalities to keep working in order to work.
You can try Magic SysRq while your computer is operating normally to know what key combination is used on your hardware.
Just experienced another crash, but I think I’m figuring this out.
I was installing a program from CD in virtualbox when the system locked up.
Used REISUB to shutdown and was expecting to just be able to restart. When I restarted I was getting page after page of ATA bus error.
Booted to a live USB and went online. Most people who had this problem solved it by switching or unplugging and replugging their SATA cables, so I shutdown and did this.
When I rebooted the error message said I need to do a manual fsck. So I did this.
So this is my question: What are the implications of an ATA bus error? Is this just a loose connection? Is my motherboard going? Are there any test programs I can run to detect and/or address this?
