Hmm maybe it may work
Have tried it, unfortunately no change from what I can see?
Yeah it hasn't switched to mtd24 you need to do that thing I said before
Alright, I've tried to do so, but I don't seem to be able to get it to work. The router just doesn't respond? Then I have to turn it off and on again on the 4th try and it boots into OpenWrt again, but the same partition as before?
https://pastebin.mozilla.org/QMpNacMf
So, just to confirm, all that's left to do is get the WiFi radios up. And that's because the firmware files are on mtd24, which is alt_rootfs? I'm not sure I'm fully on the same page though. Is the OpenWrt that boots on the rootfs partition, mtd22? And that's what was flashed when going from Stock -> OpenWrt? So whenever I do a sysupgrade it's NOT upgrading the OpenWrt that's currently installed, but instead flashing the alt_rootfs that we can't boot into..?
Tue Sep 19 08:14:02 2023 kern.warn kernel: [ 9.912432] ath11k c000000.wifi: qmi ignore invalid mem req type 3
Tue Sep 19 08:14:02 2023 kern.info kernel: [ 9.919922] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
Tue Sep 19 08:14:02 2023 kern.info kernel: [ 9.919976] ath11k c000000.wifi: fw_version 0x290104a5 fw_build_timestamp 2023-08-02 20:32 fw_build_id WLAN.HK.2.9.0.1-01890-QCAHKSWPL_SILICONZ-1
Tue Sep 19 08:14:02 2023 kern.err kernel: [ 10.068950] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=Linksys-MX4200 from ath11k/IPQ8074/hw2.0/board-2.bin
Tue Sep 19 08:14:02 2023 kern.err kernel: [ 10.069018] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255 from ath11k/IPQ8074/hw2.0/board-2.bin
Tue Sep 19 08:14:02 2023 kern.err kernel: [ 10.082471] ath11k c000000.wifi: failed to fetch board.bin from IPQ8074/hw2.0
Tue Sep 19 08:14:02 2023 kern.warn kernel: [ 10.095261] ath11k c000000.wifi: qmi failed to fetch board file: -12
Tue Sep 19 08:14:02 2023 kern.warn kernel: [ 10.102281] ath11k c000000.wifi: failed to load board data file: -12
That is correct as far as I understand it.
In fact according to some docs for other Linksys routers the recommended way of updating OpenWRT is in fact to never use sysupgrade but instead force a reboot into the OEM firmware and use that to flash. That might be very old advice though: https://openwrt.org/toh/linksys/ea6350_v3#upgrading_openwrt
That's a bit late for you though! You could try using your working OpenWRT install to flash the OEM firmware to the alt_rootfs and then use that installation to flash over the rootfs.
Oh that might be interesting!
So from your boot log of your working OpenWRT firmware @MrAlex94 I see this:
[ 2.807606] ubi0: background thread "ubi_bgt0d" started, PID 514
[ 2.808085] block ubiblock0_0: created from ubi0:0(kernel)
[ 2.823583] block ubiblock0_1: created from ubi0:1(rootfs)
and from the broken sysupgrade installation boot log posted on Github I see this:
[ 2.790098] ubi0: background thread "ubi_bgt0d" started, PID 513
[ 2.790581] block ubiblock0_0: created from ubi0:0(roo▒[ 2.811394] Waiting for root device /dev/ubiblock0_1...
Now, to me that looks like it has flashed the rootfs to ubiblock0_0 whereas in the working installation ubiblock0_0 is the kernel. Could this be the issue? The sysupgrade is flashing the kernel and rootfs the wrong way around? Or could it be due to the overlapping kernel + rootfs?
Could probably be due to the overlap
1 Like
There is logic to handle the overlap when writing though it looks like: https://github.com/openwrt/openwrt/blob/0c43a48735959245f18d79a6e908d3b45cff0a94/package/base-files/files/lib/upgrade/nand.sh#L321-L332
Though maybe we haven't got it configured correctly somewhere for this logic to work.
Damn hope I haven't bricked anything according to the message there lol
Well... the other firmware is bricked 
It won't boot. But to be truly bricked you'd need to do it to both firmwares! Thank goodness for dual firmwares! 
Yeah it's recoverable, done it by hosting a server with an IP and boom flashes stock
What are the steps for that?
Can someone try with bootargs-append = " ubi.block=0,1 root=/dev/ubiblock0_1? Again, not sure that it'll work and if it does then I don't understand why it works without it on first flash... But hey ho!
(and if it doesn't work then I maybe understand why it doesn't )
I've ordered myself a spare MX4200 so will have more of a play myself when it arrives.
Edit: actually pretty sure that won't help... but it might...
1 Like
If I'm free I'll see if I can do it
Setup a server with 192.168.0.12 with Port 69 iirc, then rename stock fw to chiron.img, and then in the router uboot mode 'run flashimg Chiron.img'
Some serious dedication bought a new router for one bug lol
I'm a tinker-er... what can I say.
Ah, need to use the serial port for that, right?
To enter uboot yeah
This also concerns me in comparing the bootlog from the working OpenWRT
[ 2.784918] ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
to the broken one
[ 2.767426] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
Not sure why the number of volumes would be different? Or maybe that isn't what that means? Maybe a difference between booting from boot_part 1 vs 2?