noxz-sites

A collection of a builder and various scripts creating the noxz.tech sites
git clone https://noxz.tech/git/noxz-sites.git
Log | Files | README | LICENSE

noxz.tech/articles/moving_from_my_hacked_readynas_to_a_raspberry_pi/index.www
1I used to have a hacked/rooted RNRX4000 (ReadyNAS 2100) in which I had replaced
2the original operating system with VoidLinux, having the boot partition on the
3integrated flash memory (100MB). Due to it being noisy and power-consuming, I
4wanted to replace it and found the solution in Argon40’s Argon EON, in which a
5Raspberry Pi is meant to manage SATA-drives connected to it over USB3.
6
7.PIMG disk.png
8
9My initial plan was to use a ZFS setup on the Pi, but I quickly realized that
10this would be a problem. Specifically, ZFS is incompatible with the latest
11kernel version of the Raspberry Pi OS. I could, of course, have
12chosen another distribution with an older kernel version, or have locked the
13release of the kernel in the packet manager. But having this issue early on
14with the knowledge of being forced to manage kernel releases manually and at
15the same time being aware of security concerns of not running updated kernels
16made me think of other solutions.
17
18So, why not run a simple
19.ICD md
20solution using the kernel module
21.I dm-integrity
22for detection and mitigation of bit rot? Sounds simple, right? No! Every
23distribution for Raspberry Pi I looked at lacked any support for
24.I dm-integrity
25out of the box. So, it was either back to manual kernel management, including
26compiling with support for
27.I dm-integrity ,
28or find another solution.
29
30I think I have found a good enough solution. By using
31.ICD md
32for raid and redundancy together with internal and external backup using
33.ICD borg ,
34I had a pretty solid solution for disk failure and historical archiving. I only
35lacked a solution for bit rot protection.
36
37So, I did what I usually do and implemented my own solution instead. With the
38inspiration of the corruption detecting program
39.ICD shatag
40and its previous C-reimplemented alternative
41.ICD cshatag
42(now implemented in Go), I wrote
43.ICD acst ,
44or the
45.I "Actual C-implementation of a Simple shaTag" .
46Well, it's not really an implementation of
47.ICD shatag
48as I have chosen some alternative ways of implementing it. But it is simple and
49written in C, so there is that.
50
51The idea is to have
52.ICD acst
53running on a scheduled basis, making sure to compute checksums of each and
54every file on the NAS and, at the same time, detect any change or corruption to
55the actual data. If any such corruption is detected, I can use
56.ICD borg
57to verify the corruption and, at the same time, ideally, restore the
58non-corrupted version of the file in question.
59
60I also stumbled upon another problem as I had created and successfully
61assembled and mounted the raid system using
62.ICD mdadm .
63When restarting the NAS, one of the disks would never assemble. After some
64time, too much time in fact, I realised that the disk was too slow to be
65initialized before the operating system tried to assemble the raid set. The
66simple solution to this problem was to add a 5 second delay when booting using
67the
68.ICD "/boot/cmdline.txt"
69file. I just appended
70.ICD "rootdelay=5"
71at the end of the command line for booting Linux and \(em voilà \(em both
72disks were now assembling correctly.
73
74This is the story of me moving from a noisy and power hungry ReadyNAS to an
75arm-based Raspberry Pi, while at the same time writing the code for
76.URL //noxz.tech/software/acst acst .