rigacci.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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:

<code>
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
</code>

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

Ecco le info su CPU e RAM:

<code>
# 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
</code>

<code>
# free       
              total         used         free       shared      buffers
  Mem:       515524        95332       420192            0         1332
</code>

<code>
# 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"
</code>

===== 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:

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

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:

<code>
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
</code>

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:

<code>
qcontrol eup off
ethtool -s eth0 wol g
qcontrol wol on
</code>

===== 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**.

<code>
         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ 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
</code>
===== 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:

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

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:

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

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//"):

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

===== 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:

<code>
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
</code>

==== 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:

<code bash>
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.
</code>

**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**:

<code>
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)
</code>

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

<code>
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
</code>

==== 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:

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

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

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

Update the initramfs with:

<code>
update-initramfs -k all -u
</code>

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:

<code>
unmkinitramfs /boot/initrd.img-4.19.0-18-marvell ./initramfs/
</code>

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

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

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.

===== USB audio dongle =====

I use the QNAP also as a **media player** because it stores all my audio files. I attached it to my HiFi amplifier through an **USB audio dongle** and an **audio cable** (3.5 mm jack - RCA stereo plugs).

I faced a problem with that audio USB interface, because at every reboot the device is not working and it does not show in **lsusb** output. The manual workaround was to unplup and re-plug the device into the USB port.

Fortunately it is possibile to force the re-initialization of the USB controller with the following script:

<code bash>
#!/bin/sh
# If the USB audio device is missing, try to reset the USB controller.
# USB 2.0 devices may be under /sys/bus/pci/drivers/ehci_hcd instead.
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
lsusb | grep -q 'JMTek, LLC. audio controller'
RET=$?
if [ "$RET" -ne "0" ]; then
    echo "USB audio device missing, trying to reset the bus."
    cd /sys/bus/pci/drivers/xhci_hcd
    echo -n "0000:02:00.0" > unbind
    sleep 1
    echo -n "0000:02:00.0" > bind
fi
</code>

So I created a systemd service to be run when the host reaches the multi-user target. Create the file **/etc/systemd/system/usb-audio-dongle-reset.service**:

<file>
# /etc/systemd/system/usb-audio-dongle-reset.service
#
# Service executed once the system has reached the multi-user status.
#
#  Type=oneshot         The unit is up after the main process exits.
#  RemainAfterExit=yes  The service shall be considered active even
#                       when all its processes exited.
#
# Eanble the service with:
#   systemctl enable my-startup.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/usb-audio-dongle-reset

[Install]
WantedBy=multi-user.target
</file>

Enable and start the service with:

<code>
systemctl --now enable usb-audio-dongle-reset.service
</code>