MR8300 doesn't boot 22.03.4 (as expected)

Hi.
Don't blame me that 22.03.4 hasn't been officialy released yet, I know already. Please read this.

It has been noticed for a few weeks that both master snapshot and 22.03 snapshot builds don't boot. Apparently it is related to a kernel change mid-march causing a partition failing to be detected.

It wanted to give a try to 22.03.4 (official factory), and as expected it also fails to boot with the very same error.
I have already published a serial boot log here.

Additional infos.

Possible kernel modification causing the issue.
https://lore.kernel.org/lkml/20230306013308.3884777-1-chengzhihao1@huawei.com/t/

Regards.

Maybe this might help:

1 Like

Hi

FYI
I built a 21.02.6 (r16842), kernel 5.4.238, for my MR8300
It doesn't boot, reverting back to 22.03.3

1 Like

The linux kernel 5.4.240 still has the fault in the code, it has not been updated with the correction as of yet.

1 Like

I wrote this in the wiki :wink:

Hi.
Were you able to serial log the boot ? To compare with the ones I published ?

Umm.. No...

I've already deleted the build and usually I don't TTL into the router unless I've bricked it. MR8300's are virtually brick proof.

1 Like

Hi.
As of 4/15/2023, the kernel issue has been solved for 21.02, 22.03 and master snapshots. Unfortunatly 21.02.6 and 22.03.4 stables won't boot. There won't be anymore release for the 21.02 branch. For the 22.03 branch, we should wait for a future stable 22.03.5. So don't install/upgrade to 22.03.4 in the meantime.

Given that sad situation we might consider releasing yet another 21.02.7 point release which includes this fix...

2 Likes

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 :warning:
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).