Install a New Linux OS On a Dell Wyse 3040


February 7, 2022

Dell linux Wyse



The Dell Wyse 3040 is an ultra low power, fanless thin PC.

The Wyse 3040, in all of its pocket-sized glory.

Sporting an Intel Atom x5-8350 CPU, 2/4GB of RAM, and 8/16GB of storage, this thin PC is never going to win any performance awards. But what it lacks in raw performance, it makes up for in size. Barely larger than a Raspberry Pi, the 3040 features 2 DisplayPort outputs, gigabit ethernet, 4x USB ports (2x front, 2x rear, one of which is USB 3), and an internal hardware clock. For an overview of the 3040, you might want to check out our video.

Bottom of the Wyse – you can see this particular device is the 5V version.

This one can be powered using 5V – a USB to 4 x 1.7mm centre positive barrel jack cable allows it to be powered using a USB charger. While the device is rated at 3A, in practice, even under full load it remains at around 1.5A. There is a second variant that takes 12V – be sure to check the bottom of your device before plugging it in.

A major difference between this and other similarly sized devices is the CPU architecture. Like other Intel CPUs, this Cherry View Atom is x86-64 based, meaning it can theoretically run any software that will run on a fully-fledged PC, with decent driver support to boot. Boards such as the Raspberry Pi are ARM based, which has more limited software support.

If you’re interested in a more detailed comparison with a Raspberry Pi 4, check out our comparison article here.

Out of the factory, the only operating systems available were ThinOS and ThinLinux, both very basic and providing only what is required to use the device as a thin client.

It is possible, however, to install a fully fledged Linux OS on these machines. Let’s take a look at how it’s done. You might also want to take a look at our guide on adding extra internal storage to your 3040.

Configuring the BIOS

The first step is to boot the device into the BIOS. To do this, press the F2 key once you’ve powered the device on.

System information displayed in the BIOS. This machine is the 2GB RAM/8GB storage version.

The tree structure on the left-hand side houses all of the available menus.

Unlocking the BIOS

Before we can change any settings, the BIOS needs to be unlocked. Click on the ‘Unlock’ button at the bottom of the screen. If your BIOS does not have a password lock, you can skip to the next section.

If you’re unsure, check the buttons along the bottom right of the screen – if you see an ‘Unlock’ button, with a padlock above it, your BIOS is password protected.

password entry
Password unlock screen.

In the box that pops up, type the system password. By default, the password is Fireport.

Once the system is unlocked, we can remove the password completely, so we will not have to unlock the device in future. Note that this is optional; if you’d rather keep the current password, this step can be skipped.

The option to change this can be found under Security >> Admin Password.

password change
Setting a new admin password.

Enter the current password in the top box, and leave the other two blank. Click ‘OK’ to save, and the password will now be removed.

Alternatively, you can enter an alternative password in the lower two boxes, to set a new password. If you do this, you’ll still need to unlock the BIOS each time if you want to change any settings.

Enabling USB Boot

To install a new OS, we’ll need to make sure USB boot is enabled.

The setting for this can be found under System Configuration >> USB Configuration.

usb boot support
Check the ‘Enable USB Boot Support’ box.

With the box for USB support checked, we will now be able to boot from a USB device.

The USB device used must support UEFI – if you need to set this up, I recommend taking a look at Ventoy. Once the USB is configured with Ventoy, adding bootable OS’s is as simple as copying the ISO file to the drive.

Installing an OS

Once booted from an external drive, the device is (for the most part) just like any other. Whichever Linux distro you’ve chosen, you should follow the installation instructions for that distro.

Just bear in mind, the 3040 doesn’t use a typical storage device – while a typical PC will use /dev/nvme* (PCIe) or /dev/sd* (SATA) mount points, as this device uses eMMC, the storage mount point is /dev/mmcblk0.

One issue you could encounter is a crash during the install process. This will usually occur early on in the process, for example, after selecting ‘Install’ on a LiveCD. It can also occur when doing anything drive/partition related through the live session. If you manage to extract the error log, you might see a message similar to the one below.

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x92 in position 83: invalid start byte

This is a known issue, caused by the hardware device name used by the Wyse for the eMMC. The name ‘MMC H8G4a\x92’ contains a non-unicode character, which causes issues for software trying to read the device name, and prevents installation from progressing.

If you encounter this issue, make sure you’re using the most up to date version of your chosen distro, as this bug has since been fixed. If this is not possible, check out the potential fix given in this GitHub bug report.

If you’re using a more ‘user-friendly’ Linux distro, such as Ubuntu or Fedora, you shouldn’t encounter any issues. However, if you’ve opted for Debian or a more exotic distro such as Arch or Gentoo, you’ll want to consider the point(s) below when configuring your system.

UEFI Shenanigans

Despite the BIOS allowing custom UEFI boot locations, it turns out that the 3040 requires the UEFI fallback location (\EFI\BOOT\BOOTX64.EFI) to be populated.

In testing, distros such as Ubuntu handle the system well, and boot without any additional setup – presumably, this is down to the use of the GRUB bootloader. Arch, Gentoo and (surprisingly) Debian on the other hand, do not. In the case of Debian, this is down to a design choice – they intentionally opt not to cater for broken UEFI implementations like the one in the 3040.

If this file doesn’t exist, the system will not only fail to boot, but all boot entry paths are set to the fallback location – the one it’s realised doesn’t exist. Odd behaviour to say the least.

Unfortunately, this took me while to notice – only to find, this issue has already been documented. If you’re using GRUB, the command mentioned over there works fine – the ‘–removable’ part of the command forces GRUB to use the fallback location, rather than its default.

In practice, this means you must have a file at \EFI\BOOT\BOOTX64.EFI. It doesn’t matter what the file is – I tried creating an empty file using

touch /boot/EFI/BOOT/BOOTX64.EFI

and the UEFI happily booted without wrecking my other entries. (Note in this case, my EFI system partition is mounted on /boot). That file simply has to exist.

Dell clearly wanted to alert users in the strongest possible way if their UEFI fallback wasn’t set. Thanks Dell. :/

In my case, I chose to leave an old kernel in the fallback location, and use \EFI\gentoo\gentoo.efi for new kernels. Because having a fallback is good. That’s definitely why. It’s absolutely not because I’m stubborn and want to use my own EFI path thank you very much Dell.

File System Sheninigans

Having faffed around with the UEFI for a while, I encountered repeated issues getting the system to boot Gentoo, my OS of choice. I did also have the same problem with Arch, but did no further testing as it wasn’t the OS I intended to keep.

Now I’m certainly no expert when it comes to compiling kernels, but I have set up several machines using a mixture of EFI stub and GRUB, with a variety of hardware. So at the very least, I know how to stumble my way around the important bits.

Despite being fairly confident in my kernel configuration, I consistently came across the same kernel panic:

Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The message is pretty clear – the kernel can’t load the root file system. Without which, there is no system. Excellent. Sometimes you’ll see hints alongside this message, a driver name that failed to load, a root path suggestion. But I got nothing.

The fix for this turned out to be something I’d never had to set up before – an initramfs. An initramfs, or initial ramdisk, is loaded straight after the kernel, but before the kernel mounts the system root. It contains additional drivers, microcode updates etc – things that are needed to boot the system, but would be otherwise inaccessible until after the device has booted.

It turns out it’s actually rather simple. I used dracut to create it.

dracut --kver=5.16.8-gentoo

Just replace with your kernel version, and you’re away. Just don’t forget to update your booting method to include the new file.

My hunch is that the eMMC driver is not available early enough to mount the root filesystem. Though it could be another driver, a kernel config error, or some other form of user error on my part.

Benchmarks & Conclusion

Below are a few benchmarks of the Wyse, compared to a Lenovo Thinkcentre M93p (i5 4570T), and a fanless IGEL M430C (AMD GX412).

Benchmark results, scaled.

The results are scaled relative to the i5 machine, which is given a score of 100 for each test.

Unsurprisingly, the i5 wins all but one benchmark. The Wyse holds its own against the similarly fanless GX412, but with a much smaller footprint and lower power consumption.

While the Wyse 3040 won’t win any performance awards, it can make a decent silent home server. If you can pick one up cheaply, it would make a good Raspberry Pi alternative for basic computing tasks.

If you like what we do, consider supporting us on Ko-fi