Adding OpenWrt support for QNAP QHora-301W

I bought a Fritzbox 4060 to test 2.5Gbps with my actual FTTH plan (2.5Gbps Down /1Gbps Up) and I am able to reach something near 2.5Gbps with the Fritzbox while I cannot reach that speed with the QNAP.

I see that the negotiated speed is 2.5Gbps on the WAN port (10g-1)

root@OpenWrt:~# ethtool 10g-1
Settings for 10g-1:
	Supported ports: [ ]
	Supported link modes:   100baseT/Half 100baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  100baseT/Half 100baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 2500Mb/s
	Duplex: Full
	Port: Twisted Pair
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Link detected: yes

And also I can see the same from the ONT (of course)

Any suggestion?

I'm getting an error here on the sysupgrade with squashfs,

[  224.378788] stage2 (2800): drop_caches: 3
Wed Mar 22 00:11:29 UTC 2023 upgrade: Switching to ramdisk...
Wed Mar 22 00:11:30 UTC 2023 upgrade: Performing system upgrade...
/lib/upgrade/do_stage2: line 38: losetup: not found
Failed to detach all loop devices. Skip this try.
[  225.961601] reboot: Restarting system

1e27d91cfee25e9b3a15499c0470cc45 openwrt-ipq807x-generic-qnap_301w-squashfs-sysupgrade.bin

Do a search on here, seems people have been getting this error for years.

Regarding a fix for losetup, is all that's needed to fix this error is just patching this file,;a=blob;f=target/linux/ipq807x/Makefile;h=539d930ce35e7b3827cf4b031124bb38e21ce843;hb=bd17683261e1dde1fdd4223745852de1ce8cfc89#l14

Not needed, losetup is a device specific package

The error you're describing can only happen during sysupgrade from an initramfs image from a multi-device build (like OpenWrt official builds)

This is due a limitation of the build system that doesn't take device-specific package into account.

Either build your own QNAP image (single device build includes device specific packages) or install losetup in the running initramfs image.

Sure, there are lots of ways to skin the cat but that's a horrible user-experience. If single-device builds include device-specific packages, why can't the official build system make a single device build for ipq807w? What percentage of OpenWRT users have made their own build?

And, what's the path to being supported here? Will this device be officially supported, and if so -- will users have to make their own build?

1 Like

If the device in included in the OpenWrt code, then it's officially supported.
If there is a problem with OFFICIAL OpenWrt builds, open an issue to see what can be done.

Just to clarify.

The mentioned limitation only applies to the initramfs-image that is used during the initial install. And I already supplied 2 workarounds how to deal with it during the install.

The sysupgrade image itself contains all the device-specific packages, that means after a successfull install sysupgrade works fine.

And the device is official supported.


I ended up building an image from Bitthief and re-flashing all 3 QNAP devices (took longer than expected), due to learning curve, work and initially 2 devices would not Sysupgrade but got their in the end.

I have both HW and SW offloading enabled and while i don't see a CPU being maxed out, I've not seen a major improvement in throughput.

@rmandrad you mentioned a bunch of tweaks / settings that have helped you, can you share what you have done on top please.

What is now the best way to test ? IPERF3 is single thread are there other test I should try ?

The issue is the initramfs image doesn't have the sufficient tooling to do the flash. I've never had that experience with other OpenWRT "supported" images. I always assumed support meant that there was a documented path to operation using built images, not that I could build them myself. But I could simply be wrong on that, and I've just never used such a device until now.

Is EXT4 kmod required as well?

Cause, if not then I would just simply ship losetup as the target default package as there are more and more boards requiring it for installation and we are not dealing with a target that has low storage


Yes, ext4 is used for the loop device.

In addition e2fsprogs would be also required to format the loop device during sysupgrade.

So we would need losetup, kmod-ext4 and e2fsprogs as target default packages.

The good thing is, we already have 2 emmc based devices in ipq807x who would benefit from that change.

1 Like

Have you by chance measured the size difference?

kmod-ext4 286kB
losetup 43kB
e2fsprogs 193kB

So we're arguing about <1mb on transient image loaded into flash, used on a device with 1 GB of flash. I love the internets.

But let's ignore the absurdity for a second. Why doesn't the openwrt build system use the same build path to build an initramfs image that a Makefile would use to target a single image? In other words, what is the advantage of having two ways to make the initramfs image? If we can just use Make and get a working image, what is the advantage to maintaining the other way to build an initramfs image that doesn't account for device specific dependencies?

It's not just 1MB on an image loaded into RAM, but also 1MB of packages that would be shipped but never used by the 32MB NOR device that we support as well, that is the issue.

There are no 2 ways to build an initramfs, but there is a limitation when you are building with:
then only packages that are selected with * so built-in are included as there is only one kernel with initramfs being built for the whole subtarget thus DEVICE_PACKAGES is ignored.

Now, everybody is free to try and rework the build system to allow building kernel+initramfs per each device.

I have no experience with firmware development, so I will just point out the following video (and its indicated resources) that perhaps someone already knew. If not, I hope it will be useful:

That is not openwrt in the video -> not relevant here.

Excuse me, but if you go to minute 9:35 after he has done the whole procedure, the interface of the installed firmware is that of OpenWRT (and it is also clearly indicated). But maybe I'm missing something.

1 Like

what that guy is doing is fundamentally different from what the official docs and everyone here is doing. he is connecting to ssh directly without ever loading an initramfs image. then he's manually flashing the rootfs and kernel. cool. then he flashes the 10gb firmware. this may work with openwrt, i would only feel comfortable if after his kernel and rootfs flash, you could flash over them with a new nightly snapshot.