Installing Debian Jessie on a Netgear ReadyNAS 102

The procedure for installing Debian Jessie on the ReadyNas 102 is very similar to that detailed by Uwe Kleine-Koenig for the ReadyNas 104. There are a few subtle differences, which I document here.

I’m greatly indebted to Uwe and Martin Michlmayr, who patiently guided me through the hairier bits.

 __   __                     _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_ 
        | | | |___|  _ \ / _ \ / _ \| __| 
        | |_| |___| |_) | (_) | (_) | |_ 
         \___/    |____/ \___/ \___/ \__|


This procedure requires two hosts. One is the RN102, the other is a (Debian) Linux host (workstation). The latter is used to prepare everything to install Debian Jessie on the former.

On the workstation, the procedure first tweaks the Debian installer so it will run on the RN102. On the RN102 we then load this installer using FTP, accessing it from the RN102 boot loader shell. Next, we complete the installation, and copy a spare kernel to the workstation, just in case. Lastly, we save the Debian kernel to the NAND device.


First, get familiar with the boot loader, U-Boot.

To access the RN102’s Marvell U-Boot shell, remove the tiny grey sticker to the left of the Ethernet jack, and connect a serial cable to the UART pins. You only need the gnd (usually black) and RX (white) and TX (green).

Plug the other end, the USB connector, in your Debian workstation, and in a term, do:

screen -L /dev/ttyUSB0 115200

Used this way, screen will save everything it shows to screenlog.0. This is recommended, in case you need to share output with others.

An alternative for screen is grabserial.

grabserial -d /dev/ttyUSB0 -o /path/to/outputfile

Power on

Power on the RN102. If screen or grabserial on the workstation show gibberish, unplug the USB connector, and restart screen and or grabserial. It might take a handful of tries, NAS reboots and combinations of screen and grabserial together in separate terms, before you get legible output.

The two RN102 devices I toyed with, ran:

U-Boot 2009.08 (Jun 03 2013 - 09:07:26)Marvell version: 1.1.2 NQ


Linux-3.0.101.RN_ARM.4 (2015-06-30)

On the workstation, you can access the ReadyNas web management interface via a browser. It allows you to update the firmware. Result:

U-Boot 2011.12-gec25d27-dirty (Oct 26 2015 - 16:53:05) Marvell version: v2011.12 2014_T2.0p1


Linux-4.1.13.armada.1 (2015-11-21)

Keeping screen on all this while, you will by now recognise the booting process of the RN102. So you will know when to hit the any key, or rather, the ‘any-but-the-function-keys’ key, at the right moment:

Hit any key to stop autoboot:

After which you will see the U-Boot prompt:


Making the installer

On your workstation, you now need to make the Debian installer. The steps are identical to those described by Uwe, except for the third one, You need:

The current Device Tree Blob for the RN102 is subtly different from the dtb on the RN012 I worked on, but it is close enough for the installer and Debian installation.

To make the installer, do like Uwe does, except that you adapt the recipe to the RN102.

# apt-get install u-boot-tools
$ cat vmlinuz armada-370-netgear-rn102.dtb > vmlinuz-rn102
$ mkimage -A arm -O linux -T multi -C none -a 0x04000000 -e 0x04000000 -n "Debian Jessie armhf installer" -d vmlinuz-rn102:initrd.gz uImage-installer-rn102
# cp uImage-installer-rn102 /srv/tftp

Copy the uImage-installer-rn102 to the ftp server. No FTP server yet?

# apt install tftpd

Now copy uImage-installer-rn102 to /srv/tftp

Loading the installer

Switch to screen, showing the RN102. At the Marvell>> U-Boot prompt, type:

setenv serverip
tftp uImage-installer-rn102
bootm $load_addr

Where, of course, is the IP address of the tftp host. In my case, it is the workstation.

The Debian installer will boot, and you can go through the usual steps to complete the installation. Don’t worry if there is no way to mark any of the partitions as bootable.

The final step in the Debian installation will prompt you to hit and reboot. Don’t do that. Instead, hit and in the Debian installation menu scroll down to the “Execute a shell” option.

In the shell, enter the following:

mount --bind /dev /target/dev
mount -t proc none /target/proc
mount -t sysfs none /target/sys
chroot /target /bin/sh
apt-install flash-kernel

You next need to adapt /etc/flash-kernel/db

vi /etc/flash-kernel/db

and enter this:

Machine: NETGEAR ReadyNAS 102
DTB-Id: armada-370-netgear-rn102.dtb
DTB-Append: yes
Mtd-Kernel: uImage
Mtd-Initrd: minirootfs
U-Boot-Kernel-Address: 0x04000000
U-Boot-Initrd-Address: 0x0
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: yes

You can (but don’t have to) make two more changes.

In /etc/initramfs-tools/initramfs.conf, set:


and in /etc/initramfs-tools/conf.d/compress set:


After this, you can run

# update-initramfs -u

And if all goes well you will see something like:

update-initramfs: Generating /boot/initrd.img-3.16.0-4-armmp
DTB: armada-370-netgear-rn102.dtb
Installing armada-370-netgear-rn102.dtb into /boot/dtbs/3.16.0-4-armmp/armada-370-netgear-rn102.dtb
Installing new armada-370-netgear-rn102.dtb.
Installing armada-370-netgear-rn102.dtb into /boot/dtbs/3.16.0-4-armmp/armada-370-netgear-rn102.dtb
Taking backup of armada-370-netgear-rn102.dtb.
Installing new armada-370-netgear-rn102.dtb.
flash-kernel: installing version 3.16.0-4-armmp
flash-kernel: appending /usr/lib/linux-image-3.16.0-4-armmp/armada-370-netgear-rn102.dtb to kernel
Generating kernel u-boot image... done.
Flashing kernel (using 3194733/6291456 bytes)


Now, please get the UUID for the / partition, by looking at /etc/fstab

Just in case you run into trouble, the next steps help make a copy of the Linux kernel installed on the NAND. This copy you can access via FTP like you did the installer.

In screen, accessing the RN102, your newly created Debian host, do:

$ scp /boot/vmlinuz you@workstation
$ scp /boot/initrd.img you@workstatin

On the workstation, and in the location where you scp’ed vmlinuz and initrd.img, do:

$ cat vmlinuz armada-370-netgear-rn102.dtb > vmlinuz-rn102
$ mkimage -A arm -O linux -T multi -C none -a 0x4000000 -e 0x4000000 -n "Debian Jessie armhf rn201" -d vmlinuz-rn102:initrd.img uImage-rn102

On the workstation, copy uImage-rn102 to /srv/tftp .

In case of trouble, you can load this kernel using:

setenv serverip
tftp uImage-rn102
bootm $load_addr


We’re almost done. For the last step, you have to interrupt the start-up, to write the boot procedure to the NAND. First test the recipe, and if that succeeds, store it. So you need to reboot. Twice.

The first time, at the Marvell>> prompt, do:

setenv bootargs $console
nand read 0x2000000 0x200000 0x600000
nand read 0x3000000 0x800000 0x400000
bootm 0x2000000 0x3000000

Where the UUID number is what you recorded by looking at /etc/fstab Actually, this should work even without the root=UUID= line.

Some explanation

The syntax for nand read is:

nand read $address_in_ram $offset_in_nand $count_of_bytes

According to the RN102’s device tree, the uImage partition starts at 0x200000 and has a size of 0x600000. Hence

nand read 0x2000000 0x200000 0x600000

and not

nand read 0x2000000 0x200000 0x400000

In the latter case, you get a boot failure once the kernel gets bigger than 4 MB. Flash-Kernel will not detect that because the partition is 6 MB big.

If this works, reboot and, again, interrupt the start-up.

At the Marvell>> prompt, do:

setenv bootcmd 'nand read 0x2000000 0x200000 0x600000; nand read 0x3000000 0x800000 0x400000; bootm 0x2000000 0x3000000'

You’ll see:

Saving Environment to NAND...
Erasing Nand...
Writing to Nand... done

Now you’re done.

Bad blocks

If your RN102 shows bad blocks like this:

NAND:  (ID 0xf1ad)      128 MiB
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000000240000

and if your update-initramfs -u is followed by:

nand: nand_erase_nand: attempt to erase a bad block at page 0x00000480
mtdblock: erase of region [0x40000, 0x20000] on "uImage" failed

and lots of these:

end_request: I/O error, dev mtdblock2, sector 3496
Buffer I/O error on device mtdblock2, logical block 437
lost page write due to I/O error on mtdblock2

Then you need to proceed with care. See Debian Bug#813995. It is possible that “update-initramfs -u” will not correctly write an image to the NAND. You probably should not write to NAND at all in case of bad blocks, until this bug is fixed.

Very useful links