Content:
The Dell Wyse 3040 is an ultra low power, fanless thin PC.
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.
Overview of a Dell Wyse 3040
Check out our video overview of the Dell Wyse 3040.
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.
Comparing a Dell Wyse 3040 with a Raspberry Pi 4
Check out our article comparing the Dell Wyse 3040 with the Raspberry Pi 4.
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.
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.
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.
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.
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.
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 byteThis 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.
UPDATE (March 2024): As per the comment by reader mmarrk, this bug is still present in the latest version of the Ubiquity installer, used by popular distributions such as Ubuntu. We no longer encountered the error as we were using Ubuntu Server for testing, which does not use Ubiquity, hence wrongly assuming the bug was fixed.
mmarrk has also offered an alternative solution, which we have quoted (with minor tweaks for brevity) below.
Install Ubuntu from a Live USB flash drive on to a second USB flash drive, but “Try…” the Ubuntu Desktop flavour first and run…
sudo rm /dev/mmcblk0…to obscure the problematically-named onboard flash device before launching the installer. You can then install to the second USB flash drive without hitting the error.
Once Ubuntu is installed on to the separate USB drive and you boot from it,
udevwill rediscover the onboard 8GB flash storage device and you can then format and use it if you want.
If you’re using a more ‘user-friendly’ Linux distro, such as Ubuntu or Fedora, you shouldn’t encounter any further 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.EFIand the UEFI happily booted without wrecking my other entries. That file simply has to exist. The command you need to run might be slightly different – check the section below to find the correct location to create this file.
Dell clearly wanted to alert users in the strongest possible way if their UEFI fallback wasn’t set. Thanks Dell. :/
I jest of course, as we must remember that these devices were never designed to take anything other than the operating systems Dell supplied them with. We are fortunate that this functionality was included at all.
Finding the Correct EFI System Partition Location
Now, if you’re trying this for yourself, you’ll need to make note of the location your EFI system partition is located to create the file in the right place. An easy way to do this is to run
fdisk -land find a result with the type EFI System.
Device Start End Sectors Size Type
/dev/mmcblk0p1 2048 264191 262144 128M EFI SystemCheck if this is already mounted by running
df -hIf it’s mounted, you’ll find an entry in this list with the filesystem matching the device field from the fdisk output.
/dev/mmcblk0p1 127M 112M 15M 89% /bootMake note of the path at the end of the entry, which specifies the mount point. In this case, mount point is /boot.
If it is not present, create a new folder somewhere on the device. It doesn’t matter where, or what it is called, but we’ll use /esp in this example.
mkdir /espMount the EFI system partition identified using fdisk to this new folder.
mount /dev/mmcblk0p1 /espMake note of /esp, or your chosen path if you used something different.
Now, to actually create the blank file needed. Run the following command, appending the path you noted in place of /x.
touch /x/EFI/BOOT/BOOTX64.EFIYou’ll note in my previous example, I replaced /x with /boot, as I identified /boot as the location the EFI system partition was mounted to.
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.
A 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-gentooJust 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.
UPDATE (March 2024):
It turned out this hunch was correct, and an alternative solution is to ensure the eMMC driver is built in to your kernel. For a while now, we have maintained a working kernel config file for the 3040, which includes the driver required to boot from the internal storage. You can find this on GitHub using the link below.
Wyse 3040 Linux Kernel Config File
Basic Linux kernel config for a Dell Wyse 3040 thin client.
The README included in the GitHub repository gives a more detailed description of what is included in the default configuration, as well as explaining a few settings you might want to change.
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).
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.
Other Wyse 3040 Content
To round out the post, we’ll leave links to a few other articles we have created on the Wyse 3040, as well as our YouTube videos and links to our GitHub projects you might be interested in.
Comparing a Dell Wyse 3040 with a Raspberry Pi 4
Check out our article comparing the Dell Wyse 3040 with the Raspberry Pi 4.
Adding Internal Storage to a Dell Wyse 3040
Check out our article showing how you can add additional internal storage to a Dell Wyse 3040.
Dell Wyse 3040 Vesa Mount 3D Models
3D models of VESA compatible mounts for the Dell Wyse 3040, suitable for 3D printing.
Overview of a Dell Wyse 3040
Check out our video overview of the Dell Wyse 3040.
