FS#3539 - ramips/mt7620 snapshot does not boot #8576
It's happening on
Install the factory image onto the stock firmware - or - install the sysupgrade onto the running r14281.
The snapshot version is booted when attempting to get into JBOOT but doesn't come up automatically.
Please guide/advise. Thank you.
CDG56CDL_0T3 Jboot B972
mtd layout on working r14281 (2020/08/26):
The text was updated successfully, but these errors were encountered:
Please do not close the task.
The latest findings is: When compiling trunk/master myself then both options work great. Installing the factory.bin on top of the native firmware and using sysupgrade with the sysupgrade.bin.
As soon as I download and install a snapshot build it fails.
Please find the config attached when compiling trunk/master myself - installing the image goes well with it.
The config of the working build:
The mtd layout of the bricked openwrt snapshot install. It was booting after attempting to get into the JBOOT/recovery, pressing reset, switching device on, releasing the reset button after 8 seconds.
OpenWrt SNAPSHOT, r15371-7e4585e593
Fwiw, /proc/mtd doesn't tell you the layout, it only tells you the mapping of partition number to name and size, not offset. You can get offset by looking in dmesg output not too long after boot. I typically pipe dmesg through grep 0x0 for something like this:
The kernel, rootfs and rootfs_data offsets are relative to the firmware partition, in this case.
I'd like to share my recent similar experience and workaround.
In short, you may like to try sysupgrade -p <sysupgrade.bin> from CLI.
Now here comes the long part.
Please note, there are no hard findings. Only my observations of a different device and a possible workaround.
My device is mt7621 powered Youhua WR1200JS. Sysupgrades on it were always fine up to r15473-5876ba6460. But when I sysupgraded from r15473 to r15491-7babb978ad, I came across the issue described in the OP, that is, my device won't boot without pressing the reset key when the device rebooted or was powered on.
The bootloader on my device is Breed. Unfortunately I don't have a serial cable to see what actually was going on during startup.
After successful boot with user intervention, the device is running normally. But I don't like the situation as it's not possible to perform remote sysupgrade and the device won't come up on its own when power resumes.
I searched and found this thread. The focus on flash layout indeed shed some light on this problem.
I wondered if a recently enabled kernel module (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a1a7f3274e0ed27511d45f62ee20281d8d57c7af) drastically increased the size of the kernel partition and the bootloader did not like it.
So I tried compiling builds with and without lwtunnel enabled, from r15503-33646a51ab to r15533-f13b623f5e, to find that it's not the case. While the size of the kernel partition went up and down as the module flag was switched on/off, it made no difference. The device still needed reset key pressed to boot.
Then I recalled the procedure of installing OpenWRT onto my device. First flash initramfs-kernel.bin, then take a relatedly important however undocumented step: execute sysupgrade -n <sysupgrade.bin> from CLI or flash <sysupgrade.bin> with "don't restore config" checked from Web-UI after the initramfs-kernel boot.
So I tried sysupgrade -n (no restore config), the device reboot ok unattended with all default settings. I experimented further, this time with sysupgrade -p (don't keep partition table, but restore config), this also works, and better with settings kept.
Subsequent sysupgrade -p to r15540-20a7c9d5c9 build with lwtunnel enabled went smoothly.
Then sysupgrade from r15540 to r15554-1bd005ea53 was also ok, even without -p.
Nevertheless, to be on the safe side I've decided to sysupgrade -p every time from now on, for there are some ongoing development activities regarding mtdsplit, may or may not be affecting my device.
Hope this info can help.