Install OpenWrt on Shuttle OMNINAS KD20

daniel · December 20, 2020, 11:33pm

Hi everyone!

I'm happy to see there is interest in the oxnas target and the KD20 specifically. I'm running that hardware myself ever since I ported OpenWrt to it years ago and I'm still happy with it.
The initial installation when still running Shuttle's stock firmware is quite tricky by now (given you want to avoid opening the device). This is because the image generated for that purpose grew larger than what the bootloader supports. Hence you need to build that intermediate firmware needed for initial installation yourself.
On a Linux buildhost, do the following

git clone -b lede-17.01 https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
cat >.config <<EOF
CONFIG_TARGET_oxnas=y
CONFIG_TARGET_oxnas_DEVICE_kd20=y
CONFIG_TARGET_BOARD="oxnas"
CONFIG_CLEAN_IPKG=y
# CONFIG_KERNEL_DEBUG_INFO is not set
# CONFIG_KERNEL_DEBUG_KERNEL is not set
# CONFIG_KERNEL_KALLSYMS is not set
# CONFIG_PACKAGE_block-mount is not set
# CONFIG_PACKAGE_fdisk is not set
# CONFIG_PACKAGE_kmod-ata-core is not set
# CONFIG_PACKAGE_kmod-crypto-crc32c is not set
# CONFIG_PACKAGE_kmod-crypto-hash is not set
# CONFIG_PACKAGE_kmod-fs-exportfs is not set
# CONFIG_PACKAGE_kmod-fs-ext4 is not set
# CONFIG_PACKAGE_kmod-fs-xfs is not set
# CONFIG_PACKAGE_kmod-lib-crc16 is not set
# CONFIG_PACKAGE_kmod-lib-crc32c is not set
# CONFIG_PACKAGE_kmod-md-mod is not set
# CONFIG_PACKAGE_kmod-nls-base is not set
# CONFIG_PACKAGE_kmod-scsi-core is not set
# CONFIG_PACKAGE_kmod-usb-core is not set
# CONFIG_PACKAGE_kmod-usb-ledtrig-usbport is not set
# CONFIG_PACKAGE_kmod-usb-storage is not set
# CONFIG_PACKAGE_kmod-usb2 is not set
# CONFIG_PACKAGE_kmod-usb2-oxnas is not set
# CONFIG_PACKAGE_kmod-usb3 is not set
# CONFIG_PACKAGE_libblkid is not set
# CONFIG_PACKAGE_libfdisk is not set
# CONFIG_PACKAGE_libmount is not set
# CONFIG_PACKAGE_libpthread is not set
# CONFIG_PACKAGE_librt is not set
# CONFIG_PACKAGE_libsmartcols is not set
# CONFIG_PACKAGE_libuclient is not set
# CONFIG_PACKAGE_libuuid is not set
# CONFIG_PACKAGE_lsblk is not set
# CONFIG_PACKAGE_mdadm is not set
# CONFIG_PACKAGE_opkg is not set
# CONFIG_PACKAGE_uclient-fetch is not set
EOF

make oldconfig </dev/null
make -j$(nproc)

That will give you a file bin/targets/oxnas/generic/lede-oxnas-kd20-factory.tar.gz which can be uploaded to the system update web interface of vendor's original firmware.
Once you have successfully flashed the intermediate firmware, you can now access it using ssh (assuming KD20 is directly connected to eth0 on your host):

# download up to date firmware to flash, to be safe get both sysupgrade and ubinized
wget https://downloads.openwrt.org/releases/19.07.5/targets/oxnas/ox820/openwrt-19.07.5-oxnas-ox820-shuttle_kd20-squashfs-sysupgrade.tar

wget https://downloads.openwrt.org/releases/19.07.5/targets/oxnas/ox820/openwrt-19.07.5-oxnas-ox820-shuttle_kd20-squashfs-ubinized.bin

ping ff02::1%eth0
# look for the duplicate response, that's the KD20 link-local IPv6 address and
# replace fe80::1234:56ff:fe78:90ab%eth0 below with the actual address you saw
# in the response

scp openwrt-19.07.5-oxnas-ox820-shuttle_kd20* root@[fe80::1234:56ff:fe78:90ab%eth0]:/tmp
ssh root@fe80::1234:56ff:fe78:90ab%eth0

# you are now connected to LEDE initramdisk system on the KD20
# fingers crossed, this should flash the kernel directly to NAND and write
# squashfs-rootfs to the rootfs UBI volume.

cat /proc/mtd
# I believe 'ubi' should be mtd4, but better check

# make sure it is detached
ubidetach /dev/mtd4
# re-format UBI and write rootfs
ubiformat /dev/mtd4 -f /tmp/openwrt-19.07.5-oxnas-ox820-shuttle_kd20-squashfs-ubinized.bin

# write kernel (and maybe rootfs again, but nvm)
sysupgrade -n /tmp/openwrt-19.07.5-oxnas-ox820-shuttle_kd20-squashfs-sysupgrade.tar

I've been using my own device in production ever since I ported OpenWrt to it years ago, and I guess for years I've been the only user. However, recently more people have been reaching out to me because there aren't many other choices left for that hardware...

It'd be nice if we can work together to document and improve the initial installation process and allow people to install without serial adapter or having to open the device (I've tried that method exactly once on a new device running stock firmware ~ 4 years ago).

daniel · December 22, 2020, 1:43am

update:
if you don't want to run the whole build process yourself, here is the ready file for download:
lede-oxnas-kd20-factory.tar.gz

daniel · December 23, 2020, 6:39pm

update: first of all, if you don't manage to find the IPv6 LL address via multicast ping you can connect the KD20 to your LAN and see on your router which IPv4 address it acquired through DHCP and then use that to upload files and connect via SSH.

Also sysupgrade -f -n ... won't work, for several reasons.
Hence, please do this in the shell after you have successfully UBI formatted the ubi MTD partition with the *squashfs-ubinized.bin file.

tar xf /tmp/openwrt-19.07.5-oxnas-ox820-shuttle_kd20-squashfs-sysupgrade.tar sysupgrade-shuttle_kd20/kernel -O | mtd write - kernel

That's essentially what sysupgrade should do to write the kernel to NAND in the way U-boot expects it. It should not through any errors and after that you are ready to reboot and OpenWrt 19.07.5 should come up. All future updates will work in the usual OpenWrt-way using sysupgrade (or uploading the *-sysupgrade.tar file to the System Update view of LuCI web interface).

TechGuy · December 23, 2020, 7:39pm

Hit a few bumps along the way, but that's how you refine a procedure!
openwrt is up and running!

Thanks!!!

daniel · December 23, 2020, 9:40pm

I've created a wiki page for the device documenting the initial installation process as @TechGuy and me have gone through it now:

ius · December 30, 2020, 4:54pm

Just to add some notes:

The 2017 brick reports occured because the bootloader does not read the full kernel/initramfs partition when booting (last argument)

loadr=nand  read.e 0x62000000 240000 280000
load=nand  read.e 0x60500000 840000 300000

Whereas the partitions are sized differently (first number):

mtd3: 00600000 00020000 "INITRD"
mtd4: 007c0000 00020000 "Kernel"

Instead of slimming down the (oversized) OpenWRT installation image, I patched u-boot to load the full partition size. This mitigates the risk of running into the same issue during an upgrade in the future.

Instructions provided as a reference for anyone looking to improve future robustness. Using the workaround by @daniel is the recommended way of installation. Do not attempt to reproduce unless you exactly know what you're doing.

If your loaders (stage1, u-boot) match SHA256

25ceb3f2f0f1b1e4f25c81bb7a85d19d8a7e5f3ca8b1e1d1d755db6fb2806131  mtdblock1.bin
9e7073ad846c715cc84bd8b0d3a09c809f1ecae8581a553aca3b676681f065a7  mtdblock2.bin

Applying this script should output two patched u-boot images matching.

e69da743f69f8ce08c8f37362896ddb95bd9de015db78bfeb6515570a101f9a3  uboot_patched.bin
b01411a337b7ec3fd2ae7bb6fb752e55dc12f3e6166edad453bb861ad0cbfe65  uboot_patched_padded.bin

Erase the u-boot partition and write uboot_patched.bin (without oob). The second checksum is provided for convenience (should match /dev/mtdblock2 on the vendor firmware after flashing).

Note: mtd numbering differs between stock firmware and WRT - WRT splits u-boot in mtdblock{1,2}.
My current stage1 & (patched) u-boot, as seen from OpenWRT:

# cat /dev/mtdblock0 | sha256sum 
25ceb3f2f0f1b1e4f25c81bb7a85d19d8a7e5f3ca8b1e1d1d755db6fb2806131  -
# cat /dev/mtdblock1 /dev/mtdblock2 | sha256sum 
b01411a337b7ec3fd2ae7bb6fb752e55dc12f3e6166edad453bb861ad0cbfe65  -

I cannot remember whether NAND oob data is used/relevant for the loaders. I think it's all 0xff for the original loaders. but by all means do verify..

Additional notes:

OX820 can boot from SATA. See: [MedionNAS] installation and recovery - creating a SATA bootable OpenWRT image might be useful.
I suppose adding the patched u-boot (and stage1) to the factory upgrade image would work.
The stage1/u-boot contained in the 'factory image' which used to be available on the net differ from whats shipped on the machine out of the box (slightly older - the ones I patched).

I don't have physical access to the machine I'm running OpenWRT on, nor any interest to work on any of the above. Just dropping my notes in case they end up being useful to anyone else.

daniel · February 23, 2021, 11:59pm

I'm working on generating "proper" ramdisk in uImage, like the vendor image does as well, not yet involving oxnas, but I will get there and re-do the installer image soon.

https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commitdiff;h=7cbb3c5bf8e18dc22f11b374026344b953ff28e5

bbaydar · March 19, 2021, 5:57am

Hello everyone,

Hopefully this will be helpful to someone else. I've just recently installed OpenWRT on my rather ancient KD20 (thank you all for getting it working!) and ran into the issue of the NAS crashing on large file transfers.

I was able to de-tune Samba enough so that the poor little thing isn't getting overwhelmed and choking to death. It does limit the performance to around 15-20MB/s though.

I haven't done super extensive testing to fine tune anything, I'm just glad it's working for now.

Changes I made to the smb.conf template are:

socket options = SO_RCVBUF=65536 SO_SNDBUF=65536 

aio read size = 0
aio write size = 0

use sendfile = yes

Other changes I made include removing the firewall modules, disabling IPv6, and turning off the bridge mode on the LAN port. None of those made a difference until I monkeyed with SAMBA options though so I don't think they're relevant. I'm mentioning it just in case though.

Happy to help answer any questions, or do more testing.

Thanks,

RoBo · April 9, 2021, 12:47pm

I have a Omninas kd20.

I uploaded firmware :
lede-oxnas-kd20-factory.tar.gz
from :

Conforms to the Openwrt instructions.
This is the "snap" version. Something went wrong.

After rebooting the device, I logged in as root,
but I couldn't do any further installation and configuration.
The openwrt directory is missing, missing wget, opkg.
I admit that without them my knowledge of Linux is there
insufficient to deal with the problem.

frollic · April 9, 2021, 12:56pm

you could try to (win)scp the upgrade tar & bin to the device, instead of wget:ing it from teh intarweb.

latest stable version is at https://downloads.openwrt.org/releases/19.07.7/targets/oxnas/ox820/

RoBo · April 9, 2021, 2:25pm

I uploaded it to the / TMP folder
shuttle_kd20-squashfs-sysupgrade.tar
shuttle_kd20-squashfs-ubinized.bin
from the page you specified.

After restart, the LED blinks - a sound is heard - after a few seconds the LED goes out.
I did something wrong?

frollic · April 9, 2021, 2:31pm

if you didn't write the rootfs, as in the instructions, then yes ....

RoBo · April 9, 2021, 2:34pm

eeeehhh So what now ? What are my options?

frollic · April 9, 2021, 2:38pm

serial console, as shown in the photo in the bottom of https://openwrt.org/toh/shuttle/kd20

you could consider upgrading the u-boot on the kd20 when/if you get the serial cable.
by doing so, you can set it up so you can communicate with it over LAN, even before linux have booted (using nc/netcat/netconsole), or try to boot from USB.
That would make it pretty much unbreakable.

https://forum.doozan.com/

tmomas · April 9, 2021, 2:48pm

Why have you flashed a 17.01-snapshot, when 19.07.7 images are available?

Edit: Answering myself: Because the installation instructions on the devicepage are still based on 17.01. And the reason for 17.01 is given in https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b0b7f2b8f3a6bba4c2e0a08b700d8522332aecd3.

frollic · April 9, 2021, 2:57pm

should be solvable by upgrading uboot, but that might not be for the faint hearted
and you still need the <4MB file to do it, unless you've got serial console set up.

RoBo · April 9, 2021, 3:21pm

Can I try to boot from usb at this point ?
I have to buy serial cable first ?

frollic · April 9, 2021, 3:26pm

no, USB boot would only be available after an uboot upgrade.

You don't need a serial cable, but an USB TTL serial port adapter, like

there are cheaper ones, but whatever you get, it needs to be for 3.3V.

RoBo · April 9, 2021, 3:32pm

I think this will allow me to use Debian? Correct me if I'm wrong.

frollic · April 9, 2021, 3:34pm

that too, yes