meta data for this page
  •  

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
hw:qnap_ts-228 [2023/02/20 21:42] – niziakhw:qnap_ts-228 [2023/03/16 13:19] (current) – niziak
Line 65: Line 65:
 </code> </code>
  
-  * /dev/md9    - ext4 - 517,62 MiB (157,61 MiB used)+  * /dev/md9    - ext4 - 517,62 MiB (157,61 MiB used)  - /mnt/HDA_ROOT
   * /dev/md256  - linux-swap - 517,69 MiB   * /dev/md256  - linux-swap - 517,69 MiB
   * /dev/md1    - LVM2   * /dev/md1    - LVM2
     * '/dev/vg1/lv544' [<18,54 GiB]  - zeros!     * '/dev/vg1/lv544' [<18,54 GiB]  - zeros!
     * '/dev/vg1/lv1' [1,79 TiB] - LUKS aes cbc-plain sha1     * '/dev/vg1/lv1' [1,79 TiB] - LUKS aes cbc-plain sha1
-  * /dev/md13   - ext3 - 448,14MiB (324,98 MiB used)+  * /dev/md13   - ext3 - 448,14MiB (324,98 MiB used)   - /mnt/ext
   * /dev/md322  - linux-swap - 6,90 GiB   * /dev/md322  - linux-swap - 6,90 GiB
 +
 +After installing mdadm, OS automatically create some MD devices, but some of them are in read-only state and consist only one RAID member.
 +To force correct detection again:
  
 <code bash> <code bash>
Line 77: Line 80:
 mdadm --assemble --scan  mdadm --assemble --scan 
  
 +mdadm --detail /dev/md1
 +/dev/md1:
 +           Version : 1.0
 +     Creation Time : Fri Apr  7 17:18:29 2017
 +        Raid Level : raid1
 +        Array Size : 1943559616 (1853.52 GiB 1990.21 GB)
 +     Used Dev Size : 1943559616 (1853.52 GiB 1990.21 GB)
 +      Raid Devices : 2
 +     Total Devices : 2
 +       Persistence : Superblock is persistent
 +
 +       Update Time : Mon Feb 20 13:17:08 2023
 +             State : clean, degraded 
 +    Active Devices : 1
 +   Working Devices : 2
 +    Failed Devices : 0
 +     Spare Devices : 1
 +
 +Consistency Policy : resync
 +
 +              Name : 1
 +              UUID : a1fa9f39:73ca1af0:96ad282b:0fb0c934
 +            Events : 1252602
 +
 +    Number   Major   Minor   RaidDevice State
 +       2       8       19        0      spare rebuilding   /dev/sdb3
 +       1       8       35        1      active sync   /dev/sdc3
 +
 +</code>
 +
 +Two members are present but one is in ''spare rebuilding'' state and nothing happens.
 +To start rebuild switch array into RW mode:
 +
 +<code bash>
 +mdadm --readwrite /dev/md1
 +
 +cat /proc/mdstat 
 +
 +Personalities : [raid1] 
 +md1 : active raid1 sdb3[2] sdc3[1]
 +      1943559616 blocks super 1.0 [2/1] [_U]
 +      [===============>.....]  recovery = 75.3% (1463781952/1943559616) finish=421.1min speed=18985K/sec
 +</code>
 +
 +Another option to force correct resync - but not used in this case:
 +<code bash>
 +mdadm --stop /dev/md1
 +mdadm --assemble --run --force --update=resync /dev/md1 /dev/sdb3 /dev/sdc3
 +</code>
 +
 +<code bash>
 pvscan  pvscan 
   WARNING: PV /dev/md1 in VG vg1 is using an old PV header, modify the VG to update.   WARNING: PV /dev/md1 in VG vg1 is using an old PV header, modify the VG to update.
Line 111: Line 165:
 </code> </code>
  
 +===== /dev/vg1/lv1 encrypted =====
  
-cryptsetup +Volume is encrypted. It contains standard LUKS header. 
 +Google says encryption password is derived from user supplied password using not know algo. 
 +It points to NAS local utility:
  
 +<code bash>
 +/sbin/storage_util --encrypt_pwd pwd=YOUR_PASSWORD
 +Encrypted passwd is: …………………………………..
 +</code>
  
 +Reference: 
 +  * [[https://unix.stackexchange.com/questions/685821/how-to-mount-on-linux-a-qnap-external-drive-with-luks-partition]]
 +  * [[https://www.linux-howto.info/mount-qnap-encrypted-volume/]]
 +
 +==== Try to run x86 QTS in Proxmox VM ====
 +
 +Set VGA to ''none''. Add serial port for console - Proxmox console will automatically switch console to serial port.
 +Import raw image as VM disk: <code bash>qm importdisk 304 F_TS-X85_20170210-1.3.0_512M.img local-lvm --format raw</code>
 +
 +Problem: cannot stop at GRUB, it boots kernel, loads initrd and then stuck. Probably some HW dependencies are not met (emmc disk?).
 +Switched to simpler solution with Docker (see below).
 +
 +==== storage_util docker ====
 +
 +Based on files from ''F_TS-X85_20170210-1.3.0_512M'' I've created root filesystem with ''storage_util'' and minimum required libraries.
 +
 +And it works. Generated password opens LUKS storage.
 +
 +==== mkpasswd ====
 +
 +After making Docker image, I found post on QNAP forum that the password can be generated using simple MD5 hash:
 +<code bash>
 +mkpasswd -m md5 -S YCCaQNAP
 +</code>
 +
 +
 +<code bash>
 cryptsetup luksOpen /dev/vg1/lv1 nas cryptsetup luksOpen /dev/vg1/lv1 nas
 +mount /dev/mapper/nas /mnt/nas
 +</code>
  
  
 +===== Recovery =====
  
 +<code bash>
 +apt install testdisk
 +photorec /dev/mapper/nas
 +</code>
  
 +
 +===== unmount and shutdown =====
 +
 +<code bash>
 +umount /dev/mapper/nas
 +cryptsetup luksClose nas
 +dmsetup remove vg1-lv544
 +dmsetup remove vg1-lv1
 +mdadm --stop /dev/md1
 +
 +mdadm --stop /dev/md256
 +mdadm --stop /dev/md9
 +mdadm --stop /dev/md322
 +mdadm --stop /dev/md13
 +</code>