eeeehhh So what now ? What are my options?
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.
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.
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.
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.
I think this will allow me to use Debian? Correct me if I'm wrong.
that too, yes
This is what I will do. Thanks to this, I will be able to record stream from the IP camera at a higher resolution. You helped me a lot. THx frollic
I noticed the thread mentions uboot from 2015, check if you can find a more recent one in other posts at doozan. The ones from 2017 might have additional features.
I'm seeing this thread to late I'm afraid but the mistake was this action:
you should have done
as that would have resulted in successful upgrade to 19.07.7.
I'm still using my KD20 every day for more than half a decade by now and I can confirm that recent OpenWrt works fine on it, with the original bootloader.
You should be able to recover by writing kref's SATA SPL and u-boot images to the first SATA drive (in case that's easier for you than wiring up serial)
We do actually have a complete working build of U-Boot 2014.10 in our tree, that is already good enough to load everything from UBI and overcome the limitations of the vendor loader as it can be used relatively risk-free as a 2nd-stage loader without replacing or patching the vendor loader.
However, as things now also work almost equally well with the vendor loader, I removed that 2nd-stage loader again as installation is much easier if the vendor loader can directly start OpenWrt (which is not a problem, even with the limitations of the stock loader -- only the initramfs used for installation grew to big...).
Other people have managed in the meantime to patch the stock U-Boot. Replace it entirely is very hard and I never dared as I wouldn't know how to recover if that goes wrong, no JTAG exposed, other recovery methods may exist (using serial like on kirkwood or even USB) but they are undocumented. While that would be the most beautiful approach, it requires quite some work as the burned-in ROM loader of the SoC once again got size limitations which would not allow for modern U-Boot loaded directly, hence would need SPL, ...
Thanks for clearing everything out. However, I don't see what has been done wrong. In your upgrade steps you posted in this thread in december 2020, you state that the kernel should be written using 'sysupgrade...'. Later on you update it toward 'tar....'.
Now I see that RoBo has used your updated instructions, but you indicate that was wrong.
Also the guide on https://openwrt.org/toh/shuttle/kd20 indicates using 'tar...'.
What am I missing? Why should he has sticked to the sysupgrade instead of your latest advise? Reason for asking: I have a KD20 I want to upgrade to OpenWRT and your guide is very clear, except for this: I don't get the difference nor what the mistake is.
Sorry, my bad, it's just too much stuff to remember everything (which is why we have that wiki after all). You did right and we should figure out why it didn't work, as it did for other users before and I'm sitting next to a KD20 running recent snapshot.
On the oxnas devices replacing u-boot is a low risk endeavor as if it fails you can always fall back to booting from a SATA drive set up with https://github.com/kref/u-boot-oxnas. SATA boot has priority and it doesn't depend on the installed u-boot.
Hi RaylynnKnight, Thanx for pointing out. I already found that site, but I didn't find any instruction how to build and install this for the KD20. Or did I miss something? I think I am not an noob, but not that experienced to do this with full confidence of succeeding and not being stuck with a brick (my house has been build, don't need another brick, just doesn't fit ). On the other hand: I want to upgrade the KD20 since it's software is very much outdated. Even if it isn't that fast, it is a nice NAS.
I followed your instructions and things are working fine. However: I noticed a slight point to improve in your instructions. You mention to 'ubidetach /dev/mtd4' but this has to be 'ubidetach --dev-path /dev/mtd4'. Afterwards, everything is working fine.
Some additional info may also help:
- after installing your updated software: no UI is available (if someone would be looking for it as I did: it's not there!)
- installing the new software has to be done from another computer toward the KD20 (not from the KD20 towards another one... I tried it, doesn't work ). On that computer one does the wget since it's not on the KD20. Therefor: scp is needed to place it on the KD20.
After these steps have been done: it's fine for now! Thanks a lot!
1 silly question: upgrading to a newer version? Is that as easy as: wget-ing both files (*.tar and *.bin), scp them over, ubidetach, and tar... ?
Best regards, H.
OpenWrt release images (eg. openwrt-19.07.7-oxnas-ox820-shuttle_kd20-squashfs-sysupgrade.tar) do come with the LuCI web-ui preinstalled, just development snapshots don't.
Yes, you will need to upload the image via SCP on initial flash for the first time after having flashed the 17.01 factory image. Once you flashed more recent OpenWrt (manually, as described in the guide), every future upgrade can be done using
tar format is also accepted by OpenWrt's sysupgrade tool as well as when uploading upgrade via LuCI UI)
Thx again. System is up and running fine until now. Since it was a RAID1, I tried to get it up as RAID1 again. I am able to get both discs syncing, they are reported as RAID, etc. However: after a reboot, the RAID is gone. I am not able to get it persistent after a reboot. Right after the reboot I have to run:
mdadm -v --create /dev/md0 -l1 -n2 /dev/sda1 /dev/sdb1
and everything is working again. Both HDD discs are visible in the UI but the RAID disc (MD0) indicates that it is not present. A 'cat /proc/mdstat' also shows there is no raid config.
The steps I took:
fdisk /dev/sda (and sdb)
created DOS partition ('o')
created new partition, primary, etc.
changed filesystemtype ('t') to Linux raid autodetect ('fd')
write config ('w')
then created RAID config:
mdadm -v --create /dev/md0 -l1 -n2 /dev/sda1 /dev/sdb1
md0 : active raid1 sdb1 sda1
1953381440 blocks super 1.2 [2/2] [UU]
[>....................] resync = 0.0% (446016/1953381440) finish=583.7min speed=55752K/sec
bitmap: 15/15 pages [60KB], 65536KB chunk
UI now shows it is present. Then mounted to /mnt/raid
UI shows /mnt/raid as mount point for /dev/md0 (and 1.8TB is available).
then rebooting drops the config.
Same steps and in the UI 'save & apply' drops the config after a reboot.
Same steps but in the UI 'generate config' and then 'Save & apply' drops the config after reboot.
Do you have any idea how to make it persistent? Have been searching but can't make it persistent.
Recently people added some UCI configutation for mdadm, it's in
If there are no array defined there, auto-detection on boot will just work.
Ie. you have two options:
/etc/config/mdadm to match your RAID setup
b) remove default array from
/etc/config/mdadm and rely on auto-detection