In March 2024 I decided to assemble an home server to be run 24h, 7/7, the system is intended to replace an old Dell PowerEdge T110, which served my house for the past 14 years without any issue. The main reason for the switch is power consumption and the fear of old hardware wear.

I discovered that a new generation of Mini PCs based on the Intel Alder Lake N95 processor outperform the old Intel Xeon @ 3.0 GHz. The cpubenchmark.net site scores a CPU Mark 5391 versus 1070, respectively. Because sometimes I use the home server to encode large video files (using ffmpeg), I was even more pushed to change the hardware.

My home server is acting also as a domestic firewall (running Debian GNU/Linux), so I opted for a dual LAN Mini-PC. Obviously the only problem is the storage: the embedded SDD disk is not sufficient for my media library, so I opted for an esternal USB Direct Attached Storage. The choice was a D4-300 TerraMaster DAS which will host two 4 Tb 3.5 inches drives (leaving two empty slots).

It seems that Linux kernel 6.1.0 (as shipped with Debian 12 Bookworm) still does not support the WiFi adapter RTL8852BE.

The T9Plus Mini PC has a strip of RGB LEDs all around the case; the default behaviour is to play a circular rainbow effect, rather nice the first time that you see it, but utterly annoing after a couple of hours!

You can program the LEDs with several visual effects, brigthness and speed by sending some specific commands to the USB serial adapter exposed to the operating system. The manufacturer provides a Windows program to configure the LEDs, but several users on the internet reported that the program (named LedControl.exe) is detected as a malware by several antivirus software. I never run MS-Windows on this PC because I booted and installed Debian GNU/Linux since the very first boot, so I cannot give any insight on it.

Fortunately enough, someone made the reverse engineering of the serial protocol required by the LEDs controller and published a working code. Then I wrote a Python program to make the programming: Mini PC T9Plus RGB LED Control Program.

In Debian GNU/Linux 12 it is possibile to run the script at bootstrap; just add a Systemd unit creating the file /etc/systemd/system/t9plus-leds.service with:

# /etc/systemd/system/t9plus-leds.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/t9plus-leds -m Off
[Install]
WantedBy=multi-user.target

Run and enable the service issuing the command:

systemctl daemon-reload
systemctl enable t9plus-leds.service --now

Press Del at bootstrap time to enter the BIOS settings, go to the Boot page and set State After G3 ⇒ S0 State.

The ACPI power states are:

• S0: Normal Powered-On state (system working)
• S1: Standby
• S3: Suspend to Ram
• S4: Suspend to Disk
• S5: Shutdown state (soft off: some devices are still powered-on)
• G3: Mechanical off state

Sometimes (randomly, about 50% of the time) the reboot command does not work. The shutdown process seems to proceed well and the PC seems to begin the reboot process, but the video signal does not switch-on and the host remains frozen. The power LED remains on.

The wake-on-lan (which is working well in normal power-off condition) does not reboot the PC when it freezes in that way.

It seems that the reboot problem is tied to the USB attached storage. If I remove the TerraMaster DAS and allow the Mini PC to boot with just the GNU/Linux operating system from the SSD, the reboot seems 100% reliable.

May be I found a workaround for the problem: in the BIOS settings I set the Boot ⇒ Fast Boot to Enabled, then I leaved the SATA Support to All SATA Devices but set the USB Support to Disable (just for safety I disabled all the boot devices, except SATA). Till now I tried several reboots, without any issue!

The problem with this workaround is that you cannot longer enter into the BIOS setup program, because the USB keyboard is not initialized at boot and you cannot press the Delete key.

If the system starts normally, it is simple to enter the BIOS setup from a Linux command propt; just issue the command:

systemctl reboot --firmware-setup

It seems that - by chance - I was able to entered the BIOS setup even when Fast Boot was enabled; it was a mix of keeping the Delete key pressed on the keyboard while long-pressing the power button for about 4 seconds, or by repeatedly pushing the power button 4 or 5 times. But I was not able to replicate this behaviour in a consistend manner.

Outpt of the lsusb command:

Bus 002 Device 004: ID 174c:55aa ASMedia Technology Inc.
  ASM1051E SATA 6Gb/s bridge,
  ASM1053E SATA 6Gb/s bridge,
  ASM1153 SATA 3Gb/s bridge,
  ASM1153E SATA 6Gb/s bridge
Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc.
  ASM1051E SATA 6Gb/s bridge,
  ASM1053E SATA 6Gb/s bridge,
  ASM1153 SATA 3Gb/s bridge,
  ASM1153E SATA 6Gb/s bridge
...

Outpt of the lsusb -t command:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
        |__ Port 4: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M
...

It turned out that the USB bus is not reliable enough, maybe due power issues. Simply inserting a USB storage key caused read errors on the USB attached storage and a consequent kernel panic.

I installed two hard disks on the Terramaster DAS:

• Western Digital 3.5” 4Tb WD Red NAS 256 Mb, 5400 rpm, SATA 6Gb/s - WDC WD40EFZX-68AWUN0
• Seagate IronWolf 3.5“ 4Tb 64 Mb cache, 5900 rpm, SATA 6Gb/s - ST4000VN008-2DR166

I made some tests on read performances on the USB attached device using hdparm. Here are the average results, which are similar on both my RAID disks (a bare 1% more performance on the Western Digital):

hdparm -t /dev/sdb
/dev/sdb:
 Timing buffered disk reads: 572 MB in  3.00 seconds = 190.47 MB/sec

Unfortunately the check_ide_smart Nagios plugin provided by the Debian 12 package monitoring-plugins-basic 2.3.3-5+deb12u2, is unable to scan the SMART attributes of the SATA drives through the Terramaster Direct Attached Storage. As reported into the Nagios-plugins issue #16, the check_ide_smart plugin should be phased out in favor of check_scsi_smart.

We compiled the plugin binary from the sources (using the master branch 064a9fd) and now we can check the SMART attributes of each disk into the DAS:

check_scsi_smart -d /dev/sdb
OK: prdfail 0, advisory 0, critical 0, warning 0, logs 0 | 1_read_error_rate=0;;;; 3_spin_up_time=3883;;;; 4_start_stop_count=26;;;; 5_reallocated_sectors_count=0;;;; 7_seek_error_rate=0;;;; 9_power_on_hours=19301;;;; 10_spin_retry_count=0;;;; 11_recalibration_retries=0;;;; 12_power_cycle_count=17;;;; 192_power_off_retract_count=5;;;; 193_load_cycle_count=49;;;; 194_temperature=32;;;; 196_reallocation_event_count=0;;;; 197_current_pending_sector_count=0;;;; 198_uncorrectable_sector_count=0;;;; 199_ultradma_crc_error_count=0;;;; 200_multi_zone_error_rate=0;;;;

To integrate the SMART checks for all the devices into a single Nagios check and to have a more terse output, we created the following script check_scsi_smart_all:

#!/bin/sh
if [ "$#" -lt "1" ]; then
    echo "Usage: $(basename $0) sda [sdb ...]"
    exit 1
fi
OUTPUT=''
STATE=0
for DEV in $@; do
    OUT="$(/usr/local/sbin/check_scsi_smart -d /dev/$DEV)"
    RET=$?
    if [ $RET -gt $STATE ]; then
        STATE=$RET
    fi
    if [ "$RET" -eq "0" ]; then
        # Get only the short status, e.g. "OK".
        OUT="$(echo "$OUT" | cut -f1 -d':')"
    else
        # Get the summary, e.g. "OK: prdfail 0, advisory 0, critical 0, warning 0, logs 1 "
        OUT="$(echo "$OUT" | cut -f1 -d'|' | sed 's/[[:space:]]\+$//')"
    fi
    test -n "$OUTPUT" && OUTPUT="${OUTPUT}; "
    OUTPUT="${OUTPUT}${DEV}: ${OUT}"
done
 
OUTPUT="check_ide_smart[${OUTPUT}]"
case $STATE in
    0)
        OUTPUT="OK: $OUTPUT"
        ;;
    1)
        OUTPUT="WARNING: $OUTPUT"
        ;;
    2)
        OUTPUT="CRITICAL: $OUTPUT"
        ;;
    *)
        OUTPUT="UNKNOWN: $OUTPUT"
        ;;
esac
echo "$OUTPUT"
exit $STATE

Finally we defined the NRPE Nagios check with a line into /etc/nagios/nrpe_local.cfg:

command[check_scsi_smart]=/usr/bin/sudo /usr/local/sbin/check_scsi_smart_all sda sdb sdc

During bootstrap several error messages appears on the console (and are logged in syslog):

ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.TXHC.RHUB.SS01], AE_NOT_FOUND (20220331/dswload2-162)
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.UBTC.RUCC], AE_NOT_FOUND (20220331/psargs-330)
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.LPCB.ITE8.GETT], AE_NOT_FOUND (20220331/psargs-330)
...

This is caused by the BIOS missing the “Advanced Error Reporting” mechanism. It is possibile to ignore it by adding pci=noaer to the Linux command line in /etc/default/grub:

GRUB_CMDLINE_LINUX="pci=noaer fsck.repair=yes consoleblank=0 reboot=cold,force"

Do an update-grub and reboot.

• How can I check whether USB3.0 UASP (USB Attached SCSI Protocol) mode is enabled in Linux?
• systemd: How do I automount a USB filesystem using /etc/fstab?
• Mini PC T9Plus RGB LED Control Program
• T9 Plus N100 - How to control LED
• LED Controller
• Mini PC RGB AK1 Plus - Controllo RGB
• How can I fix these ACPI errors?