Upgrade from Barrier Breaker 14.07 to latest 21.02 (WD My Net N750)

FYI. SquashFS errors persist on WD N750 running a December 7 2022 SNAPSHOT version, standard configuration and default packages.

What happens if you remove luci?

If there is an established dev who is willing to take a look at this issue, I would gladly send you an n750 with serial port attached.

What issue (specific to the N750)?

The most recent posts seem to imply it's an issue on multiple platforms.

BTW, I'm running 22.03.3 - it sysupgraded without issues. I'm using an image made using the Firmware Selector, without LuCI.

The squashfs errors on the n750 which persist in the latest builds.

See my post:

No squashfs errors when using an image that isn't too big.

  • Try luci instead of luci-ssl?

Thanks, I dont use Luci of any sort. Command line config only.

Then image size is OK, no errors.

Simply use the Firmware Selector to make an image without LuCI.

I'll give it a try, thanks.

1 Like

I finally was able to access this device. I installed an image without tcpdump, luci or luci-ssl. There are no errors thus far.

:notebook: It seems that changing to luci-ssl makes the image/free flash requirements for the N750 larger - and it's barely enough to fit a few configs.

This is the exact list of packages I add/kept on the Firmware Selector - for an 22.03.3 image without issues:

base-files busybox ca-bundle dnsmasq dropbear firewall4 fstools kmod-ath9k kmod-gpio-button-hotplug kmod-nft-offload kmod-usb2 libc libgcc libustream-wolfssl logd mtd netifd nftables odhcp6c odhcpd-ipv6only opkg ppp ppp-mod-pppoe procd procd-seccomp procd-ujail swconfig uboot-envtools uci uclient-fetch urandom-seed urngd wpad-basic-wolfssl kmod-wireguard wireguard-tools snmpd


EDIT - this machine has issues, the only difference between this and another is that the configs take more space:

Your JFFS2-partition seems full and overlayfs is mounted read-only.
Please try to remove files from /overlay/upper/... and reboot!
[   13.096778] jffs2: error: (544) jffs2_do_read_inode_internal: CRC failed for read_inode of inode 612 at physical location 0x22b41c

(When possible, I'll attempt an image without snmpd.)

On https://openwrt.org/toh/western_digital/my_net_n750 i read: "21.02, 22.03 and development snapshots do not work properly at this time. (Sep 2022)"

So: 21.01 will work? The main reason for the newer openwrt versions is that they support WPA-3.

So i can install OpenWRT 21.01 without any problems (the self-destroying behavior of all newer versions)

THank you very very much for your feedbacks :slight_smile:

Would you like me to reword the Wiki?

@bill888 and myself appear to have made the last edits there.

(I'd prefer to edit it AFTER you verify, not before - but you keep postong days/months later. Additionally, your statements always imply that you haven't installed a single firmware nor attempted.)

I'm not sure why you keep repeating your inquiry(s).

Are you experiencing an actual issue?

I think the best would be to buy a new device which is compatible to current versions.

But it's really difficult to find a smillar device that is a.) small and b.) has no ugly antennas..

(I just had installed the 21.x version on one device - it was running a long time [a few months], then, ony day, it has destroyed itself... then i was done some research and found that forum thread here...)

We discussed how to solve that issue. Did you?

:+1: OK sure - I agree that might be less of an issue for you to handle/phantom.

Purely a suggestion, of the 5 I have in use, I've replaced one for a Netgear WAX202. The only reason it's replaced is to handle ans upgraded 1Gbps ISP connection. Otherwise,the device was still OK.

Edit: The WAX202 needs flow offloading enabled for 800+ Mbps speed - something that was never made open source for the Atheros switch chips capable of it, additionaly, the device was chosen for [low] power requirements too - as I run it off mains power using a solar/battery system.

Would you like me to reword the Wiki?

It is not immediately clear from the Wiki, or even the discussion here and there and elsewhere just what the simplest way is when it comes to making an >19.07.10 image that will work reliably on the N750.

  • On the wiki there are links to default images for 22.03, and warnings they will not work.
  • In this thread the takeaway is to use an image without luci.
  • In the other thread, "small images" (without luci and other packages) are recommended.
  • In the bugreport, applying a PR and compiling with ztsd compressor support seems to be the preferred solution.
  • Also, jlpapple's discovery that an immediate EXTROOT build also works is floating around here and in the bugreport.

So yeah, it's not surprising people are confused.

I recall there once being a warning on the wiki that builds past 21.02-rc2 didn't work. As your results and Bradford's investigations strongly suggest there is some kind of kernel regression resulting in a locking error in the flash storage once a certain limit is reached, perhaps there should be a recommendation that firmware size should be less than SOME SIZE to work with necessary config space and no extra packages. Now both -rc2 and -rc3 are the same filesize at 5374270 bytes, but -rc1 was smaller at 5308734 bytes. Presumably whoever wrote that old wiki warning jumped from -rc1 to -rc3.

Personally, I used the Firmware Selector to make a 22.03.3 image without things like ppp, luci, dnsmasq, odhcpcd etc. (this is for a dumb AP) to get an image of 5243704 bytes. Using 428 1k-blocks in the /overlay, my longest uptime is 49 days, and I have not experienced squashfs errors over ~10 reboots.

However, when I added another ~300kb of text files to the router flash, squash errors popped up on reboot and I had to reflash.

1 Like

I should respond here for posterity. I am the same user who made this comment here https://github.com/openwrt/openwrt/issues/9085#issuecomment-1253919045 I have been reliably using https://github.com/attila-lendvai/openwrt-auto-extroot to generate a working image that would immediately create a external root on a connected USB device for both the WD My Net n750 and TP-Link TL-WDR3600 devices I own.

That project generates a special install that proceeds to setup a 'extroot' on the first USB drive it finds. Somehow this is quick enough to not trigger a "SQUASHFS" error and on proceeding boots it immediately boots from the USB drive. Once you are booting from the USB drive it seems to not trigger any further "SQUASHFS" issues.

This has been great for all of the random USB thumb drives I've collected over the years that have only been getting dusty. I should add that slower or poorly made USB thumb drives may not boot properly, a few USB thumb drives I have suffered this issue but once I had the right USB thumb drive it worked fine.