Running a Modern Debian on the Netgear ReadyNAS NV+ v2

April 21, 2020 at 18:23

I have an old ReadyNAS NV+ v2 (not to be confused with the SPARC-based v1) that has been my workhorse home NAS for a good 7 years now (previously I had an older Netgear NAS that suffered a hardware failure and needed to be replaced). It’s a great piece of hardware, but the software hasn’t seen a major update in many years, and the OS is based on Debian squeeze, which is several releases behind current stable, and is no longer maintained.

I recently tried to visit the NAS’s admin web UI, only to see a recently-updated Firefox throw up a big scary security warning, telling me that TLS 1.0 and 1.1 are disabled in the browser, but the server I’m trying to connect to (the NAS) doesn’t support TLS 1.2 or newer. It allowed me to bypass the warning for now, but eventually I expect that older TLS versions (just like SSLv3 before it) will be removed entirely.

No problem, I thought, as I ssh’ed into the NAS. As I expected, the issue was that Apache was linked against an old version of OpenSSL which lacks TLS 1.2 support. To avoid disturbing the system itself too much, I figured I’d use debootstrap to create a chroot with a more modern Debian version, and run the webserver (or a proxy) from there.

But that didn’t work out. The glibc versions in Debian testing, buster, stretch, and even jessie all require a newer kernel than what’s running on the ReadyNAS (2.6.31.8). I looked at some other OSes, like Alpine (which uses musl and wouldn’t have the same issue) and nixOS (which I expected might just be more flexible), but neither of them support the armv5-based CPU in the NV+ v2.

After a bunch of dead ends, I finally ended up natively building a newer version of OpenSSL, as well as HAProxy, on the NAS itself, and installed it to a private prefix. That ended up working, but was largely unsatisfying. Even before this, I’d lamented being unable to run newer versions of some software (offlineimap, for one thing) on the NAS.

So I started poking around to see if anyone has done a large, unsupported upgrade on this hardware. I didn’t find any concrete instructions, but I did find some encouraging information. I found someone who had cataloged all the hardware of the device, and had upstreamed support for the board into the Linux kernel, and had noted that nearly all the hardware (save the front-panel LCD) is now supported by the upstream kernel. I found a reference on Debian’s ARM EABI port page that the ReadyNAS NV+ v2 is specifically supported by the upstream kernel.

WARNING

First off, a big disclaimer:

This is inherently risky, and you can very easily brick your NAS to the point where it will be incredibly difficult to recover it. I recommend you open it up and make sure you can get the serial console working before proceeding with any of these steps (there are instructions in one of the above links).

Also remember that, while it is possible to connect your NAS’s drives to a computer running Linux in order to assemble the RAID/LVM array to pull data off, you should have a backup of all data to be safe.

Kernel

The first step is to get a more modern kernel running on the box. Unfortunately the ReadyNAS’s stock kernel is compiled without kexec support, so we can’t experiment without overwiting the one-and-only copy of the bootable kernel on the ReadyNAS’s flash chip.

TODO: see if the stock u-boot supports USB booting and how to get that to work.

The flash chip is partitioned like so:

1dev:    size   erasesize  name
2mtd0: 00180000 00020000 "u-boot"
3mtd1: 00020000 00020000 "u-boot-env"
4mtd2: 00600000 00020000 "uImage"
5mtd3: 01000000 00020000 "minirootfs"
6mtd4: 06800000 00020000 "jffs2"

The first partition contains the u-boot bootloader, with the second holding environment variables that control u-boot’s operation. The third (uImage) holds the kernel, and the fourth (minirootfs) holds a small initial RAM disk that kicks off the boot process before turning control over to the main rootfs. The fifth partition, jffs2, contains

  1. First back up all flash partitions on the NAS: for i in /dev/mtd*; do sudo dd if=$i of=$(basename $i); done Be sure to copy the resulting files off to another computer for safekeeping.
  2. apt install gcc-arm-linux-gnueabi u-boot-tools screen lrzsz
  3. Grab kernel of your choice (I used 5.6.6; here’s .config), and build with: make zImage ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
  4. Make u-boot image for kernel: mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.6.6 -d /path/to/linux/arc/arm/boot/zImage kernel.img
  5. Extract the initrd file system image (from the backup of mtd3 created earlier): dd if=mtd3 bs=64 skip=1 | gunzip -c | sudo cpio -i (Strip the 64-byte uImage header, unzip, extract).
  6. Patch init to not try to load Netgear’s proprietary kernel modules (which are no longer needed): sed -i -e 's/insmod/ls /g' init
  7. Repackage the initrd: find . -type f >name-list && sudo cpio -o <name-list | gzip -9 -c >initrd.gz && rm name-list
  8. Make u-boot image for initrd: mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initrd -d initrd.gz initrd.img