Differences

This shows you the differences between two versions of the page.

--- doc:appunti:hardware:qnap_ts-120 [2022/02/10 22:34] – [Upgrading to 4 Tb Hard Disk] niccolo
+++ doc:appunti:hardware:qnap_ts-120 [2022/02/12 08:06] (current) – [The Serial Console] niccolo
@@ Line 95: / Line 95: @@
 </code>
-===== Console seriale =====
+===== The Serial Console =====
-Vedere qui: [[http://www.cyrius.com/debian/kirkwood/qnap/ts-119/serial/]]
+{{ .: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]].
-===== Tips =====
+^ Console Pinout  ^^
+^ 1  | TX        |
+^ 2  | VCC +3.3  |
+^ 3  | RX        |
+^ 4  | GND       |
-  * FIXME C'è un clock RTC a bordo?
+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 =====
@@ Line 116: / Line 171: @@
 </code>
-==== Dump and restore ====
+==== Partition, dump and restore ====
-To avoid a complete reinstallation, I performed a dump/restore via SSH.
+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.
-==== Keel the UUID of root filesystem ====
+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:
-Beware that the **kernel** installed into the **flash memory** will search the root filesystem using the **UUID**, so you have to change the partition UUID on the new disk once formatted, 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.
+<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>
-# flash-kernel
+scsi 1:0:0:0: Direct-Access     ATA      WDC WD40PURZ-85A 0B80 PQ: 0 ANSI: 5
-kirkwood-qnap: machine: QNAP TS219 family
+sd 1:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
-Using DTB: kirkwood-ts219-6282.dtb
+sd 1:0:0:0: [sda] 4096-byte physical blocks
-Installing /usr/lib/linux-image-4.19.0-18-marvell/kirkwood-ts219-6282.dtb into /boot/dtbs/4.19.0-18-marvell/./kirkwood-ts219-6282.dtb
+sd 1:0:0:0: [sda] Write Protect is off
-Taking backup of kirkwood-ts219-6282.dtb.
+sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-Installing new kirkwood-ts219-6282.dtb.
+ sda: sda1 sda2 sda3
-flash-kernel: installing version 4.19.0-18-marvell
+sd 1:0:0:0: [sda] Attached SCSI disk
-flash-kernel: appending /usr/lib/linux-image-4.19.0-18-marvell/kirkwood-ts219-6282.dtb to kernel
-Generating kernel u-boot image... done.
-Flashing kernel (using 2070050/2097152 bytes)... done.
-Flashing initramfs (using 6093136/9437184 bytes)... done.
 </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.