Notes on Successful LM-18.2 Install on Intel NUC7i5BNH

Chat about anything related to Linux Mint
DaveUdon
Level 1
Level 1
Posts: 4
Joined: Sun Jul 09, 2017 2:38 am

Notes on Successful LM-18.2 Install on Intel NUC7i5BNH

Postby DaveUdon » Sun Jul 09, 2017 4:43 am

The newish Intel NUC7 series is a definite hardware upgrade from the earlier models. I was hoping to use my LM-17.3 image file copied over from an out-of-warranty NUC, but it wouldn't boot cleanly. I quickly found that the NUC7 driver focus is on Win-10. Linux is NOT directly supported, as I learned to my chagrin after purchase, build, BIOS flash to latest f/w, attempted boot, and sudden interest in research. Linux users are expected to rely on their distros for Intel video and wifi driver compatibility. I needed a Linux Mint upgrade...

LM-18 and Ubuntu 16.04 are the minimum Linux requirement. The 17.3 LiveCD did not load successfully, with video gibberish I could not recover from. I decided to do a clean install with LM-18.1 Cinnamon a few days before 18.2 went live. My USB-3 (strongly recommended) LiveCD loaded nicely without the dreaded black software-rendering warning. Hmm... means there's hope recognizing the Intel Video card! Once installed, and again without any video warnings, I restored my /home directory from the 17.3 luckyBackup Restore function and rebooted. (I'm a firm believer in luckyBackup rsync...)

Voila, the familiar 17.3 desktop, settings and links intact! The next few hours were spent on discovering which app packages needed re-installation due to broken links.

I upgraded to kernel 4.8, hoping for the best compatibility with the NUC hardware. I was rewarded with the NUC's new onboard wifi chip being recognized in the Network Manager box!

The video quality is excellent with 1080p movies using the Video app. Sorry, I'm not into 4k for analysis...

I attempted an upgrade to LightDM, but stopped when I ran into too many problems using a non-forum method. I'll stick with MDM for now to see if I run into as many freezes as I was experiencing with 17.3. It's been a week so far with only a few screen glitches...[EDIT: Installed LightDM cleanly using Clem's blog, and I'm delighted: system now boots in 8-9 secs.]

Ok, here are some notes I hope will be useful to the LM/NUC community:

After trying to overcome long delays in booting, sometimes with no display of F2-F7-F10 under the Intel logo, I reloaded the F9 BIOS default settings many times. After discovering several reasons for the long delays (below), in the end I made one change only to the BIOS -- disable UEFI booting. Unchecking the USB device in the Boot Configuration box will hide any USB devices in the F10 Boot Menu. So, leave that one on.

I found two reasons for the lengthy boot process by observing the screen POST events (ESC): 1) hanging on connecting to a local NAS which was powered off (but Ok under 17.3 on the older NUC), and 2) using a permanently-inserted USB-3 drive which had a fault in its formatting. I pulled out the stick, and F2-F7-F10 immediately appeared.

SAMBA was quick to set up. It boots and runs without a hitch using this link as a guide: https://www.youtube.com/watch?v=dm0_9N3dY90 -- your mileage may vary, but it ran fine under both 17.3 and 18.2 for me.

If the local NAS is powered up during boot, then no problems. It was when powered down that I began experiencing 2-min boot delays. The solution was to remove the 'auto' option in the /etc/fstab line. This one works for me:

# noatime recommended for SSD
# (any suggested improvements?)
192.168.1.201:/volume1/Media /media/NAS nfs nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

With the minimal change to the BIOS, I can wake-on-lan locally using an iPhone or Android tablet.
Vino works well for VNC.

I relocated the Firefox and Chrome browser caches to a ramdisk using symlinks and this fstab entry:
# mount a ramdisk
tmpfs /media/ramdisk tmpfs nodev,nosuid,noexec,nodiratime,rw,size=2g 0 0

I installed Firejail (no changes to FJ's config files) for use with Chrome in browsing dodgy sites.
Oh, one thing there: Chrome under Firejail (Launcher Properties: firejail /usr/bin/google-chrome-stable %U ) will NOT launch if it sees its cache file in the ramdisk (why?). I wrote a script to test for and delete it if found, then launch Chrome. (Reply if the script may help you.)
Launches ok now.

VPN settings in the Network Manager work fine. One nag: I wish the panel icon would show a lock as in 17.3 when the VPN connection is active.

The system boots consistently now in 15 secs or less [EDIT: now 8-9 secs with LightDM]. I disabled hibernation, but found a problem with suspend-to-ram: the NUC went to S3 state (flashing amber light), and the screen went black. Pressing Enter or the Power button restarts the NUC, but the screen stays black. A Google search found a fix:

From: https://askubuntu.com/questions/770065/ ... er-suspend
In /etc/default/grub, make the following change:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor acpi_osi='!Windows 2013' acpi_osi='!Windows 2012'"
Followed by sudo update-grub and reboot TWICE (I've found twice to be unnecessary)

[EDIT: Suspending with the Menu | Shutdown | Suspend option has proved to be only 50% successful on recovery. I've had more consistent recoveries by using '$ systemctl suspend'. Create a desktop launcher with the 'systemctl suspend' command (without quotes ' ').

BUT... see my separate post-reply just below for a possible 100% solution.]

Finally: I am super-cautious yet willing to try new ways to improve my system, so I rely heavily on Menu | Preferences | Disks to create IMG files of my LM-18.2 partition, while using a Live-CD, to archive and document changes. In case of disaster, I quickly restore. I used it heavily as I progressed with the above events in stages.

I'm very pleased with the results and hope it helps you too...

Regards from NE Thailand, nr Laos
Last edited by DaveUdon on Mon Jul 17, 2017 5:27 am, edited 5 times in total.

DaveUdon
Level 1
Level 1
Posts: 4
Joined: Sun Jul 09, 2017 2:38 am

Re: Notes on Successful LM-18.2 Install on Intel NUC7i5BNH

Postby DaveUdon » Sun Jul 16, 2017 11:20 pm

Subject: Recovery from Suspend-to-Ram with blank screen -- on Nuc7 running LM-18.2 Cinnamon LightDM with kernel 4.8.0-58-generic, 16k-ram, 6Gb swap partition

I've spent a week on this, possibly with a 100% solution, and describing it needs this separate post which I will keep updated.

A browsing of the internet reveals this subject to be a thorny problem going back a long time, across many software platforms and devices, esp laptops. The most helpful website I've found for debugging and helpful info is:

https://01.org/blogs/rzhang/2015/best-p ... ate-issues

This group says it has been researching suspend-to-ram problems for years, and it offers step-by-step procedures to track down and report issues to both the team and Intel. It's a recommended read!

In my case, I could SSH in to shutdown, or VNC in to view the desktop hidden behind the black screen and manipulate it with mouse and keyboard. I could never invoke the virtual console, however, or restart LightDM.

My latest, hopefully final recovery solution follows. So far, it's been 100% successful in recovering to a desktop within seconds, although directly and without a login prompt. Since I'm the sole user at home, I'm Ok with it. I did see suggestions online, however, to recover to a login screen.

1) From the main post above:
From: https://askubuntu.com/questions/770065/ ... er-suspend

In /etc/default/grub, make the following change:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor acpi_osi='!Windows 2013' acpi_osi='!Windows 2012'"
Followed by sudo update-grub and reboot TWICE (I've found twice to be unnecessary)

2) Disable the Menu | Shutdown | Suspend box using https://sites.google.com/site/easylinux ... nd-to-ram- (section 10.2)

Until I did this, I could get nowhere in recovering consistently.

3) Refer to section 2.7 pm_async in the above 01.org debugging link:

# echo 0 > /sys/power/pm_async (sudo didn't work for me -- I needed su -)

This setting is in a checklist of status items to report to the team (ie, "yes, it helps recovery work", or not). In my case, it helps it work more consistently, and I will leave it in place.

4) The team's 01.org debugging link above always refers to '# echo mem > /sys/power/state' to invoke Suspend, and never 'systemctl suspend'. When I began using this echo command, I could always recover to the desktop. Hopefully, I have found my solution... we'll see.

5) Suspend-to-Ram uses both internal ram and the swap space. My combined /root + /home partition uses 15 Gb. I have 16 Gb of ram, but 1.5 Gb is used for a ramdisk (Firefox cache). Although I increased my swap space from 2 Gb to 6 Gb to ensure plenty of suspend memory, it was apparently not helpful while I continued to use 'systemctl suspend'. It wasn't until I used '# echo mem > /sys/power/state' that 100% recovery occurred. I'll try reverting to less swap space later.

6) How to launch Suspend from the desktop in one click plus password entry? Here are my Launcher details:

The Command is 'gksudo /home/<user>/suspend.sh'
"Launch in terminal?" box is unchecked.

Here is my Launcher's bash script, suspend.sh, which runs a second, streaming script under root-user. The reference is https://stackoverflow.com/questions/198 ... -that-user

--------------------------------------
#!/bin/bash

## SUSPEND-TO-RAM using a 'heredoc' under root user
#----without pswd entry, if run within a terminal, ie $ sudo -i bash <<EOF (with add'l streaming lines)
#----needs gksudo, if this script is run in Desktop Launcher

# 'heredoc' is from: https://en.wikipedia.org/wiki/Here_document

# run a streaming heredoc under root user
sudo -i bash <<EOF

# heredoc streaming begins under root user
echo mem > /sys/power/state
EOF
# heredoc streaming ends
--------------------------------------

UPDATE: Nearly a week later, suspend/recovery from ram began to fail repeatedly with the black screen, but I can see behind it with VNC remote desktop. At the same time, kernel 4.10.0-27-generic was released, and I installed it. Recoveries thus far have been reliable. I will keep this post updated periodically.

UPDATE: a day later, both commands to suspend are still completely successful in recovery. 'systemctl suspend' recovers to a login screen, and 'echo mem > sys/power/state' recovers directly to the desktop.

Hope this is helpful...


Return to “Chat about Linux Mint”

Who is online

Users browsing this forum: No registered users and 4 guests