Hi.
Pleased to read this.
Release announcement states that 21.02.6 would be the last. You may as well consider a 22.03.5 release for the same reason. Thank you.
EDIT : are there many other devices involved?
1 Like
Leaving things broken for which had been originally operational is not a solution where individuals skip generations due to poor judgement. The issue has been known for a month now, not much traction for weeks after reporting. The solution was posted March 6, the fix was not considered. The option to roll-back in the interim for the offending code was also ignored as a way to preserve the integrity of the builds for all the targets that had been known to be working for several generations. Now a caution is needed to give a heads up to unsuspecting individuals as a proposed 'fix'? The real correction is to refresh all the stable branches with the correction so the matter can be closed and goes away for good and you do not need to be dragging a historical mistake through an unknown release strategy for the future. Simple, clean, and effective. Short of such is just a mess.
1 Like
As highlighted this situation with @badulesia, consideration on branching just adds to the burden for the development team. Refreshing each branch is a sensible approach since it would not impact any of the devices already working, resolve the issue with those that do not, and ensure that those which remain unknown at present do not come back to haunt the team from this exercise. I for one stick with the snapshot releases for eight unique equipment due to the necessity to ensure operational consistency, and predictable troubleshooting, and due to a very long standing deficiency where one of the devices errantly marks the environment partition as read-only preventing dual-partition devices from deploying Advanced Reboot for device management. So I am not stressing the need to refresh the builds on a personal matter, just that the whole way the issue is being handled is foolish and certainly stands up to a release strategy being done as a rush job instead of preserving the integrity of what 'stable' releases mean.
This was very helpful as the EA8300 page has not been updated with this information.
Do you (or someone on the forum) know if it is possible to have the download links for these two devices removed from the Index of /releases/22.03.4/targets/ipq40xx/generic/ (openwrt.org) page to save others from trying to install only to fail?
P.S. I only found why I couldn't update after the router fell back to 22.03.3 and I was able to search and find this thread in the forum. This is the first upgrade failure I have encountered since starting with 19.* in 2021.
You're welcome.
I'm a user of MR8300, so I'm willing to maintain the wiki page for it. Every information from the MR8300 is basically identical for the EA8300. That being said, there may be tiny differences, that only a user of the EA8300 would be aware of. So only a real user of the EA8300 should maintain its page.
Actually the only way is a strong warning message in the wiki, assuming the user will read it before upgrading. In case of trouble, the device can easily be recovered.
1 Like
Thank you! I read the EA8300 docs more carefully and set the bootloader variable using SSH and fw_setenv kernsize 500000 per instructions on MR8300 page. I then successfully rebooted back into 22.03.3. Is this sufficient to install 22.03.4, or do I still need to wait for 22.03.5? It doesn't look like the commit addresses this (also needed) manual change.
Also, I'm unfamiliar with protocol / how the Wiki is maintained. I would be happy to request a login and help by copying the 22.03.4 warning from the MR8300 page to the EA8300 page, or would it be best to add the last person that edited that page to this thread and request that?
NO = in this command 
Read more carefully the documentation. You device may be bricked and need a serial link to recover.
This command is only needed if you want to run a snapshot, or prepare for the future. It is not needed to run actually any 22.03.x. 22.03.4 won't run anyhow, don't even try. Keep 22.03.3 and wait for 22.03.5.
1 Like
Thank you again! My bad, I did read the instructions for modifying the bootloader using the proper command, but mistakenly posted the output of fw_printenv when I checked to see the change was there after reboot, which could confuse others. I've edited my post to clarify the command I used.
1 Like
In that case you may want to try a master snapshot. It runs very well and has better performance. Meanwhile you need to reconfigure the device from scratch as it will now use DSA instead of swconfig. It is worthy, and ready for the next major 23.xx.
1 Like
For future users of OpenWrt on MR8300, when 23.xx is the new stable, maybe it's helpful to have a stripped down build with kernel 5.10 (from 22.03.3) that just executes the kernsize change upon boot then reboots backs to the OEM firmware to allow flashing of 23.xx and higher.
There will be no kernel v5.10 in 23.xx, it will only ship with a single kernel (v5.15) for everything. If you need kernel v5.10 for anything, you will need to resort to 22.03.x (and chances are non-zero that you might be able to convince a developer to get necessary changes in future 22.03.x releases).
I know, but you can only set kernsize with kernel 5.10
The stripped down version can be as simple as using the firmware selector with a minimal set of packages and a start up script that set the kernsize.
You don't understand, there will not be any kernel v5.10 in 23.xx at all. Not on the source level - and even less in binary form, there's no way to do this sanely. The kernel is always shared between all devices of a (sub-)target, there can't be different kernels for different images of the same (sub-)target, not without major buildsystem changes (no going to happen). On top of that, none of the developers will sign up for continued kernel v5.10 maintenance for 22.xx, that would be a significant undertaking - and swconfig vs DSA won't make this any easier either. Really, there is no chance -at all- for this.
The options with 22.03.x would be:
- documentation changes in the wiki (device page)
trivial, someone will just have to write something up, anyone can sign up for a wiki account - linking to a simple script to do these changes on top of 22.03
easy, apart from writing said script (relatively easy, the biggest effort would be proper error handling (making sure not to mess up the firmware environment) - getting above script into a future 22.03.x maintenance release, available for manual execution
you'd likely be able to convince a developer to merge such a PR - changing sysupgrade in a future 22.03.x maintenance release to do the necessary automatically for you
this will need more convincing a developer, but that might be successful.
I do understand, I know.
If you read my initial suggestion it said from 22.03.3
What I'm suggesting is a firmware that just sets the kernsize, before flashing with the 23.xx firmware.
Because for a new user of OpenWrt on MR8300 THEY WILL ALWAYS need to use a 22.03.3 firmware to set the kernsize! So it mind as well be a firmware that does this automatically and as such it only needs minimal set of packages.
I can create this firmware right now by going to the firmware selector, selecting a minimal custom set of packages for 22.03.3 and a startup script that sets the kernsize.
Finally put a link to this firmware in the wiki page.
EDIT: Added that this firmware could be downloaded from the wiki.
1 Like
Still a kludge by any other name, refresh the 22.03.4 tree and all is done for good. Simple, elegant, and keeps the migraines to a minimum.
Sure.
But... that's not what I'm talking about.
I'm talking about in the future, after 23.xx is out and a user gets a Linksys MR8300. You will not be able to install 23.xx on it because of the kernsize limitation, so that user will still need to install a a firmware with kernel 5.10 before to set the kernsize. Now, I have no problem if 22.03.4 or 5 checks the kernsize automatically and sets it at boot (although a user might actually want to use 22.03.4 or 5 without changing kernsize).
Other IPQ40xx devices are already running with kernsize 600000, for which I have also adopted so that the next kernel bump does not hit the ceiling anytime soon, so using an interim step for installation is acceptable for future releases as long as the release notes disclose it. A commented addition to the rc.local script for these boxes that tests for the firmware environment variable size and automatically adjusts to the parameter to the desired cap for all legacy releases would solve the upgrade issue in the future but would still bite the individuals starting from a fresh 23.x and later release.
So... What I'm suggesting is creating (already said this multiple times) a stripped down firmware of 22.03.x that only serves to set the kernsize and reboot back to partition A, automatically and put a link to it in the wiki.
The kernsize cap adjustment could become a feature, always checking for the next stable release.
But down the line, say, 5 years from now, and a user gets this device, OEM, it would be helpful that there was a link in the wiki to a firmware (again, it would have to be 22.03.x with a startup script) that would set the kernsize to whatever would be the ceiling needed then.
Hi.
22.03.5 (about to be released) is now booting!
Thanks to the devs for solving this.
3 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.