I think adding a note about the dangers of factory reset (i.e. it wiping the firmware) would be the next best thing to having a firmware auto installer package.
1 Like
Has anyone had success in getting the 10G ports to work appropriately in 2.5G? I mean expected data rate too, not just the negotiation.
Weird thing is that stock FW doesnt allow 2.5G as far as I can tell but MAC certainly supports it, but I am not sure that its changing the link between AQR and MAC properly
Well, technically, my 10G link between my 301W and (also QNAP) NAS has an effective approximate throughput of 2.5Gbps 
But that's more down to the current software limitations (some bits of NSS that enable hw acceleration haven't been ported because the original Qualcomm code is crap, at least by my understanding).
After flashing a build from OpenWrt master, I just noticed that all settings (password, network, mwan3, openvpn) are all lost after a reboot. It seems the router is restored to default after a reboot. I also observed that the reset button is missing in Backup/Flash Firmware->Restore section as shown below
I rolled back to previous firmware built from robimarko's branch and every looks good again, I have tried re-flashing using LUCI or sysupgrade -n, I get same result all the time. The firmware build from OpenWrt master causes settings to be lost (back to factory default) after a reboot.
Your help/suggestion will be appreciated.
I noticed that too and it took me a while to find the reason.
Since commit https://github.com/openwrt/openwrt/commit/bd0f9d8ffcd1dc169fb66f9d7ddb335abbe49d37
fstools doesn't mount the ext4 loop device any more as overlay but instead the mmcblk0p9 (which is also named "rootfs_data")
[ 7.036343] EXT4-fs (mmcblk0p9): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
[ 7.038453] mount_root: switching to ext4 overlay
df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 12.0M 12.0M 0 100% /rom
tmpfs 434.3M 1.4M 433.0M 0% /tmp
/dev/mmcblk0p9 2.0G 1.5M 1.8G 0% /rom/overlay
overlayfs:/overlay 2.0G 1.5M 1.8G 0% /
tmpfs 512.0K 0 512.0K 0% /dev
That means loosing the entire config.
There are 2 workarounds at the moment:
- revert that commit
- add "fstools_ignore_partname=1" to the uboot env bootargs (we have no CMDLINE_OVERRIDE at the moment for ipq807x AFAIK)
fw_printenv bootargs
bootargs=ttyMSM0,115200n8 fstools_ignore_partname=1
[ 7.029253] loop0: detected capacity change from 0 to 1048576
[ 7.091037] loop0: detected capacity change from 1048576 to 1024384
[ 7.122096] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
[ 7.123848] mount_root: overlay filesystem has not been fully initialized yet
[ 7.134565] mount_root: switching to ext4 overlay
df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 12.0M 12.0M 0 100% /rom
tmpfs 434.3M 1.4M 433.0M 0% /tmp
/dev/loop0 458.5M 710.0K 428.8M 0% /overlay
overlayfs:/overlay 458.5M 710.0K 428.8M 0% /
tmpfs 512.0K 0 512.0K 0% /dev
Other eMMC devices could be also affected. And all snapshot images build after that commit are gonna break the device.
2 Likes
Lovely..... just waiting for that fking hell -.-
I guess, reverting it for now is a must, cause there will be other devices as well.
yep the only way... I have to contact that ipq806x user about this
some ipq806x devices already have a bootargs-override config:
So this isn't completely new
problem is that we have no way to understand devices that suffer from this...
I think this doesn't depend on the device, but only if there is at least one rootfs_data partition on the eMMC. fstools finds that instead of using the loop device.
sure I can test a patch
And the use of the loop device was wrong from the start but nobody notice that since the partname parsing was broken all along...
Well no, using loop device is what we always did for eMMC/SD devices
1 Like
LGTM, that fixes the issue
can I add your tested by tag?