Booting into the recovery went fine and I uploaded the firmware file from OpenWRT's firmware selector, openwrt-22.03.4-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb. LuCI didn't give any warnings for the firmware file. The device rebooted and never came back up; I just have a blinking light now.
Has anybody else had issues with this? I'm unsure of what the problem is or what the recovery steps should be. It seems it might be related to the kernel as I haven't had success in getting it to boot into recovery mode with the reset button. I don't have a serial cable on me so I'm not able to provide diagnostic logs.
As warned, the higher capacity UBI based MTD devices will be affected, just that all known units has not come out of the woodwork since the inventory is not complete. That refresh of the stable trees are starting to sound real good by now, but the devs are dragging this out beyond sensibility. Pull the 22.03-SNAPSHOT recent build that is known to correct the fault and the matter is closed.
Unfortunately, without knowing those who are responsible for managing the issue, and being under the impression that development teams review the forum postings, the depth of the issue and rapid resolution suggestion has gone unacknowledged. The team may be headstrong on fastracking ahead to the future 23.x release instead of cleaning up the mess the bug has caused.
I surmise that speculating on v23 would be just as fruitless. I'm glad I understand now - that you're just guessing and prognosticating.
Thank you for clarifying.
Those who have accounts might read - but how would they know to look for your specific posts raising issues - especially when you've never created a topic for the problem (as I've only seen replies to others' postings)?
From the Wiki:
Perhaps - you could create a Original Thread in the "For Developers" section regarding the issue - so it can be discussed, models listed, etc.?
E-Mailing the developer list is also a good option
Perhaps in the email and new thread - you could even link a lot (or all) of the 34 posts/replies (i.e. the total as of the time of this post) that you've made as references. I think that might help a lot.
Same here. In fact I've updated twice, first one the day of official release, then second one a week later to pick up the libopenssl update. No issues at all, the workstation I'm typing this on is connected through the RT3200's 5G radio...
The reference was your wiki posting, however, the bug was originally reported by @badulesia for the MR8300 and a trouble ticket was generated. During the investigation of the changes in the kernel sources for the last known good build to the failure, it was traced back to the UBI code in the MTD driver. Discussions on kernel.org also highlighted the fault in the code change and a suggested workaround was proposed. No PR was filed with the current mainline streams and only seems to have been generated for the NEXT kernel. That raised the severity of the issue since a fix would not be forthcoming anytime soon and the number of devices that would be impacted was covering a larger number of targets since the code is not specific to only his trouble report. Plus it spanned several long term supported trees used by OpenWRT. The conversation with @badulesia suggested three possible ways to rectify the problem, eventually adopting the second approach. Shortly thereafter, the mainline kernel removed the change and reverted back to the previous builds instead. However, the hasty releases posted prior to the integration of the fix now left several known devices that updated to the latest stable tree as soft-bricks instead. While the snapshots built off the mainline benefitted from the kernel reversion, existing multiple so called "stable" branches no longer were and remained categorized instead as severity one issue.
The matter is closed since the development team has elected to not correct the latest releases that contains the UBI code, and not for every device currently supported. Refreshing only those built with this module against the updated stable linux kernel streams. The fact that no action has taken place in a week leaves the matter closed and relegates those to migrate their devices to snapshots instead, or reversion to a previous generation that still incorporates latent issues and security holes.
I have opened a thread about MR8300 using 22.03.4 on april 10th. By this time the bug was already known. I was just cheking its presence in 22.03.4, and informing not to upgrade.
The original (oldest) thread was opened by @clauded on march 18th. I joined it on 19th. I'm only using the device from time to time, it's in a relative's home. So it took me some time to get it and perform tests/boot logs.