I went for a Chinese N100 board with 6 SATA ports from Glovary, an Amazon reseller of CWWK boards similar to this one. Equipped with 8 GiB of RAM, a power supply and without any CPU fans, the total hardware costs were about 272€. To save money on the case in stay within my allocated budget of 300€ (without hard drives) I decided to 3D print a case. There are a few offerings out there that match the mini-ITX form factor with a SFF power supply and fit 4 drives. My favourite was the NASHole. However, the drive bay would only fit some of my drives. It turns out the thickness of drives is not standardised! I tried another print as well with similar results, before deciding to shell out another 100€ for a Fractal Design Node 304 case. This worked out fine and the fans are quiet and strong enough to keep the CPU temperature in a good range.

My previous NAS was running on Armbian a Debian derivative for ARM. I had tried to set it up with Ansible workbooks, however I stopped midway as I felt they were limited, and not by design idempotent. I installed other things manually, with the contingency plan being to make a full disk copy of the SD card running the OS and replace it whenever it stopped (happened once or twice). Since I have been using Guix as a package manager for the last few years, never daring to go full Guix system on my day-to-day hardware, I welcomed the opportunity to do so on the less mission-critical NAS. This turned out to be a source of much frustration. I clocked 33 hours and 37 minutes until today trying to set up the NAS operating systems and all the services I had running previously:

• encrypted disks with parity using snapraid
• mergerfs to pool all the drives
• regular snapraid sync and scrub
• bind mounts as target for backups
• CIFS/SAMBA access for my scanner
• monitoring using monitorix

Of these I have finally achieved all but the last. But even simple things such as the bind mounts turned out to require careful reading of the documenting, filtering out outdated information (e.g. from the Guix Cookbook) and asking in the IRC channel. I will maybe share my configuration in a future post.

To take a step back for a minute: one advantage or appeal of Guix is its declarative nature. You specify what you want inside a text file and guix instantiates an operating system from it containing exactly and only what was specified. This is amazing for reproducibility amongst other. So if I keep at it, I will have a system declaration that I will be able to reproduce on any future NAS (assuming at least it runs the same kernel). But since I only change NAS every 6 years, is it really worth it? The main reason I keep at this (despite the sunk costs fallacy) is because I want to use Guix as the backend to my DAMright! project about digital asset management (done right!).

With a declarative system configuration that covers most of the ground of what I expect from my NAS, I can showcase off some of the cooler stuff about Guix: I can use the file to instantiate a disk image that when burned onto an SD card will run the OS I declared. In my case I even declared that disk image to have a separate partition storing the encryption keys for my disks that gets unmounted after all the disks have been decrypted (this is not meant as a security measure, my threat modelling for full disk encryption is simply that it makes discarding/re-selling old drives a no-brainer). This allows me to A/B boot new versions using two SD cards: if the new OS declaration is faulty in any way, I just swap the previous SD card in and we are back to normal. All state is declared explicitly, no bad surprises. I might have to move to using NVMe drives for the OS as stated in the next section.

Ideally the NAS will run 24/7. Since I live in an environment with high energy costs (and being environmentally conscious) I want to reduce the power consumption of the NAS as much as possible. My previous research had surfaced internet posts of people with idle consumption around or under 10W. This would be acceptable for me. However, I am still far from reaching this. First thing I did to optimise power consumption: update the BIOS to the latest version. This was refreshingly simple using the instructions here:

1. Mount the iso file from this link

mount -o loop /path/to/iso /mount_path

1. Copy all files to a FAT32 formated SD card
2. Boot from the SD card: the BIOS flashing utility autostarts. Follow instructions on screen (basically, press ENTER, wait for BIOS to update, remove SD card and press ENTER to reboot).

Now came the harder part. The BIOS has some hidden settings which need to be enabled by pressing Ctrl+F1. Then I followed an online post. This is made a bit more difficult by the fact that some BIOS settings seemingly reset, but apparently it is just their display that resets but not the setting itself. Go figure! Solution online is here (save as User Defaults and reload everytime).

With these changes came the first surprise: the system would not boot anymore! Much later did I understand, this might be due to using the SD slot instead of an NVMe drive. And yes, by plugging in another Fedora NVMe I could boot with setting the C-states to C10 and after powertop --auto-tune I could actually get to C10 (in Fedora). The same did not work using Guix System. So my current system idling at 25W with 3 disks. This leads to about 100€/year utility bill. And the culprit seems to be Guix again. Maybe due to the linux-libre kernel. I will investigate further hoping to reduce power consumption. On the Fedora system it was at 15W idle. So today, I can throw away all my guix configuration and start from a Fedora base which gives me lower power consumption at the cost of re-configuring all the sofware. Or I can try to debug why I cannot get to C10 or C8 with guix, not knowing how long this might take. Tough choice! I will probably post once I have this figured out

I want to love Guix, I really do! However, its learning curve is very steep and help cannot be found as easily online and with other distribution with more users. In hindsight, I should have bought a case for the NAS mainboard straight away and perhaps used a more common operating system.