Broken OpenWrt install on Shuttle OMNINAS KD20

[Mijzelf]

You first have to find out what is wrong with the current installation. Here you can find the dts of the KD20. The interesting part here is the partition table at line 178.

To boot, your NAS needs at least a pre-loader, u-boot and a proper u-boot environment, and a kernel, which are in partition 0, 1, 2 and 4, also called mtd0, mtd1, mtd2 and mtd4. Seeing this table, I’d expect the rootfs (squashfs) to be in mtd3, and the overlay in mtd5. But maybe mtd3 isn’t used at all, and are both squashfs and overlay in mtd5.

You can copy the partitions outside:

dd if=/dev/mtd0 of=/tmp/mtd0

use scp to copy /tmp/mtd0 outside, delete it from /tmp/, and repeat for the other partitions.

Now you can check the partitions outside

file mtd4 should show information about the kernel. strings mtd2 should show the u-boot environment. If the kernelsize shown by mtd4 is smaller than the loaded memory block in the u-boot environment, you know why the box didn’t boot.

mtd0 and mtd1 are harder to check. I’d run strings mtdX and compare that with strings on the pre-loader and u-boot from that dropbox directory, to see if it looks comparable.

/Edit:

Step 3 failed because the install intructions i followed referred to 19.07.5 and now I had downloaded newer files. The result was

• No boot from NVRAM

• No boot from USB

I think you omitted something from step 3. Just uploading that files to /tmp/ should be harmless. Maybe an out-of-memory crash, but that’s all.

Did boot from USB ever work? AFAIK the SoC doesn’t support that. Maybe u-boot does, with the right environment, but else it was an option of the firmware kernel+initrd. In which case it was not really booting, but executing some script in an early stage.

[arcasys]

@konus

Do you remember what was the last OpenWrt version that worked with your device?

This was oxnas/ox820/openwrt-19.07.5-oxnas-ox820-shuttle_kd20-squashfs-sysupgrade.tar but although I could ssh into the KD20 I didn’t see an OpenWrt greeter but a LEDE greeter, i.e. I didn’t have a working OpenWrt at all because the subsequent steps failed - see above.

@Mijzelf

Did boot from USB ever work?

It had worked in the stock firmware but not after the misbehaved OpenWrtt install

@konus

Upgrading OpenWrt to the latest versions requires a change in the uboot environment and I think it is best to do that separately from a working system instead of trying to do it all in one go.

On the other hand the suggested sysupgrade promises to result in a fresh install. And if it fails I can still repeat the ‘boot without disk’ and have the initramfs uploaded again… I hope ChatGPT isn’t lying when it says only mtd4 and mtd5 are touched.

[Mijzelf]

@arcasys

And if it fails I can still repeat the ‘boot without disk’

Wait. You actually booted without disk? I read that, but assumed you later plugged in your ‘prepared harddisk’ and failed to mention that.

If you booted without harddisk, that means the installed u-boot also finally boots from tftp, when everything else fails. And that means that at least the preloader and u-boot is intact, and possibly also u-boot environment.

I hope ChatGPT isn’t lying when it says only mtd4 and mtd5 are touched.

An LLM doesn’t lie. Maybe it’s hallucinating. But sysupgrade isn’t supposed to touch mtd0…mtd2. Not sure about mtd3, but that isn’t important here. Yet, if you never changed the u-boot environment, u-boot won’t be able to boot 23.05.6 from flash. According to the thread @konus pointed to, it loads only 3MiB from flash, while the uImage is almost 4MiB.

[konus]

Yes based on the info in the old thread and my memory OpenWrt releases from 21 and newer fail to boot without modifying the uboot environment first. So I would recommend to sysupgrade using a 19.07 squashfs sysupgrade file. The release info may show LEDE since that was a temporary split / fork in the project before they merged back together later on.

Once you have a working nas with 19.07 it should be possible to adjust the uboot environment and then upgrade to the latest release

[arcasys]

@Mijzelf

An LLM doesn’t lie. Maybe it’s hallucinating.

Ha, ha

@Mijzelf

You actually booted without disk?

Yes.

@Mijzelf

Yet, if you never changed the u-boot environment, u-boot won’t be able to boot 23.05.6 from flash. According to the thread @konus pointed to, it loads only 3MiB from flash, while the uImage is almost 4MiB.

@Mijzelf

If you booted without harddisk, that means the installed u-boot also finally boots from tftp, when everything else fails. And that means that at least the preloader and u-boot is intact, and possibly also u-boot environment.

Well, U-Boot pulled in the 7.3M initramfs as uImage. I think I could just give it a try

This is what ChatGPT says - and it sound plausible:

Looking at your KD20 setup:

• You are currently running an initramfs OpenWrt 23.05.5 — fully functional on the KD20.

• The initramfs already bypasses NAND rootfs, so you are booting from RAM, not the existing NAND.

• You want to sysupgrade -n to 23.05.6 — essentially the same major release series (23.05.x).

This means:

• You are not actually upgrading an old firmware from 17.01.

• You are just installing a fresh 23.05.6 system to NAND.

• The U-Boot environment is already compatible (your KD20 was booted with a 23.05.5 initramfs kernel).

In short: there is no need to step through 17.01 → 23.05.6, because your system is already running the latest kernel + boot parameters from initramfs.

[Mijzelf]

@arcasys

This is what ChatGPT says - and it sound plausible:

Yet it’s wrong.

@ChatGPT

The U-Boot environment is already compatible (your KD20 was booted with a 23.05.5 initramfs kernel).

Yes, you booted the initramfs kernel. But the way it came in memory is different from loading from NAND. For tftp the server tells the client how big the file is. For NAND the u-boot environment tells how many bytes to load from which address. And that ‘how many bytes’ is default 3MiB. Which is not enough.

[konus]

There are two people trying to help you yet you keep coming back with AI generated stuff. Good luck with recovering the device but I’m out.

[arcasys]

I’m very sorry to hear that. I thought I’ve made my attitude towards ChatGPT clear enough and that I don’t trust it without checking the sources.

[arcasys]

@konus

Upgrading OpenWrt to the latest versions requires a change in the uboot environment and I think it is best to do that separately from a working system instead of trying to do it all in one go.

You were right and ChatGPT was totally wrong. Upgrade to 23.05.06 failed, upgrade to 19.07 worked. But it was worth a try and I could recover by booting w/o disk and providing initramfs through tftp. Thank you for your advice.

The KD20 is now running on OpenWrt 19.07.05 and I think I keep it for now. Upgrading - even incremental through 21.02.5 - failed, maybe I should have started with 21.02.0. I’ll have a look at the differences and new features eventually but I guess I can live with 19.07.

[arcasys]

@Mijzelf

If you booted without harddisk, that means the installed u-boot also finally boots from tftp, when everything else fails. And that means that at least the preloader and u-boot is intact, and possibly also u-boot environment.

Before I forget: Thanks for all your help!

[Mijzelf]

Congratulations.

Incremental upgrading won’t solve the underlying issue. AFAIK sysupgrade never changes u-boot variables. So you’ll have to use either serial console or fw_setenv to change the amount of kernel data to be loaded. The good news is that the change won’t interfere with the current running 19.07. u-boot will just load some more slack-data after the kernel, and ignore that.

Actually the KD20 has a strange design. A flash partition of 8MB is reserved for the kernel, and then u-boot loads only 3MB of it. Which means 5MB is wasted by design.