Un NAS bastato su architettura Intel N100 con una dotazione di RAM sufficiente e abbastanza spazio su SSD eMMC per installare un sistema operativo completo, ad esempio Debian 13 Trixie. La dotazione di una porta HDMI lo rende capace di essere anche un media center completo.

Caratteristiche tecniche

Accesso al BIOS e Boot Menu

Collega un monitor alla porta HDMI e una tastiera a una porta USB, accendi il dispositivo e premi la combinazione di tasti quando vedi il logo UGREEN:

Per impostazione di fabbrica, c'è un watchdog abilitato (tempo predefinito 180 secondi) che riavvia il dispositivo se il sistema operativo non provvede periodicamente ad azzerare il contatore. È necessario disabilitare il watchdog se si desidera installare un sistema operativo diverso. Anche durante la configurazione del BIOS il watchdog è attivo e bisogna essere rapidi a salvare le impostazioni.

Queste sono le impostazioni del BIOS più interessanti:

• BIOS
  • Advanced
    • WatchDog Setting
      • Watch Dog Control [Disabled]
    • Power Settings
      • Power Loss
      • Wake on LAN
      • RTC Wakeup from S5
    • Hardware Monitor
      • Smart Fan Function

Alcune persone in rete affermano che è necessario premere Ctrl+F1 nel BIOS per abilitare il menu Advanced; nel mio caso quella pagina è abilitata di default.

Nei menu del BIOS si trovano le impostazioni per il Power Loss (con le tre opzioni classiche: Power Off, Power On e Last State), il Wake on LAN e il RTC Wakeup (avvio all'ora impostata). Purtroppo quest'ultimo è configurabile solo con ora, minuti e secondi, non è possibile scegliere il giorno della settimana o del mese.

Il sistema operativo UGOS (UGREEN O.S.) è basato su Debian 12 Bookworm, collegando un monitor HDMI e una testiera USB è possibile vedere il boot loader GRUB e assistere al boot del sistema operativo GNU/Linux. Al termine del boot sul display HDMI viene visualizzata la grafica di un player multimediale che invita a scaricare l'app di controllo (in cinese, vedi più avanti):

Premendo Alt-F1 è possibile accedere al terminale VT1 ed effettuare login come utente root con password ugreen. Al termine della configurazione iniziale eseguibile da pagina web, la password dell'utente root viene disabilitata e l'utente amministratore creato ha la possibilità di diventare root con sudo.

Collegando il NAS alla rete locale questo acquisisce un indirizzo IP dal server DHCP. Puntando il browser HTTP sull'indirizzo IP si trova una procedura di configurazione iniziale. Vengono chieste le seguenti informazioni:

1. Nome del device.
2. Creazione di un account di amministrazione (scelta di login e password).
3. Registrazione di un numero di telefono per accesso remoto tramite app e per ricevere SMS (prefisso bloccato su +86, forse perché al device non era stato dato accesso a internet).
4. Impostazioni degli aggiornament: solo importanti, tutti, solo notifica.
5. Tentativo di upgrade via internet.

Al termine della procedura di inizializzazione l'accesso HTTP fornisce una interfaccia grafica web desktop.

Il servizio ssh è disabilitato; può essere abilitato dalla riga di comando con systemctl enable --now ssh, ma al reboot successivo sarà di nuovo disabilitato. Eventualmente va abilitato da Control Panel ⇒ Terminal.

Il disco SSD /dev/mmcblk0 da 32 Gb contiene la partizione p2 da 2G che contiene il root filesystem in formato squashfs montato read-only, sul quale viene montato in overlay la partizione p7 da 18.9 Gb formattata ext4. La procedura di reset indicata nel manuale e attivabile con il microswitch relativo probabilmente elimina il contenuto della partizione overlay restituendo il contenuto originale del filesystem squashfs.

È possibile installare pacchetti Debian aggiuntivi con i normali comandi apt update, apt install, ecc.

Sulla porta HDMI si trova l'interfaccia grafica in cinese di un player multimediale. Dopo aver effettuato la configurazione iniziale l'interfaccia viene nazionalizzata in inglese:

La pagina in cinese ha titolo Riproduzione diretta HDMI, la traduzione del menu più o meno è come segue:

1. Apri l'app Greenlink Cloud
2. Seleziona il video da riprodurre
3. Fai click sull'angolo in alto a destra
4. Seleziona la riproduzione HDMI

Le note dicono:

1. Supporta la riproduzione diretta dei codec più diffusi, come H.264 e H.265
2. Se durante la riproduzione non si sente l'audio o esso non è sincronizzato, provare a cambiare traccia audio.
3. Questa è una versione beta. Se riscontri problemi prova a fare nuovamente play o invia una richiesta di supporto tecnico.

Prima di effettuare la configurazione iniziale del device da interfaccia web, è possibile accedere ad un terminale come utente root. Avendo collegato monitor e tastiera, dalla schermata grafica del video player è possibile digitare Ctrl+Alt+F1 per accedere al terminale VT1 ed effettuare login come root con password ugreen.

Il sistema operativo è basato su Debian 12 Bookworm, se si collega la porta Ethernet ad una LAN con server DHCP l'interfaccia verrà configurata automaticamente. Per abilitare l'accesso via SSH da remoto è sufficiente aggiungere l'opzione PermitRootLogin yes ad un file /etc/ssh/sshd_config.d/00-local.conf e riavviare il servizio con systemctl restart ssh.

Una volta completata la configurazione iniziale del NAS, il servizio SSH viene avviato solo se è stato abilitato nel sistema operativo web, da Control Panel ⇒ Terminal.

Ecco alcuni output per capire come si presenta il sistema:

mount | grep mmcb

/dev/mmcblk0p2 on /rom type squashfs (ro,relatime,errors=continue)
/dev/mmcblk0p6 on /ugreen type ext4 (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/mmcblk0p7 on /overlay type ext4 (rw,relatime)
/dev/mmcblk0p3 on /mnt/factory type ext4 (rw,relatime)

df -h | grep mmcblk | sort

/dev/mmcblk0p1  256M   66M  190M  26% /boot
/dev/mmcblk0p2  930M  930M     0 100% /rom
/dev/mmcblk0p3  8.6M   31K  7.8M   1% /mnt/factory
/dev/mmcblk0p6  3.9G  2.4G  1.4G  64% /ugreen
/dev/mmcblk0p7   19G  180M   18G   2% /overlay

Questo l'output di parted sul device /dev/mmcblk0:

Model: MMC MMC32G (sd/mmc)
Disk /dev/mmcblk0: 61194240s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start      End        Size       File system     Name  Flags
128     34s        511s       478s                             bios_grub
 1      512s       524799s    524288s    fat16                 legacy_boot
 2      524800s    4719103s   4194304s
 3      4720640s   4741119s   20480s     ext4
 4      4741120s   8935423s   4194304s   ext4
 5      8935424s   13129727s  4194304s   linux-swap(v1)
 6      13129728s  21518335s  8388608s   ext4
 7      21518336s  61194206s  39675871s  ext4

Il comando free riporta:

               total        used        free      shared  buff/cache   available
Mem:         7870148     1036568     3841088       58448     3485060     6833580
Swap:        6029292           0     6029292

I 6 Gb di swap sono in effetti costituiti da 2 Gb della partizione p5 della memoria eMMC più 4 blocchi da 1 Gb ciascuno di zram (compressed RAM block device) /dev/zram{0|1|2|3}. Usare la zram come swap consente una ottimizzazione della RAM disponibile e consente di ricorrere con minor frequenza al disco eMMC aumentandone la vita utile.

Seguendo le istruzioni di Installing Debian On Ugreen l'installazione di Debian GNU/Linux 13 Trixie sul NAS DXP2800 è stata fatta con una normale chiavetta USB Debian netinst. Dopo aver disabilitato il watchdog nel BIOS, si è fatto accesso al boot menu con Ctrl+F12 e selezionato l'avvio da chiavetta USB. L'avvio avviene in modalità UEFI e si procederà con una installazione UEFI.

Si consiglia di utilizzare una porta USB 2 per fare il boot da chiavetta, alcuni utenti riportano che l'installer non riesce a gestire le porte USB 3.

Si è scelta l'opzione di partizionare il disco in modo manuale e si sono rimosse tutte le partizioni ad eccezione delle due partizioni esistenti relative al boot loader, cioè la #1 (con il flag legacy_boot) e la #128 (con il flag bios_grub). Non è chiaro come avviene il boot con il boot loader e sistema operativo originali, infatti il sistema parte in modalità EFI, ma la partizione #1 che contiene i relativi file non ha i flag boot e esp propri di una partizione EFI. Inoltre durante l'installazione tale partizione non viene riconosciuta automaticamente come destinataria dell'installazione del boot loader, è necessario forzare manualmente l'uso della partizione #1 come partizione EFI.

Abbiamo optato per creare una singola partizione per il root filesystem e una per lo swap, questo lo schema risultante al termine dell'installazione:

Number  Start   End     Size    File system     Name  Flags
128     0.00GB  0.00GB  0.00GB                        bios_grub
 1      0.00GB  0.27GB  0.27GB  fat16                 boot, legacy_boot, esp
 2      0.27GB  27.3GB  27.0GB  ext4
 3      27.3GB  31.3GB  4.06GB  linux-swap(v1)        swap

La partizione con il flag bios_grub è in effetti inutilizzata e il flag legacy_boot sulla partizione #1 non è coerente e può essere tolto.

Vogliamo attivare il monitoraggio della funzione SMART degli hard disk e vogliamo anche abilitare lo spin-down degli stessi se non vi è attività di lettura o scrittura. Infatti si prevede di tenere il NAS accesso h24, ma l'attività del disco sarà necessaria solo durante alcune funzioni di backup programmate.

Avendo installato il pacchetto smartmontools è possibile conoscere lo stato del disco con il comando:

smartctl -a /dev/sda

Inoltre il demone smartd è attivo per effettuare il monitoraggio continuativo. Per configurare l'attività di monitoraggio si modifica opportunamente il file /etc/smartd.conf:

# Disable DEVICESCAN, which does not work in our environment.
#DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

# Use the suggedested subset of checks, instead of the '-a'.
# NOTICE: We are running smartd with option --interval=3600 instead of the
# 1800 default, i.e. device polling occurs every 1 our instead of 30 minutes.
# The number of skipped checks (option -n) must be multipled by that value
# to obtain the maximum time that checks will be skipped:
# 1 hour interval * 168 times = 7 days.
/dev/sda \
    -H \                # Check the health with the SMART RETURN STATUS command
    -l selftest \       # Report increasing number of failed Self-Test
    -l error \          # Report increasing errors number in the Summary SMART error log
    -f \                # Check for 'failure' of any Usage Attributes
    -n standby,168 \    # Skip smartd checks during standby (max 168 times, add ',q' for quiet)
    -W 0,50,60 \        # Temperature (SMART att. 194): WARN=50 (log), CRIT=60 (mail)
       \                # Schedule a short Self-Test at 23:00 of every monday.
       \                # Schedule an Offline Immediate Test every day at 21:00.
    -s (S/../../1/23|O/../.././21) \
    -m root@localhost \ # Send a warning email on failures and errors
    -M daily \          # Repeat email warnings daily
    -M test             # Send an email test on daemon start

Ovviamente se i dischi sono due la configurazione va ripetuta anche per /dev/sdb. Per verificare il log dei selftest eseguiti:

smartctl -d sat -l selftest /dev/sda

Per configurare lo stand-by timeout (spin-down) del disco si installa il pacchetto hdparm. Non useremo la funzione Advanced Power Management (APM) perché non è supportata da tutti i modelli di hard disk e con essa non è possibile impostare con precisione il timeout dello spin-down. Per verificare se il disco supporta APM:

hdparm -B /dev/sd[ab]

nel nostro caso sda non supporta APM mentre sdb sì:

/dev/sda:
 APM_level      = not supported
/dev/sdb:
 APM_level      = 254

Utilizzeremo piuttosto l'opzione hdparm -S da riga di comando:

hdparm -S 241 /dev/sda
hdparm -S 241 /dev/sdb

dove il valore di timeout se è compreso fra 1 e 240 rappresenta unità da 5 secondi (quindi da 5 a 1200 secondi), se è compreso fra 241 e 251 rappresenta da 1 fino a 11 unità di 30 minuti ciascuna (quindi da 30 a 330 minuti). Per impostare il timeout ad ogni reboot si configura il file /etc/hdparm.conf:

# Enable hard disk standby (spin-down) timeout at 30 minutes.
# It is advisable to disable write cache in this case.
# See man hdparm(8), -S and -W options.
# A value of the spindown_time between 1 and 240 represents units of 5 seconds,
# a value between 241 and 251 represents 1 to 11 units of 30 minutes.
/dev/sda {
        write_cache = off
        spindown_time = 241
}
/dev/sdb {
        write_cache = off
        spindown_time = 241
}

Il sistema è dotato di due ventole, una sulla CPU e una sul retro del case. Nel BIOS è possibile impostare il funzionamento delle ventole con notevole dettaglio:

Da software è possibile leggere la temperatura di 6 sensori: si tratta dei 4 core della CPU più un sensore per la System temperature e uno per la CPU temperature.

• /sys/devices/virtual/thermal/thermal_zone0/temp
• /sys/devices/virtual/thermal/thermal_zone1/temp

Il BIOS riporta la velocità di rotazione solo della ventola di sistema. È possibile leggere la velocità dal sistema operativo?

L'UGREEN DXP2800 dispone di 4 LED multicolore che è possibile controllare via software, ma è necessario compilare e caricare un modulo kernel ad-hoc che non si trova nei pacchetti ufficiali Debian.

Fortunatamente su GitHub si trova il repository ugreen_leds_controller che fornisce i sorgenti per il modulo kernel e per alcuni tool di controllo. Il repository contiene anche la release di due pacchetti Debian compilati

Il pacchetto led-ugreen-dkms fornisce il modulo kernel utilizzando il framework dkms (Dynamic Kernel Module Support), cioè il pacchetto contiene i sorgenti del modulo e quando lo si installa esso provvede a compilare il modulo binario utilizzando le dipendenze necessarie (strumenti di sviluppo e header del kernel). Questo garantisce che quando si installerà una nuova versione del kernel, il modulo sarà ricompilato e installato automaticamente.

Il pacchetto led-ugreen-utils contiene invece script ed eseguibii di supporto, nonché le unit Systemd per attivare il funzionamento dei LED nella loro normale funzione di monitoraggio attività e/o guasti.

I pacchetti Debian da installare per soddisfare le dipendenze sono:

• dkms
• linux-headers-6.12.57+deb13-amd64
• i2c-tools

I pacchetti extra da installare possono essere scaricati da GitHub. Noi abbiamo usato la versione 0.3:

• led-ugreen-utils_0.3_amd64.deb
• led-ugreen-dkms_0.3_amd64.deb
• ugreen_leds_controller_v0.3.tar.gz (sorgenti)

Il pacchetto led-ugreen-utils contiene l'utility da riga di comando ugreen_leds_cli per interrogare e impostare lo stato dei LED accedendo direttamente al bus I2C. Essa non ha bisogno del modulo kernel aggiuntivo, anzi è incompatibile con esso. Per utilizzarla bisogna essere certi di caricare il modulo I2C e rimuovere il modulo LED UGREEN:

modprobe i2c-dev
modprobe -r led-ugreen

Ecco alcuni esempi di utilizzo:

ugreen_leds_cli all -status
disk1: status = off, brightness = 128, color = RGB(255, 255, 255)
disk2: status = off, brightness = 128, color = RGB(255, 255, 255)
disk3: status = off, brightness = 128, color = RGB(255, 255, 255)
disk4: status = off, brightness = 128, color = RGB(255, 255, 255)
netdev: status = off, brightness = 128, color = RGB(255, 255, 255)
power: status = off, brightness = 128, color = RGB(255, 255, 255)

ugreen_leds_cli netdev -breath 600 400 -color 255 0 0 -brightness 255

In condizioni normali non si userà il comando ugreen_leds_cli, ma si vorrà usare il modulo kernel fornito dal pacchetto led-ugreen-dkms configurando gli opportuni trigger, cioè gli eventi che provocano l'accensione dei LED. In questo modo sarà possibile ad esempio far lampeggiare un LED quando c'è attività di rete o dei dischi. Il tutto avverrà automaticamente senza che debbano essere eseguiti comandi speciali.

Dopo aver installato il pacchetto led-ugreen-dkms si avrà il modulo kernel led-ugreen compilato e installato nella directory /lib/modules/6.12.57+deb13-amd64/updates/dkms/. Il modulo si carica con

modprobe led-ugreen

per attivare il nuovo device I2C si esegue lo script (fornito dal pacchetto led-ugreen-utils):

ugreen-probe-leds

dopodiché nella directory /sys/class/leds/ dello pseudofilesystem compaiono i link disk1, disk2, netdev e power.

È possibile manipolare lo stao dei LED scrivendo gli opportuni valori nei nodi relativi. Ad esempio per controllare la brillantezza:

echo '0' > /sys/class/leds/netdev/brightness
echo '127' > /sys/class/leds/netdev/brightness
echo '255' > /sys/class/leds/netdev/brightness

oppure è possibile determinare il colore con i valori RGB, ad esempio per avere il rosso:

echo '255 0 0' >  /sys/class/leds/netdev/color

Si possono impostare gli effetti blink e breath oppure una luce fissa con l'effetto none:

echo 'blink 100 100' > /sys/class/leds/netdev/blink_type
echo 'breath 500 300' > /sys/class/leds/netdev/blink_type
echo 'none' > /sys/class/leds/netdev/blink_type

Un esempio più complesso che collega il lampeggiamento del LED netdev all'attività dell'interfaccia di rete enp1s0:

#!/bin/sh
modprobe led-ugreen
modprobe ledtrig-netdev
led="netdev"
echo netdev > /sys/class/leds/$led/trigger
echo enp1s0 > /sys/class/leds/$led/device_name
echo 1 > /sys/class/leds/$led/link
echo 1 > /sys/class/leds/$led/tx
echo 1 > /sys/class/leds/$led/rx
echo 100 > /sys/class/leds/$led/interval

Il pacchetto led-ugreen-utils fornisce gli script per impostare il normale funzionamento dei LED. Si tratta principalmente di due script Bash che gireranno in background, uno si occupa del LED netdev e l'altro dei LED disk[12]. Per ragioni di efficienza lo script che gestisce i LED dei dischi si appoggia a due programmi esterni scritti in C++ e compilati, questo perché il lampeggiamento a seguito di attività disco richiede il polling continuo e molto frequente di uno pseudofile in /sys/devices/, che è sconsigliabile effettuare con uno shell script. Anche il monitoraggio dello stato di stand-by dei dischi è preferibile effettuarlo con un progamma esterno in C++ compilato, per gli stessi motivi di efficienza.

Il modo più efficiente per far lampeggiare i LED dei dischi è usare il programma ugreen-blink-disk (eseguibile compilato da sorgente C++), che deve essere lanciato e fatto girare in background. Ecco un esempio che effettua il polling ogni 0.1 secondi per rilevare attività sui device /dev/sda e /dev/sdb, in caso affermativo fa lampeggiare i LED disk1 e disk2 rispettivamente:

ugreen-blink-disk 0.1 sda disk1 sdb disk2

Esiste anche il comando ugreen-check-standby (eseguibile compilato da sorgente C++) che cambia il colore dei LED dei dischi da COLOR_DISK_HEALTH a COLOR_DISK_STANDBY e viceversa quando il disco entra o esce dalla modalità stand-by. Se il LED ha una colorazione diversa (es. COLOR_DISK_UNAVAIL oppure COLOR_ZPOOL_FAIL) non modifica il colore. Il programma esegue un loop infinito e deve girare in background, ecco come può essere lanciato:

ugreen-check-standby 1 "0 0 255" "255 255 255" sda disk1 sdb disk2

ATTENZIONE: L'assegnamento dei nomi sda ed sdb non è garantito che avvenga sempre nello stesso ordine ad ogni boot, si deve fare riferimento al contenuto di /dev/disk/by-id/ e al seriale del disco per essere certi di abbinare il disco al rispettivo LED.

Il pacchetto led-ugreen-utils mette a disposizione tre servizi Systemd che provvedono - facendo uso degli script shell visti sopra - a inizializzare i LED e a monitorare lo stato dei dischi e della scheda di rete rispettivamente. La configurazione è contenuta in /etc/ugreen-leds.conf di cui viene fornito un esempio /etc/ugreen-leds.example.conf.

Per far sì che i moduli vengano caricati e che il device I2C sia registrato ad ogni bootstrap si attiva il servizio Systemd ugreen-probe-leds fornito dal pacchetto:

systemctl enable --now ugreen-probe-leds.service

Il servizio ugreen-diskiomon.service, se attivato, esegue in background lo script /usr/bin/ugreen-diskiomon:

systemctl enable --now ugreen-diskiomon.service

Tale script molto complesso si occupa di monitorare lo stato dei dischi tramite le funzioni SMART, lo stato di stand-by, l'eventuale messa off-line per guasto e riflettere le varie condizioni con i colori configurati in /etc/ugreen-leds.conf. Lo script a sua volta esegue in background il programma /usr/bin/ugreen-blink-disk che monitora l'attività dei dischi ed eventualmente manda segnali al /sys/class/leds/disk{1|2}/shot Per questo viene caricato il modulo kernel ledtrig-oneshot. Anche il programma /usr/bin/ugreen-check-stanby viene eventualmente eseguito in background, per riflettere lo stato di stand-by dei dischi nel colore dei LED.

Il servizio ugreen-netdevmon@enp1s0.service, se attivato, esegue in background lo script /usr/bin/ugreen-netdevmon (Verificare che il nome della scheda di rete sia effettivamente enp1s0):

systemctl enable --now ugreen-netdevmon@enp1s0.service

Il LED viene inizializzato per eseguire la funzione di base di lampeggiamento in caso di attività di rete, per questo viene caricato il modulo kernel ledtrig-netdev. Questa funzione di base non ha bisogno dell'esecuzione di altri programmi in background, ma lo script resta in esecuzione per monitorare la raggiungibilità del gateway (tramite ping) e la velocità del link. Eventuali anomalie sono segnalate con gli opportuni colori, configurati a loro volta in /etc/ugreen-leds.conf.

• My public notes, findings and experience with UGREEN DXP6800 Pro NAS from kickstarter
• Trying to modify BIOS to lower power consumption
• DXP2800 Product Documentation
• LED Controller for UGREEN's DX/DXP NAS Series
• Installing Debian On Ugreen
• How to Control and Customize LED Lights UGREEN NAS 2025
• UGREEN NASync DXP2800 BIOS Smart Fan Settings to Lower Temps