I do not have physical access to the router. I might in a few weeks to check the label, but I will never be able to open it to get console access.
The alternate firmware is 23.05 that works fine.
Is there anything we can do via software? Compare the flash partitions...cpu versions, don't know...
Nah, you won't be able to check revision on the software side 'cause that revision did not warrant a code change. I mean, the difference could be in a plastic molding for all I know or maybe they removed a couple protection diodes to cut costs... Long story short, neither openwrt nor linksys made revision specific firmwares for that router so it's safe to assume it's not relevant.
Anyway, the reason I asked for the alternate firmware is because I know from June to October this year there was an issue with a bugged version of mtd-utils in snapshot causing it to not actually write image to flash. So the bug was not in the firmware being flashed, but in the firmware doing the flashing. Maybe that broken version made its way into stable and you're not actually flashing but actually rebooting the same corrupted version all the time?
Can you check the new version was actually flashed. You can do that from the working firmware with the luci-app-advanced-reboot. If the flash was indeed successful, it would display Alternative OpenWrt (Linux 6.6.61) assuming you flashed the snapshot image I linked in my previous post.
A mismatch would indicate the image was not flashed properly. But then, that means your only running firmware cannot flash, so you'd need to TFTP from uboot with serial access to fix that mess.
That's a wild guess based on my own issue with the device that may or may not be relevant to your issue. Other than that and without any log to go on, I have no idea.
Copy and paste from Luci Advanced reboot:
Advanced Reboot
Linksys MR8300 Partitions
|Partition|Status|Firmware|Reboot|
| --- | --- | --- | --- |
|01|Alternative|OpenWrt SNAPSHOT r28114 (Linux 6.6.61)||
02 Current OpenWrt 23.05 (Linux 5.15.171)
Actually you may be able to check your hardware version remotely: cat /dev/mtd9ro shows hw_revision as well as hw_version.
It looks normal so the problem is somewhere else.
Are you sure the device is wired in a way that would still be accessible with default firewall zones and no VLAN config? As a reminder, both main and alternate firmware have separate configuration files.
Unless it's that kind of oversight, I just don't see a way around pulling log from serial.
Thank you, something to note down... here is the result:
# cat /dev/mtd9ro
admin1_passphrase=xxxxxxxx
admin2_passphrase=xxxxxxxx
cert_region=EU
default_passphrase=xxxxxxxx
default_ssid=_LinksysSetup160
deviceType=urn:home-linksys-com:device:Router:1
devinfo_version=20200219.1
hw_mac_addr=E8:9F:80:17:61:60
hw_revision=1.1
hw_version=XA
manufacturer=Linksys
manufacturerURL=http://www.linksys.com
manufacturer_date=2020/09/30
mfg_data_version=1
modelDescription=Linksys MR8300 Tri-band Mesh WiFi Router, AC2200
modelNumber=MR8300-UK
recovery_key=42096
serial_number=29V11M29A22069
sw_version=1.3.3
tc_passphrase=xxxxxxxxx
tc_ssid=K7ZdfpAkscfQf46luJmq0iaCNbnlkSn2
uuid_key=EE86DF2E-1DD2-11B2-8002-E89F80176160
wps_device_pin=xxxxxxx
To make that sure I flashed plain 23.05 from downloads with default configuration, exactly as I flash 24.10. No issues with 23.05 on default configuration.
Please see also my observation regarding the switch port up/down stati reported above which I believe is indicative that with 24.10 plain and snapshot, the kernel boot must be failing, or the device does not reach the stage when the LAN network interface is configured.
Hi.
Weird : I have tested several snapshots during this period, and flashes were successfull. Last time I tested was about 2 weeks ago. It can have occured since indeed. I will try again when I have access to the device.
The fact of the matter is we're stuck trying to find out what the condition to trigger the issue is. Might be related to ethernet speed/duplex negotiation or something connected to the USB port? So far, I can't replicate it.
I believe the problem started with mtd-utils 2.2.0 and got fixed by 2.2.1. Considering the timing and nature of the issue, that fits.
Also, stable is using last year's 2.1.5 so again, it makes sense that it isn't impacted. That's only guesswork but it's compelling enough to me.
Sounds reasonable indeed.
I'll try myself as soon as I can, and I'll bring the serial link to monitor the boot. I'll report here of course.
Thank you and everyone for your help and patience. I will report back if/when I manage to get physical access to this router, which means in practical terms that I have to replace it since it is managing a live connection and I have only one of this model.
Hi
As promised a few days ago, I have just flashed a 24.10 snapshot. It flashes and boots correctly. I didn't keep the settings, starting fresh. It's OpenWrt 24.10-SNAPSHOT r28155-17bdccb4a5
Mistery solved!
I went to the page https://openwrt.org/toh/linksys/mr8300 which I had not visited in a long time and I found the solution.
My router still had
kernsize = 300000
For some reason this router never had any issues running 23.05, perhaps because I build my openwrt firmware with only the basic kernel drivers.
I set the parameter to:
kernsize = 500000
as recommended and now it boots 24.10.
Thank you again for helping me with the investigation.
Indeed solution is obvious. 
As long as the kernel is reduced under 3MB it should boot. Default settings and drivers in 23.05 (and 24.10) nevertheless require 5MB, hence the kernel size variable change.
As I pointed out 23.05 (also standard OpenWRT 23.05 downloaded images) worked flawlessly on this router since its release with this router's kernsize set to 300000, which explains why I have never looked at this parameter before.
It's weird, it shouldn't. I am the one who tested the kernel size change on the MR8300 two years ago. I confess that I don't follow the commits for 23.05, does something has changed in the partitions scheme?
Anyhow, it is mandatory for 24.10, so the wiki should stay as is.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.