This thread's initial OP appears below this Workaround Alert. Since folks afflicted by Intel's 'Linux Suspend > Dead NUC' intermittent defect can no doubt benefit most from learning how to avoid getting their NUCs bricked by it, it seems wise to present these bricking avoidance techniques at the top of this thread; and of course you're at liberty to read the whole conversation below, from which they derive.
Workaround Alert
or 'How To Avoid Getting Your NUC Bricked by Linux Suspend'
TL;DR – use wake-on-USB to wake with an input peripheral (eg: keyboard, mouse, trackpad, etc.) or wake-on-LAN from a smartphone app.
Many reports in these forums, dating back to August 2014, show that the Intel NUC is afflicted by an as yet unfixed design flaw: when run under several different distros of Linux (Ubuntu, Arch, Mint, Fedora, Debian), each use of the Linux Suspend function carries a small but real risk of initiating a NUC-bricking incident. Susceptible NUC users are those who use a short press on the Power button to wake from suspend, because the first symptoms of an impending NUC-bricking incident are as follows.
NUC-Bricking: Symptoms #1
When Linux Suspend is used and works normally, the NUC goes into sleep mode, and the Power button LED winks amber. When the 'Linux Suspend > Dead NUC' problem occurs, these are the symptoms which afflict sleep mode:
- a short press on the Power button does not wake the NUC (as it ought to, and usually does) – the amber winking just continues; and
- a long press on the Power button does not switch the NUC off (as it ought to, and usually does) – the amber winking just continues.
See 'Bricking Avoidance Workaround' below for ways in which to successfully wake a NUC exhibiting these symptoms, rather than experience...
NUC-Bricking: Symptoms #2
Once a NUC is in the grip of symptoms #1, the only way to get the NUC to power off is by disconnecting the power cable. After the power cable is reconnected:
- a short press on the Power button does not switch the NUC on (as it ought to, and usually does) – the NUC is bricked; and
- a long press on the Power button does not start the NUC up in Power Button Menu mode (as it ought to, and usually does) – the NUC is bricked.
Unbricking Workaround: to get a thus bricked NUC to work again, you have to fully disassemble the NUC, disconnect and reconnect the CMOS battery from the far side of the motherboard, and reassemble the NUC. Such a drastic remedial action highlights the nature of this failure mode as a manufacturer design defect.
Bricking Avoidance Workaround
Two ways of avoiding the NUC-bricking consequence of symptoms #2 are known to be effective, and both involve alternate ways of waking a sleeping NUC: by input peripheral (wake-on-USB), and by mobile device (wake-on-LAN). They both take some setting up, which is described below.
BIOS Settings for Wake-on-USB and Wake-on-LAN
On booting up your NUC, press 'F2 to Enter Setup' on your keyboard to go into Intel Visual BIOS Settings. On the Power tab (Advanced pull-down menu > Power), set your Secondary Power Settings to match those illustrated below.
![Wake-on-keyboard-BIOS-Settings.jpg]()
Photo credit: sylvia_intel
Press 'F10 - Save and exit' (and 'Y' to confirm) to save these settings and reboot your NUC.This may well be all you need to do, so test to see if you can now wake from suspend with the USB-connected input peripheral of your choice (eg: keyboard, mouse, trackpad, etc.); if it works OK, then you should also be able to use it after a Linux shutdown to boot up your NUC.
OS Settingsfor Logitech Wireless Input Devices
My Logitech wireless keyboard+trackpad and wireless trackpad didn't work straight away to wake from suspend, but community assistance soon got them working flawlessly – so if you too are using Logitech wireless input devices, please see the '2. OS Settings' section of post #39 below (» https://communities.intel.com/message/362981#362981 ) for additional set up instructions.
Wake-on-LAN Apps
To boot up and wake from suspend using wake-on-LAN, you can use a smartphone/tablet app – so just search your mobile device's app store for 'wake on LAN' to acquire an appropriate app. For instance, I've tested the free 'Wake On Lan' Android app by Mike Webb, available in the Google Play store, and it works perfectly. Similar apps are also available for Apple iOS devices.
Workaround Works – Fix is Pending
Once you've settled in to routinely using either wake-on-USB (ie: wake-on-keyboard, wake-on-trackpad, etc.) and/or wake-on-LAN, then even if symptoms #1 of the 'Linux Suspend > Dead NUC' defect should arise again, they'll most likely go unnoticed, since you'll no longer be using a power button short press to end a suspend – and a simple routine tap on an input device or mobile app will wake your NUC as usual.This workaround thankfully avoids the NUC-bricking effect of symptoms #2, but it does not eliminate the 'Linux Suspend > Dead NUC' defect – so we are still waiting on Intel and System76 to come up with a permanent fix for this defect; and that's why this thread remains tagged as 'This question is Not Answered'.
__________________________________________________________________
Dear Intelistas,
I have an Intel NUC5i5RYH (rebadged as a System76 Meerkat), which was delivered on 14 Oct 2015, with Intel BIOS v.0249 in firmware, and it booted from its M.2 SSD [1] into pre-installed Ubuntu 15.04 in around 15 seconds.
My NUC has now been bricked by the well-known 'Ubuntu Suspend > Dead NUC' problem [2] fivesix* times (in 54 58 days of usage), about which many threads exist here at communities.intel.com (dating back at least a year) – and here is a list of what steps I've taken from those threads as potential fixes and implemented on my NUC, but all to no avail:
- upgrading the BIOS firmware: neither Intel BIOS v.0350 nor v.0352 (nor System76 BIOS v.0350) eliminate the 'Ubuntu Suspend > Dead NUC' problem – and upgrading has slowed down its boot time from ~15 seconds to ~2 minutes <sigh>
- mikec_intel's BIOS settings fix [3] does not eliminate the 'Ubuntu Suspend > Dead NUC' problem
- prigaux's 'echo 0 > /sys/power/pm_async' fix [4] does not eliminate the 'Ubuntu Suspend > Dead NUC' problem
For now, the only effective way to avoid getting my NUC bricked for a sixthseventh time would seem to be the major inconvenience of avoiding using the Ubuntu Suspend function altogether; and I'd be very grateful if anybody could recommend a way to get my NUC back to booting up in ~15 seconds, as it did when new (and as might be expected from a motherboard-bound SSD boot drive).
Has Intel really failed completely to address this 'Ubuntu Suspend > Dead NUC' problem?
Or is there yet another potential fix to the 'Ubuntu Suspend > Dead NUC' problem I should try?
Thanks in advance for your attention and help.
Yours in frustration and disappointment,
Tim Jones
__________________________________________________________________
* UPDATES are in red: My NUC has now been bricked by the well-known 'Ubuntu Suspend > Dead NUC' problem SIX times (in 58 days of usage).
[1] Its M.2 SSD: "M.2 SATA: Samsung SSD 850 EVO M.2 250GB : PART 0 : Boot Drive"
[2] The well-known 'Ubuntu Suspend > Dead NUC' problem:
- Mean time between failures: 9.7 days (6 failures in 58 days use, in my personal experience) 10.8 days (5 failures in 54 days of use, in my personal experience)
- Symptoms #1: each use of the Ubuntu Suspend function carries a small but real risk of bricking the NUC. When Ubuntu Suspend is used and works normally, the NUC goes into sleep mode, and the Power button LED winks amber. When the 'Ubuntu Suspend > Dead NUC' problem occurs, these are the symptoms which afflict sleep mode:
- a short press on the Power button does not wake the NUC (as it ought to, and usually does) – the amber winking just continues; and
- a long press on the Power button does not switch the NUC off (as it ought to, and usually does) – the amber winking just continues.
- Symptoms #2: the only way to get the NUC to power off is by disconnecting the power cable. After the power cable is reconnected:
- a short press on the Power button does not switch the NUC on (as it ought to, and usually does) – the NUC is bricked; and
- a long press on the Power button does not start the NUC up in Power Button Menu mode (as it ought to, and usually does) – the NUC is bricked.
- Workaround: to get my NUC to work again, I have to fully disassemble the NUC, disconnect and reconnect the CMOS battery from the motherboard, and reassemble the NUC.
- Users of Linux distributions other than Ubuntu (eg: Arch Linux, Fedora, Linux Mint) have also reported experiencing this NUC bricking on using Suspend, so it could be described more inclusively as the 'Linux Suspend > Dead NUC' problem.
[3] mikec_intel's BIOS settings fix – as detailed in:
● 'NUC5i7RYH did not wake from sleep mode', 11-Sep-2015 to 15-Nov-2015
» https://communities.intel.com/message/331090#331090
...and involves making changes in Intel Visual BIOS settings.
[4] prigaux's 'echo 0 > /sys/power/pm_async' fix – as detailed at post #10 in:
● 'NUC dead after suspend mode in Ubuntu 14.10', 23-Dec-2014 to 28-May-2015
» https://communities.intel.com/message/309188#309188
...and involves using rc.local to write '0' into /sys/power/pm_async at each boot up.
PS: I've sought help from System76 tech support, but sad to say they're about as useful as a chocolate teapot – so I'm hoping the Intel NUC community might be of some actual help in addressing these problems. After an email of complaints to System76 CEO Carl Richell, the 'chocolate teapot' tech (non-)support staffer has been replaced by a honest and helpful operations manager, and a possible fix has been encoded in a 'System76 Driver' update, so System76 are at least striving to address this defect; meanwhile Intel are asking for more time to investigate the problem (07 Jan 2016 update).