If the only problem is LuCI not loading properly, try clearing your browser cache. There may be incompatible old LuCI pages in the cache on the PC.
This part is huge...
14.07 is extremely old, unsupported, and has many known and actively exploited security vulnerabilities.
Upgrading to 19.07 or 21.02 gets you back into supported territory (although technically 19.07 will go EOL in the relatively near future), with up to date security patches, new features, and up-to-date offerings with the package manager (should you choose to use them)
If your issue is related to the stability of the firmware itself, 19.07 and 21.02 seem to be pretty solid for most devices. However, I don't know how many people are using your specific device, and per the comment from @bill888, there could potentially be some issues with that unit (but @mk24 points out that it could be browser based -- we'd need additional datapoints or experiments to know for sure if @bill888 's experience actually indicates any real issues)
If your situation is caused by failing hardware, though, you will be best served by replacing the unit.
Sounds like maybe going from 14.07 > 17.01 > 19.07 to start would be my best bet. And probably the lowest risk. I can see if that's enough for now at least. Then I can decide later if I need/want to jump to 21.02.
Sadly clearing browser cache in Chrome web browser for Windows does not resolve the problem. I've been opening new incognito windows throughout my testing.
I don't think I've come across any postings where LuCI stopped working after first reboot, starting 21.02.0-rc3 for other devices.
Update: If I sysupgrade from clean install of rc2 to rc3 and 'keep settings', LuCI in rc3 survives reboots. Will investigate tomorrow.
When you jump to 19.07, decide if you wish to stay with ar71xx images, or make big leap to using ath79 images (you can't keep settings when upgrading from older release such as LEDE 17).
As reported last night.
If I sysupgrade from 21.02.0-rc2 to a later release such as 21.02.1 and 'keep settings', I have observed LuCI survives subsequent reboots (until I reset the device to default OpenWrt settings)
I also observed when I back up the settings while LuCI survives reboots, and then restore the settings, I get 'LuCI Configuration interface' followed by "Bad gateway". WinSCP then refuses to connect until I reset the router to restore openwrt defaults.
I couldn't find any differences between the files in /etc/config. Only the ULA prefix in /etc/config/network differed.
21.02 seems to be snafu on MyNet N750....
I've put 19.07.8 ath79 image on the N750 and it doesn't exhibit the LuCI or backup/restore issues so far. I know 19.07.7 ar71xx image works reliably.
ath79 vs. ar71xx should not cause any material difference.
It is only about how the hardware is described to the OS.
(old style mach-xxxxxx.c in ar71xx vs. modern DTS in ath79)
Might be about the host ssh certs and the SSL cert for LuCI (for uhttpd daemon). Browsers (and SSL enabled tools in general) are sometimes really picky about connecting to the same host if the certs have changed during a browser session.
WinSCP (and PuTTY) gives a specific warning if it's cert-related.
Clearing browser or restarting incognito session with chrome wouldn't work after I performed a simple restore of settings. I didn't investigate the WinSCP issue.
Only way I could regain access was to reset OpenWrt to default settings on the N750.
Ideally require another MyNet N750 owner to verify whether there are indeed problems with the 21.02 images. I've not encountered any of these weird issues with other openwrt devices when using 21.02.
I had a weird problem on a device and noticed this forum link here when considering 21.02.2.
I had the followg installed on 19:
luci-app-wireguardsnmpdtcpdump
After upgrading to 21.02.1, I started having network issues when saving settings (e.g I would loose wireless, log errors on the partition, etc.). One error read off a blurb of a config file. 
Currently I have omitted those programs as a workaround.
I have another running default software now too - I don't see issues (I upgraded it to 21.02.2 already).
1 Like
This device failed.
- I could not login via LuCI (correct password brought you back to the login screen)
- after I SSHed to router and
rebootthe would not boot back up
I had to use the Emergency Room firmware recovery to downgrade to 19.07.9.
(Also, I don't recall doing this when I first switch to OpenWrt; but I had to use the Factory in Emergency Room, then flash again with sysupgrade after it booted. Otherwise it rebooted into the same unusable state - just FYI.)
1 Like
[ 11.310024] jffs2: error: (600) verify_xattr_ref: node CRC failed at 0x9b0128, read=0xfffaff7e, calc=0xced28f4a
[ 11.320345] jffs2: error: (600) verify_xattr_ref: node CRC failed at 0x9b0050, read=0xfffff7fb, calc=0xb925e3b5
[ 11.331096] jffs2: notice: (600) jffs2_build_xattr_subsystem: complete building xattr subsystem, 34 of xdatum (20 unchecked, 11 orphan) and 41 of xref (10 dead, 0 orphan) found.
[ 11.347925] jffs2: notice: (600) jffs2_get_inode_nodes: Node header CRC failed at 0x9b000c. {fdff,e77a,fd7ae77e,fdffe77e}
[ 11.360880] jffs2: notice: (600) jffs2_get_inode_nodes: Node header CRC failed at 0x9b026c. {fdff,e77a,fd7ae77e,fdffe77e}
[ 11.374001] mount_root: switching to jffs2 overlay
[ 11.381682] jffs2: error: (601) do_verify_xattr_datum: node CRC failed at 0x9b00dc, read=0xfdfef7ff, calc=0x21946102
[ 11.393535] overlayfs: upper fs does not support tmpfile.
[ 11.407995] urandom-seed: Seeding with /etc/urandom.seed
[ 11.514146] eth0: link down
[ 11.531531] jffs2: notice: (1) jffs2_get_inode_nodes: Node header CRC failed at 0x9b268c. {7600,ffff,00000044,a4ef223e}
From another device running 21.02.1. Can't recall if this was some of the relevant logs I saw before...(as it's still running, LOL).
I have experienced similar issues with MyNet n750 upgraded to 21.02.2. I started out by using the sysupgrade firmware to go from 19.07.1 to 21.02.2. It initially appeared to work properly but after changing some settings and rebooting a few times I was no longer able to web into it. I reset and flashed the router multiple times and invariably the web interface would stop working while trying to configure it, either it was unresponsive or it prompted with "Bad Gateway". My last attempt was to boot into "Emergency Room" and use the factory firmware, then sysupgrade. Thinking it might be related to the new LuCI interface and based on the release note for 19.07.9, I installed luci-compat and it appears that uhttpd-mod-ubus in included in the image. But that resulted in the same issues with the web interface.
I flashed it to back to 19.07 (19.07.9) using the Emergency Room and had no issues configuring the device.
2 Likes
I can report the same exact experience with my WD N750 on 21.02. I downgraded back to 19.07 and the issues have resolved.
2 Likes
Has anyone tried 21.02.3?
1 Like
I upgraded from 19.07.9 to 22.03.0 RC1 last night on my N750, kept settings.
It has been 24 hours, so far no signs of the SquashFS errors in the kernel log. I will keep monitoring, as previously the errors didn’t appear until a few days running on 21.02.01.
So far, so good.
1 Like
Did settings for 22.03.0-rc1 survive when rebooting the N750 ?
Yes, survived all reboots.
1 Like
Hmm, I maybe spoke too soon. Woke up this morning to no Internet, router is in a boot loop. The router was scheduled via cron to reboot last night, perhaps that reboot caused the issue. The router survived multiple soft reboot earlier in the week, unsure why this might be different.
The cause of this issue is very likely related to the previously reported SquashFS corruption problem, referenced here - and here.