Mittwoch, 10. September 2025, 01:15 UTC+2

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

1

Samstag, 2. November 2019, 16:51

OpenWRT 18.06.4 on an ICY BOX IB-NAS-4220-B

Hello,

Firstly I'd like to say its been a decade since I was last active here and it's really nice to see it still going! Lots of thanks to HWguru for patiently resuscitating various NAS1000's I had back then, luckily they're all long gone!

I've been handed a NAS4220B recently which had the original (and latest) ICY BOX firmware on it of 2.6.3.2-20090424... but I wanted to put OpenWRT on it (larger list of packages, newer kernel, etc...).

Luckily they provide a file (filename sysupgrade-ib4220b.tar.gz - not to be confused with an *actual* 'sysupgrade.bin' formatted file) that is compatible with the original ICY BOX firmware web based upgrade screen which you can get from... https://downloads.openwrt.org/releases/1…gemini/generic/

A progress bar appeared and it froze at around 78%, so I gave it a couple of hours to be sure... then manually powered it off/on. Hurrah! the LuCI interface was waiting for me on 192.168.1.1. Must have worked despite the 78% !

Things I've noticed so far however are...
  • Don't try to swap the LAN (i.e. eth0 which by default is alone in it's own bridge called br-lan) from static to DHCP Client. By the looks of things they forgot to to enable 'CONFIG_PACKET' in the kernel so things like DHCP doesn't work. This seems to have been fixed in a commit 2 weeks after that download was built, so in theory a '18.06.5' version or even a '19.x' version will have that fixed.
  • No matter what I've tried I've not been able to find a package/technique that will allow me to read the temperature data from the temperature sensor that is clearly inside the case (on a little wire)... and the fan seems to start/stop on it's own (presumably based on the readings of the sensor). My conclusion is that this is possibly fully automated and not something that is/can be exposed to the OS/kernel? Let me know your thoughts.
  • It doesn't seem to support 'sysupgrade' (i.e. supply a file ending 'sysupgrade.bin' via the CLI command 'sysupgrade' or via LuCI... and it'll magically update using that file). Which is a little insane given how it *does* support a similar style of upgrading from the original firmware! Instead it makes reference to upgrading manually.

And it's that last point I mostly wanted to talk about. Presumably the separate bits of hddapp / rd / zImage are meant to be copied/imaged over to different partitions/areas somehow?

Has anyone had to manually upgrade the firmware of a 4220B around here? What steps would this generally be, the OpenWRT wiki is lacking :S

I'm trying to anticipate for when the next version comes out.

Other than those niggles, it seems to work just fine.
Thanks

Steven

2

Sonntag, 12. Januar 2020, 19:52

RE: OpenWRT 18.06.4 on an ICY BOX IB-NAS-4220-B

I have installed 19.07 stable on a ib-4220.
Boot the nas as normal. When it is booted, attach the serial to usb adapter and connect using a terminal adapter 19200/1N8/flow control off (the nas wont boot if you connect the serial adapter before starting it from a cold boot).
Reboot from console and press ctrl+c at the boot menu.
You get this:

Boot Menu==============================================================================
0: Reboot 1: Start the Kernel Code
2: List Image 3: Delete Image
4: Create New Image 5: Enter Command Line Interface
6: Set IP Address 7: Set MAC Address
8: Show Configuration F: Create Default FIS
X: Upgrade Boot Y: Upgrade Kernel
Z: Upgrade Firmware A: Upgrade Application
R: Upgrade RAM Disk

=> Select:

Download the openwrt firmware and unpack it to a tftp server, you should get 3 files hddapp.tgz rd.gz zImage.Flash the kernel with Y and point it to zImage on the tftp server.
Flash the Application with A using the hddapp.tgz from the tftp server.
Flash the ramdisk with R using the rd.gz from the tftp server.
You should see a succefull flash for the 3 files.
Press 0 to reboot and thats it.
I am having issues with the latest stable 19.07.0, release and the ethernet driver:
I get this as soon as I start to generate trafic.

root@nas4220:/# [ 211.284791] gmac-gemini 60000000.ethernet: could not find mag
[ 211.321683] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.358345] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.394969] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.431589] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.480735] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.517370] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.554015] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.590638] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.627260] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.663887] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.705118] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.858979] gmac-gemini 60000000.ethernet: could not find mapping
[ 211.895616] gmac-gemini 60000000.ethernet: could not find mapping
[ 212.079182] gmac-gemini 60000000.ethernet: could not find mapping
[ 212.184915] gmac-gemini 60000000.ethernet: could not find mapping
[ 213.417049] gmac-gemini 60000000.ethernet: could not find mapping
[ 215.193682] gmac-gemini 60000000.ethernet: could not find mapping
[ 215.784722] gmac-gemini 60000000.ethernet: could not find mapping
[ 218.609603] gmac-gemini 60000000.ethernet: could not find mapping

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »oliv75« (12. Januar 2020, 19:57)


3

Mittwoch, 6. Januar 2021, 08:16

Hi
There seems to be none of those 3 files (hddapp.tgz rd.gz zImage) published on openwrt.org since after version 18.06.9 ( https://downloads.openwrt.org/releases/1…gemini/generic/ ).
1) How did you get them?
2) haven't you encountered a problem downloading hddapp.tgz using Red Boot Menu (such as the shown below)?

==============================================================================
0: Reboot 1: Start the Kernel Code
2: List Image 3: Delete Image
4: Create New Image 5: Enter Command Line Interface
6: Set IP Address 7: Set MAC Address
8: Show Configuration F: Create Default FIS
X: Upgrade Boot Y: Upgrade Kernel
Z: Upgrade Firmware A: Upgrade Application
R: Upgrade RAM Disk

=> Select: A

1 : Download by X-modem
2 : Download by TFTP
ESC: Return

==> Select: 2
TFTP Server IP Address: 192.168.0.3
Image Path and name(e.g. hddapp.tgz): hddapp.tgz

TFTP Download hddapp.tgz from 192.168.0.3 ....

Successful to download by TFTP! Size=6292480
File is too large!

========================

The problem with my version of Red Boot bootloader is that the "Size=6292480" (and "File is too large") is always shown for bigger application file sizes:
- for OpenWRT 15.05.1, where the actual hddapp.tgz size is 7995392
- for OpenWRT 17.01.7, where the actual hddapp.tgz size is 10616832
- for OpenWRT 18.06.0, where the actual hddapp.tgz size is 10525970
- for OpenWRT 18.06.8, where the actual hddapp.tgz size is 10618342

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Sergio« (6. Januar 2021, 14:53)


4

Sonntag, 24. Januar 2021, 20:56

Hi Sergio,

you have to unpack the firmware image like this from Linus Walleij, one of the developers from open wrt for the ICYBOX:

Zitat

I just extract the firmware files:
tar xvf openwrt-gemini-storlink_sl93512r-squashfs-factory.bin
then I flash
hddapp.tgz
rd.gz
zImage

I found it here: https://patchwork.ozlabs.org/project/ope…ro.org[/email]/

Regards Hendrik

5

Donnerstag, 29. April 2021, 12:22

Hi Hendrik ! Thank you so much! This is exactly what I needed.
Such file extraction also works fine with the latest stable release 19.07.7. I succeeded to install it.
Best regards
Sergio :)

6

Sonntag, 21. November 2021, 17:52

Hey,

So I've finally found the time to look at this again, much MUCH later!

It would seem that the latest OpenWRT 21.02.1 does not work on this device. The squashfs version just hangs on boot up and the ext4 version can't be used as the bootloader claims it is too big to write.

Have written it all up on the OpenWRT bug tracker... it mostly talks about the squashfs build but look at the comments for information on the ext4 build issues... https://bugs.openwrt.org/index.php?do=details&task_id=4137

Also I found the pin out for the internal serial connection at this site (use the Wayback Machine if it ever goes offline)... http://hled.narod.ru/index/0-7

I'm interested in knowing if it might be possible to run the ext4 version from a USB pen plugged into the back of the device (as it has a female USB Type-A port at both the front and back). Thus there wouldn't be any issues on how big the filesystem and operating system is. However I don't *yet* know how I'd make the bootloader boot from that instead... if anyone has any thoughts then I'm all ears!

Thanks, Steven.
Thanks

Steven