I was indeed wondering if other ipq40xx devices had the same issue.
Just tried the EA6350 with 22.03.4 and it does not boot (22.03.3 does). I just got this router around the time of the start of this thread and the newer kernels have never worked so I've been assuming it's affected by same issue.
Just fetched the MR8300 snapshot r22549 and confirm that it still does not boot, if your build snapshot is different then can you confirm if this is the case and that some future cut will be integrating the patch as mentioned. The kernel sources for 5.15.106 are still showing as unpatched so I am assuming that an OpenWRT roll-out fix is being applied.
My bad, I was talking of building the snapshot on your own, since you have to apply the patch for yourself. The pull request hasn't followed yet.
Well at least it works with the patch. Let us know when the PR had been merged.
Any link to share ?
Fixing the issue or?
Cause if it is, then it should be backported to OpenWrt to fix those devices booting
Does the following address this issue or is it something else that we are waiting for?
I have now tried the latest r20125.
Same problem, router fails to boot.
The PR targets the next linux kernel, so the fix will not be applied to any of the existing broken branches. It should have been submitted as a general PR to correct all LTS streams, so there should not be a resolution from the mainline kernel tree anytime soon nor has it been integrated into the OpenWRT trees since a localized patch has not been created for all UBI based targets using MTD devices. Will need to scan for all impacted equipment using this driver as is currently being released into the 22.03.4 builds.
Unfortunately it does, and others will soon find out when attempting the upgrade to 22.03.4 from 22.03.3, unless notified that the outstanding issue is resolved. This should have been incorporated as a localized patch once the issue was reported about a month ago, but the team is waiting for the fix to make it downstream instead.
I am well aware of all that, my question is if that commit fixes things?
If so, then its easy to backport
No it's a separate problem. When upgrading, the other partition is flashed, but without any previous config. Hence it's not a real upgrade, and the systemp boots with default value. One must manually restore the config after.
Ouch, incoming bricked devices!
Let's hope the devs will post a global message about this in the 22.03.4 release note.
These 23.03.4 images should be pulled from the servers.
I compiled master with the patch and my EA6350v3 is now working. It looks like T4keT4ke did the same with an MR8300.
It's not really bricked as the other partition can always be used on the MR8300 (but it's no fun). Also the doc has a warning (for those who read the doc..).
Agreed, it was just a matter of fast speaking.
Fun fact : I rewrote the doc in january when the snapshots became available again, after updating kernel to 5.15.
Does anyone have a working snapshot at the moment or know how to build it?
Or should i rather wait for the fix.
I'm presently building from source code. It's rather long but it works. I have a custom build, and I'm awaiting for a build with default official config. I don't know yet how to include the patch, but I'm confidend I'll find soon enough.
Good news. A commit has been submited for solving both kernels 5.10 (22.03 snapshot) and 5.15 (master).
It may be active in the next daily release.
The fix does not correct the builds on 5.4.238 used in the earlier stable release, only the 5.10.x and 5.15.x cuts but leaves the 21.02.6 broken as well as 22.03.4. All stable releases should incorporate the fjx and then be re-issued in these stable branches. The feeling is if the build does not work, then so sad, if the build bricks it, too bad.