Differences

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

--- doc:appunti:hardware:qnap_ts-120 [2022/02/11 09:09] – [Partition, dump and restore] 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 120: / Line 175: @@
 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**. 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**:
+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>
@@ Line 127: / Line 199: @@
     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 ====
-Beware that the **initramfs** installed into the **flash memory** will search 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.
+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.
@@ Line 155: / Line 239: @@
 </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.
+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:
-You can verify that the proper //rootfs// device is written into the //initramfs// image: unpack the the content of your initramfs by executing:
 <code>
@@ Line 169: / Line 251: @@
 </file>
-Now try to reboot. If the problem is fixed, you may remove the file **/etc/initramfs-tools/conf.d/root** and **update-initramfs** again: now the proper rootfs will be autodetected.
+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.