====== QNAP TS-120 ====== ===== Prima accensione senza disco fisso ===== 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" ===== Installazione Debian ===== Vedere questa guida: [[http://www.cyrius.com/debian/kirkwood/qnap/ts-119/install/|Installing Debian on QNAP TS-11x and TS-12x devices]]. Qui una copia locale dell'installer Debian e del contenuto originale della flash: [[http://www.rigacci.org/pub/Linux/qnap_ts-120/|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 [[http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/|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: [[https://lists.debian.org/debian-boot/2014/01/msg00227.html|QNAP TS-210 will not boot >=3.12-1, needs dtb]]. ===== Upgrade Debian ===== È 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. * **[[https://www.cyrius.com/debian/kirkwood/qnap/ts-119/faq/|FAQ about Debian on QNAP TS-11x/TS-12x]]** * **[[https://www.cyrius.com/debian/kirkwood/qnap/ts-119/upgrade/|Debian on QNAP TS-11x/TS-12x]]** ===== Wake-on-LAN ===== Con Debian Jessie, kernel 3.12.9 e qcontrol 0.5.2-2 il bug [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703888|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: [[http://michael.stapelberg.de/Artikel/qnap_ts119_wol|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 ===== The Serial Console ===== {{ .:qnap:qnap-ts-120-serial-console-jtag.jpg?direct&400|QNAP TS-120: Console connector}} {{ .:qnap:qnap-ts-120-serial-console-closeup.jpg?direct&160|Serial Console JTAG Connector}} 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: [[http://www.cyrius.com/debian/kirkwood/qnap/ts-119/serial/|Serial console for QNAP TS-11x/TS-12x]]. ^ Console Pinout ^^ ^ 1 | TX | ^ 2 | VCC +3.3 | ^ 3 | RX | ^ 4 | GND | 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 ===== Real Time Clock rtc0 ===== 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 **[[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203|#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 ===== Upgrading to 4 Tb Hard Disk ===== 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 ==== Partition, dump and restore ==== 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 /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 ==== Beware the UUID of root filesystem ==== 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 (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/ 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.