I have not tested what happens when both Kernel and Kernel2 partitions are trashed.
it will enter rescue mode.
i have tested it again i noticed i was wrong.
Yeah the mr has be merged.
yeah, but you didn't remove the useless extra ax54 ALT entry like I've told you above.
Yeah i didnt
First snspshot build for it : https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=ramips%2Fmt7621&id=asus_rt-ax54
Hoping for a little help.
I have an Asus RT-AX1800S. A couple of weeks ago, I installed the snapshot build via the mtd-write method and everything seemed grand. I rebooted it a few times, everything worked as expected.
Then I put it on the shelf to work on some other things.
Today I got the router back off the shelf, ready to finish setting it up to my preferences... and... it doesn't boot anymore. No idea why, as it worked just fine when I put it up.
I used the Asus Firmware Restoration tool to restore it to factory, which worked fine.
Then re-flashed it with a fresh OpenWRT snapshot, which did not.
I think it's boot-looping. The LED comes on for a few seconds and I get a link detection light on the Ethernet port, then the light goes out; after a few seconds, this repeats.
Open to any suggestions... The hardware seems fine, it works with the stock firmware. But I'd really love to have OpenWRT running on it instead!
Did you flash the firmware intended for AX53U at any point?
I don't believe so. I've tried only Snapshot builds from the Firmware Selector for the RT-AX54. First the snapshot from 2023-04-12 (the one that worked for a while, then mysteriously stopped working) then the firmware from 2023-04-24.
Can you try flashing via Asus Firmware Restoration Tool the initramfs-kernel image from here?
After booting that you can flash the sysupgrade image.
(those are builds containing LuCI, sources as of today).
Steps also mentioned here (for AX53U).
This avoids flashing the stock firmware twice.
Thanks for your help!
This has resulted in partial success... The initramfs-kernel image works fine. I used the Asus tool to flash it and boot into it.
Using the sysupgrade isn't going so well, though. I tried doing the upgrade via luci and also by scping the sysupgrade image to /tmp and running sysupgrade from the shell. I've tried using the sysupgrade image from your build directory and from the Firmware Selector. None of them seem to stick -- I'm still in the initramfs version after rebooting. Weird.
Without serial it's hard to know what the router doesn't like.
But I'll try building a few images later and see if we can figure out what it doesn't like.
And I'll also test the latest images on AX53U because I honestly didn't have the chance yet, maybe something broke in master.
LE: but something broken in master recently wouldn't explain your old install not booting anymore.
I've included a new build in that folder, please flash the new initramfs via the Firware Restoration tool and then sysupgrade to this version.
Please use only the files from that folder, 20230426-001-README-1ST, do not sysupgrade to some other build.
The new initramfs-kernel version works, I can see the partition changes in /proc/mtd. But the sysupgrade still fails:
root@OpenWrt:/tmp# sysupgrade -n -v openwrt-ramips-mt7621-asus_rt-ax54-squashfs-sysupgrade.bin
Wed Apr 26 12:05:37 UTC 2023 upgrade: Commencing upgrade. Closing all shell sessions.
Command failed: Connection failed
root@OpenWrt:/tmp# Connection to 192.168.1.1 closed by remote host.
Connection to 192.168.1.1 closed.
I will try to find a serial adapter and crack open the case and see if there is any additional information available that way that might explain what is happening.
It takes a while for the router to come back after flashing, in what state are the leds after it reboots?
I opened it up and attached to the serial console.
This is what is happening that is causing the sysupgrade to fail:
root@OpenWrt:/tmp# sysupgrade -n -v openwrt-ramips-mt7621-asus_rt-ax54-squashfs-sysupgrade.bin
Wed Apr 26 22:16:35 UTC 2023 upgrade: Commencing upgrade. Closing all shell sessions.
Watchdog handover: fd=3
- watchdog -
Watchdog does not have CARDRESET support
Wed Apr 26 22:16:36 UTC 2023 upgrade: Sending TERM to remaining processes ...
Wed Apr 26 22:16:40 UTC 2023 upgrade: Sending KILL to remaining processes ...
[ 114.049710] stage2 (3300): drop_caches: 3
Wed Apr 26 22:16:46 UTC 2023 upgrade: Switching to ramdisk...
Wed Apr 26 22:16:48 UTC 2023 upgrade: Performing system upgrade...
verifying sysupgrade tar file integrity
Unlocking kernel ...
Writing from <stdin> to kernel ...
[ 117.367835] ubi0: attaching mtd7
[ 117.473378] UBI: EOF marker found, PEBs from 31 will be erased
[ 118.023742] ubi0 error: ubi_io_is_bad: error -77 while checking if PEB 315 is bad
[ 118.031442] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd7, error -77
ubiattach: error!: cannot attach mtd7
error 77 (Bad message)
ubiformat: mtd7 (nand), size 48234496 bytes (46.0 MiB), 368 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 183 -[ 118.883660] ubi0: attaching mtd7
libscan: scannin[ 118.990002] UBI: EOF marker found, PEBs from 31 will be erased
libscan: scanning eraseblock 31libmtd: error!: [ 119.541642] ubi0 error: ubi_io_is_bad: error -77 while checking if PEB 315 is bad
[ 119.549588] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd7, error -77
ubiattach: error!: cannot attach mtd7
error 77 (Bad message)
cannot attach ubi mtd partition ubi
sysupgrade failed
Then the device reboots.
I have no experience with ubifs... Might I have a bad block in my flash or something that is causing this result?
Ok, can you stop the boot process and go into uboot console?
From there you should be able to get the nmbm state, similar to what I've posted here: https://github.com/openwrt/openwrt/pull/11806#issuecomment-1383803384
using nmbm nmbm0 state
My output looks identical to yours...
=> nmbm nmbm0 info:
nmbm0:
Total blocks: 1024
Data blocks: 960
Management start block: 960
Info table size: 0x2000
Main info table start block: 960
Backup info table start block: 963
Signature block: 1023
Mapping blocks top address: 1022
Mapping blocks limit address: 964
=> nmbm nmbm0 state:
Physical blocks:
Legends:
- Good data block
+ Good management block
B Bad block
I Main info table
i Backup info table
M Remapped spare block
S Signature block
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
I++i+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++S
Logical blocks:
Legends:
- Good block
+ Initially remapped block
M Remapped block
B Bad/Unmapped block
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
=> nand info:
Device 0: nand0, sector size 128 KiB
Page size 2048 b
OOB size 64 b
Erase size 131072 b
subpagesize 512 b
options 0x00010000
bbt options 0x00008000
So, I guess that means no bad block, at least!
No bad blocks that nmbm knows of, at least.
I could compile a few more test builds with/without nmbm, range covering ubi etc.
Willing to test? Until someone else has any idea about this.