It's a small (ish) size, passively-cooled PC that I leave on 24/7 and performs various duties for me, most importantly being a large archive storage space and a separate backup space.
- Coolermaster Elite 110 case
- Gigabyte J1900N-D3V Celeron SoC, passively cooled (Intel ARK)
- 2x 4T WD Red drives (one for archive, one for backup)
- 4G RAM
- custom ATX PSU blanking plate with DC-DC cut-out from Kustom PCs
- Delock MiniPCIe Sata III card (not in active use)
- Simtec Entropy Key
- VGA dummy dongle (see below)
- Blinkstick Nano for notifications (see below)
- SoC: 10W (Intel TDP), some people experiencing draw of about 14W idle with one SSD connected
I plan to do some power draw measurements in the near future.
The Coolermaster case is high-quality (although I am having some problems with the front-most USB ports so there might be a fault there). It's much bigger than I'd like, but is the smallest case I could find at the time. It's about the same size as a HP Microserver (which I was continually recommended when I re-specced this machine) and there's at least growing room. I'd prefer something about the size of the ChenBro ES32067.
The Gigabyte mainboard has some quirks, most of which are listed below. In terms of hardware design, the mini-PCI slot is in a strange place on the board. There is no easy way to secure a mini-PCI card if inserted into the board – the card will protrude at roughly 45° from the plane of the board and if you try to smooth it down it extends beyond the board dimensions so there's no way to secure it with a screw or similar. I've found trying to plug SATA ports into it is enough to loosen the connection.
Sadly, Vs 1-4 of the firmware for the Gigabyte board requires a connected display in order to boot in UEFI mode. This seriously limits the utility of this system, as I want to keep the machine on a bookshelf, away from my desk and any convenient display. It's possible that a newer firmware version fixes this.
I've had a report from someone else with this board that they can boot headless in legacy/CSM mode, with a old-style DOS partition table (not GPT).
In my case, I've constructed a dummy VGA plug that fools the board into thinking that there is an attached monitor. I bought a 15 pin D-SUB gender changer and three 15 Ohm resistors. Connecting the resistors across pins 1-6, 2-7, 3-8 (Red signal to Red ground, etc.) is sufficient.
My go-to external keyboard is an IBM Thinkpad Ultranav USB. It presents itself as a USB hub with a keyboard attached, because it has two USB ports built into it (and two pointing devices too). Sadly with V1 of the Firmware, you can't use this keyboard to operate the firmware. However this was fixed by Version 4.
I've managed this only twice. It's pretty tricky. If you get it to work I'd recommend keeping the USB stick that worked for future updates.
Build a FreeDOS USB stick and put the DOS-based flasher onto it. In the Gigabyte Firmware, ensure
- CSM is enabled
- boot mode dual (legacy, UEFI) or UEFI only
Oddly despite needing a legacy partition layout it's the UEFI boot that needs to run.
For me, the 'fdos' boot option (once the USB bootloader has been launched) did not
work and I needed to use the 'odin' (cut-down freedos) option to proceed, but having
done that I could run the flasher (which was on drive
I don't use RAID (which is not backup).
I use full-disk encryption which necessitates supplying a passphrase when the
machine is booted. Since this is a headless box, some additional work is needed
to permit supplying this passphrase over the network. Luckily most of the work
is done already by installing the
dropbear Debian package and reconfiguring
keys and authorized_keys files in
/etc/initramfs-tools afterwards. This means
I can SSH into the pre-boot environment. From there, I just need to write the
/lib/cryptsetup/passfifo. I will probably write a convenience
script to make that last bit easier.
I wanted to add a means of notifying me of events on the machine. I bought a
Blinkstick Nano, a tiny USB stick with an LED on each
side. I've hooked calls to change the light colour into the success/failure paths
systemd jobs that drive my backups. Further details here:
The light defaults to off. When an interactive job is in progress, it turns on and blue. When the job completes, the light changes to either green or red depending on success or failure. Green means I am safe to remove the drive, in the case of external drives.
When a non-interactive, scheduled job fails, the light turns red. I usually notice this next morning.
The case has some front-mounted USB ports that are blue coloured and described as USB 3. However, the mainboard only offers USB 2.0/1.1 via the header for such ports. I have problems with connecting block devices to these ports.