QNAP TS-120

In un paio di minuti il dispositivo richiede un indirizzo IP via DHCP, altrimenti si assegna un 169.254.100.100, quindi risulta attivo sulla rete con queste porte aperte:

PORT      STATE SERVICE
22/tcp    open  ssh
443/tcp   open  https
8080/tcp  open  http-proxy
8090/tcp  open  unknown
49153/tcp open  unknown
49154/tcp open  unknown

L'accesso SSH con utente admin e password admin dà in effetti accesso root.

Ecco le info su CPU e RAM:

# cat /proc/cpuinfo 
Processor name  : Feroceon 88F6282 rev 1 (v5l) @ 1.6 GHz 
BogoMIPS        : 1589.24
Features        : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

# free       
              total         used         free       shared      buffers
  Mem:       515524        95332       420192            0         1332

# cat /proc/mtd   
dev:    size   erasesize  name
mtd0: 00080000 00010000 "U-Boot"
mtd1: 00200000 00010000 "Kernel"
mtd2: 00900000 00010000 "RootFS"
mtd3: 00300000 00010000 "RootFS2"
mtd4: 00040000 00010000 "U-Boot Config"
mtd5: 00140000 00010000 "NAS Config"

Vedere questa guida: Installing Debian on QNAP TS-11x and TS-12x devices.

Qui una copia locale dell'installer Debian e del contenuto originale della flash: qnap_ts-120.

Avviando dal firmware di base (quello su flash installato di fabbrica) si ha a disposizione un server SSH minimale, che non permette neanche il comando scp. Per copiare qualcosa via rete (ad esempio una partizione della flash oppure il conenuto di una cartella) si possono usare questi trucchi dal PC:

ssh admin@169.254.100.100 "cat /dev/mtdblock0" > mtd0
ssh admin@169.254.100.100 "tar cf - /mnt/sda2" | tar xvf -

Installazione Debian in breve: da una sessione SSH si scarica l'installer ufficiale Debian per QNAP (da ftp.debian.org), si lancia la procedura che scrive la flash e si effettua il reboot:

cd /tmp
busybox wget http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/initrd.gz
busybox wget http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/kernel
busybox wget http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/flash-debian
busybox wget http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/model
sh flash-debian
reboot

Sempre via SSH, login successivo (utente installer, password install) parte la procedura di installazione. Con la modalità expert è stato possibile installare Debian Jessie con kernel 3.12. Ad oggi (2014-02-11) pare risolto il problema di kernel qui descritto: QNAP TS-210 will not boot >=3.12-1, needs dtb.

È stato possibile fare l'aggiornamento Debian dalla versione 7 Wheezy ⇒ 8 Jessie ⇒ 9 Stretch fino a 10 Buster. Con il partizionamento originale della memoria flash non è possibile installare Debian 11 Bullseye poiché lo spazio per flashare l'immagine del kernel non è sufficiente. Esiste tuttavia una ricetta per cambiare lo schema di partizione oppure è possibile installare Debian 11 mantenendo il kernel di Debian 10.

• FAQ about Debian on QNAP TS-11x/TS-12x
• Debian on QNAP TS-11x/TS-12x

Con Debian Jessie, kernel 3.12.9 e qcontrol 0.5.2-2 il bug 703888 è risolto e il Wake-on-LAN funziona esattamente come su un PC: prima di fare lo shutdown bisogna mettere la scheda di rete nella modalità opportuna, tale funzione poi resta abilitata fintanto che il device è collegato all'alimentazione. Nel caso in cui venga scollegato e poi ricollegato alla rete, il WoL non funziona.

Le indicazioni sono contenute in questo post: Wake-On-LAN with Debian on a qnap TS-119P2+, in pratica prima di fare shutdown bisogna impartire i comandi:

qcontrol eup off
ethtool -s eth0 wol g
qcontrol wol on

On the circuit board of the QNAP TS-120 there is a JTAG connector for the serial console. I used an old CD-ROM audio cable because it had the right connector. I wired only the GND, TX and RX pins from to QNAP to a serial-to-USB adapter. The adapter was inserted intp a GNU/Linux computer running the minicom program. The speed of the serial line was set to 115200. The connector pinout is documented in this page: Serial console for QNAP TS-11x/TS-12x.

This is the boot process captured from the serial line. At the end of the bootstrap you will get a login prompt.

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|  ** LOADER **
 ** MARVELL BOARD: DB-88F6282A-BP LE TS-120 ,PHY=1.8v

U-Boot 1.1.4 (Nov  5 2012 - 17:39:47) Marvell version: 3.5.3

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CD5C0

Soc: MV88F6282 Rev 1CPU running @ 1600Mhz L2 running @ 533Mhz
SysClock = 533Mhz , TClock = 200Mhz

Into the QNAP TS-120 there is a Real Time Clock. You can see the battery on the motherboard and the kernel will print this on the serial console:

[    1.262622] hctosys: unable to open rtc device (rtc0)
[    1.628724] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0

The problem is that the rtc support is compiled as a module and the kernel executes hctosys before the module is loaded, so before the rtc0 device is available. When the rtc0 device becomes available, the udev subsystem is triggered by the file /usr/lib/udev/rules.d/85-hwclock.rules. The rule says to run the script /usr/lib/udev/hwclock-set.

Historically that script does nothing if systemd is running, because it assumes that the system clock was already set from the hardware clock. See Debian bug #855203 - hwclock-set: Synchronize from hwclock despite systemd presence.

A quick and dirty solution is to edit the script /lib/udev/hwclock-set removing the systemd check:

#if [ -e /run/systemd/system ] ; then
#    exit 0
#fi

You should also comment-out the hwclock commands containing the --systz option, (from the man page: “It is intended to be used in a startup script on systems with kernels above version 2.6 where you know the System Clock has been set from the Hardware Clock by the kernel during boot”):

  #/sbin/hwclock --rtc=$dev --systz --badyear
...
  #/sbin/hwclock --rtc=$dev --systz

It is possibile to install a 4 Tb Hard Disk on the old QNAP TS-120: I successfully installed a Western Digital WD40PURZ.

The original disk was partitioned using a MSDOS partition table, but there is a 2 Tb limit on partition size when using MSDOS table, so I decided to partition the new disk using GPT. Fortunately enough the kernel does support GPT and I was able to use the following partition schema:

Number  Start   End     Size    File system     Name     Flags
 1      1049kB  5000MB  4999MB  ext4            primary
 2      5000MB  6000MB  1000MB  linux-swap(v1)  primary
 3      6000MB  4001GB  3995GB  ext4            primary

To avoid a complete reinstall, I connected the new disk to a GNU/Linux computer, then partitioned the disk and performed a dump/restore via SSH.

For partitioning I used parted, see above for the partition schema. I created the ext4 filesystem and performed a dump/restore over the net, using SSH:

mkfs.ext4 /dev/sdb1
mkswap /dev/sdb2
blkid /dev/sdb1
blkid /dev/sdb2
# Take note of the UUIDs of new partitions.
mount /dev/sdb1 /mnt
cd /mnt
ssh root@qnap.lan 'dump -0 -a -b 64 -f - /dev/sda1' | restore -r -b 64 -f -
vi /mnt/etc/fstab
# Update the UUIDs in fstab.

WARNING: It is advisable to change the UUID of the root filesystem to match the one on the old disk, this is beacuse the initramfs stored into the QNAP flash memory will search the rootfs by UUID. It should be possibile change the UUID on the unmounte partition using tune2fs -U <UUID> /dev/sdb1. I forgot to make this step, so I had to attach a serial cable to the QNAP and fix the boot process manually. See below.

Fortunately the hard disk was seen correctly both on the computer and later on the QNAP, I mean in particular the overall size and the logical/physical sector size. This is a subtle matter, e.g. the QNAP bootloader seems limited to disk size of 2 Tb, during bootstrap you can read this on the serial console:

Model: WDC WD40PURZ-85AKKY0    Firm: 80.00B80 Ser#:    WD-WX12D81D4P9U
    Type: Hard Disk
    Supports 48-bit addressing
    Capacity: 1718295.8 MB = 1678.0 GB (-775897424 x 512)

but from the kernel point of view, everything seems ok:

scsi 1:0:0:0: Direct-Access     ATA      WDC WD40PURZ-85A 0B80 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
sd 1:0:0:0: [sda] 4096-byte physical blocks
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3
sd 1:0:0:0: [sda] Attached SCSI disk

Once the new disk was partitioned, formatted and populated using restore, I installed it into the QNAP. Unfortunately it didn't boot. The initramfs installed into the flash memory looks for the root filesystem using the UUID, so you have to set the partition UUID on the new disk to match the old one, otherwise the boot process will fail.

If you forget this step (like I did) you can attach to the serial console and fix the problem.

When the boot process fails, you get the initramfs prompt, here you can temporarly fix the problem by making a symlink from the new UUID to the missing one:

(initramfs) cd /dev/disk/by-uuid/
(initramfs) ln -s <new-UUID> <old-UUID>
(initramfs) exit

The QNAP should boot. To make a permanent fix you have to create a file /etc/initramfs-tools/conf.d/root containing the following:

ROOT=/dev/disk/by-uuid/<new-UUID>

Update the initramfs with:

update-initramfs -k all -u

The update-initramsf on the QNAP will call the flash-kernel tool to write the kernel and the initramfs images to the proper flash partitions. Flashing the images requires some minutes. You can verify that the proper rootfs device is written into the initramfs image: unpack its content by executing:

unmkinitramfs /boot/initrd.img-4.19.0-18-marvell ./initramfs/

Verify that inside the file /conf/param.conf is declared the proper device:

ROOT="/dev/disk/by-uuid/423996a4-7a6c-497d-bc45-ecfa98385c47"

Now try to reboot. If the problem is fixed, you may remove the file /etc/initramfs-tools/conf.d/root and run update-initramfs again: now the proper rootfs will be autodetected.