Tech —

Linux on the NUC: Using Ubuntu, Mint, Fedora, and the SteamOS beta

Intel's mini desktop handles four prominent distros with a few headaches.

Intel's NUC: not just for Windows.
Intel's NUC: not just for Windows.
Andrew Cunningham / Aurich Lawson
Specs at a glance: Intel NUC D54250WYK1 (as reviewed)
OS Ubuntu 13.10, Linux Mint 16, Fedora 20, and SteamOS Beta
CPU 1.3GHz Core i5-4250U (Turbo Boost up to 2.6GHz)
RAM 8GB 1600MHz DDR3 (supports up to 16GB)
GPU Intel HD Graphics 5000 (integrated)
HDD 128GB Crucial M500 mSATA SSD
Networking 802.11ac Wi-Fi, Bluetooth 4.0, Gigabit Ethernet
Ports 4x USB 3.0, 1x mini DisplayPort 1.2, 1x mini HDMI 1.4a, DisplayPort, audio
Size 4.6” x 4.4” x 1.4” (116.8 x 111.8 x 35.6 mm)
Other perks Kensington lock
Warranty 3 years
Price $389.99 (barebones), $602.99 with selected components and software

One of the drawbacks of buying a barebones PC like Intel’s NUC—at least if you’re a Windows user—is that it comes with no operating system. The big PC OEMs get Windows at a steep discount compared to end users, and you’ll have to pay somewhere in the neighborhood of $100 for a full OEM Windows license (and more if you want a retail version with tech support).

The other side of that coin is that barebones PCs can be good for people who aren’t planning on paying for an OS. You can use your favorite Linux distribution on a barebones PC without paying the added cost for some Windows license you have no intention of using.

As a follow-up to our original review, we’ve installed four different Linux distributions to the Haswell NUC to get an idea of what open source enthusiasts can expect to experience when they load up Linux on the hardware. We tried Ubuntu 13.10, Linux Mint 16, and Fedora 20 because of their popularity, and then we loaded up SteamOS to test out its recently acquired Intel graphics support.

Installation

UNetbootin is probably the easiest way to make USB install drives for major Linux distributions.
UNetbootin is probably the easiest way to make USB install drives for major Linux distributions.
Andrew Cunningham

UNetbootin is still an easy way to load most Linux distributions onto a USB drive. For both Ubuntu and Mint, all you need to do is download the ISO you want, point the program at the ISO and your USB drive of choice, and UNetbootin will do the rest. For whatever reason, UNetbootin wouldn't create a functioning live USB key for Fedora—it would boot but fail over to Emergency Mode without trying to install anything. Creating USB install media with Fedora's own utility remedied the problem.

Many Windows computers include features like Fastboot or Secure Boot that need to be disabled or circumvented to use Linux in UEFI mode, and while the NUC supports these features for Windows, they aren’t enabled by default. Installing Linux on the NUC should have been the easiest part of the whole process, but for most of our distributions it ended up being a gigantic pain, and that comes down to the NUC's EFI implementation.

The NUC supports features like Secure Boot, but it keeps them disabled by default. The real problem is the NUC's EFI implementation.
Enlarge / The NUC supports features like Secure Boot, but it keeps them disabled by default. The real problem is the NUC's EFI implementation.
Andrew Cunningham

Each time we would install one of our Debian-based distros (Ubuntu, Mint, or SteamOS), the NUC would boot to the USB drive and install the operating system to the internal mSATA SSD without issue. The problem was that the NUC wouldn't see the drive as a EFI boot target, and it would refuse to boot from the drive. The first helpful suggestion I found about the issue came from Tested.com's Will Smith on the Steam community forums. He suggested that the NUC had problems with custom EFI boot locations—the NUC expects there to be a file named bootx64.efi located in the /EFI/BOOT folder on the EFI partition, and if that file is named something else and/or located elsewhere, the computer can't recognize the drive as a boot target. The Debian distros will usually try to place a bootloader named grubx64.efi in a folder named /EFI/[distro name], so the NUC wouldn't try to boot from the drive.

There are a couple of ways you can try to fix this. The first is to use Ubuntu's boot-repair tool, though it can occasionally be overzealous and inconsistent in its fixes. The second is to move and rename the files manually. While that is a little more difficult, it has the benefit of being consistent. From our Ubuntu live USB drive, finish the operating system installation but don't reboot. Instead, open a terminal window and type the following:

$ sudo mount /dev/sda1 /mnt
$ sudo mkdir /mnt/EFI/BOOT
$ sudo cp /mnt/EFI/ubuntu/* /mnt/EFI/BOOT
$ sudo mv /mnt/EFI/BOOT/grubx64.efi /mnt/EFI/BOOT/bootx64.efi

These instructions apply to Ubuntu specifically, but they worked the same way for SteamOS and Mint, and they should get the job done for any other Debian distribution that behaves the same way. Just check which folder the operating system stores its bootloader files in—it's /mnt/EFI/ubuntu for Ubuntu, /mnt/EFI/steamos for Steam OS, and so on. We've passed all of our findings on to Intel's NUC team, and while we haven't received a response as of publication, we hope that this problem can be fixed with a BIOS update. Update: Intel tells us that the NUC team will be addressing the bootloader issue in an upcoming BIOS release. There's no word on exactly when we can expect a fix, but one is apparently coming.

Once UEFI was working properly and the operating systems were actually booting, Ubuntu, Mint, and Fedora didn't give us any more trouble with installation. While installing SteamOS, the default image-based installer didn’t seem to want to see the internal mSATA hard drive for some reason—it would attempt to image the hard drive via CloneZilla, but it consistently errored out. It worked fine using the custom Debian-based installer, aside from the EFI problems.

Power consumption

One of the draws of the NUC, aside from its small physical footprint, is its small power footprint. In Windows, it idles at around 6W, displays YouTube videos in Chrome with about 9W, and won’t consume more than 38W even when gaming at full-tilt. Not all of the tests we ran in our original review will run under Linux, but we’ve gotten a few more numbers for our Linux distros to get an idea of how they all stack up.

Activity Ubuntu 13.10 Linux Mint 16 Fedora 20 SteamOS Beta (1/31/2014) Windows 8.1 x64
Idle at desktop 6.6W 6.6W 6.6W 8.2W (Gnome)/27.3W (SteamOS UI) 6.4W
Sleep mode 2.4W 2.4W 2.4W N/A 1.1W
Watching YouTube in Chrome/Chromium 9.6W 7.9W 9.8W N/A 9.0W
Running Portal at 1080p (title screen) 27.5W 27.7W 27.7W 27.5W 27.5W

Generally, the NUC’s power consumption figures under Linux are pretty near where they are in Windows, though Windows seems to be a little less power-hungry in sleep mode. The standard desktop Linux distributions are all pretty similar no matter what you're doing, which isn't surprising—there's a fair degree of commonality in drivers across the biggest distributions, after all.

Of the four Linux distros, SteamOS is the most interesting. For one, getting the NUC to sleep was impossible—it would go to sleep for just a couple of seconds before waking back up even if no input devices were plugged in, foreshadowing some of the other problems we’ll talk about soon. What’s more striking is just how active the SteamOS UI keeps the CPU and GPU. Sitting still on the SteamOS menus consumes almost as much power as actually playing a game. These figures might differ on a more powerful machine with a stronger GPU (it doesn’t take a whole lot to max out the HD 5000), but in any case, it’s much higher than in a less demanding desktop OS.

Channel Ars Technica