Linksys EA4500: OpenWrt 25.12.5 sysupgrade fails and router automatically reverts to 24.10.8

Installing and Using OpenWrt
1

Hello,

I have a Linksys EA4500 (Viper) running OpenWrt. I am currently on OpenWrt 24.10.8, and the router is working normally.

I attempted to upgrade to the latest OpenWrt 25.12.5 using the official image:

openwrt-25.12.5-kirkwood-generic-linksys_ea4500-squashfs-sysupgrade.bin

The image is listed as compatible with the EA4500 on the OpenWrt download site.

However, after performing the upgrade, the router does not boot into 25.12.5. The power LED blinks for several minutes, the router becomes temporarily unreachable, and after reboot/recovery it eventually returns to the previous 24.10.8 installation.

I have reproduced this behavior twice with 25.12.5.

Current hardware/software information



Model: Linksys EA4500 (Viper)
SoC: Feroceon 88FR131 rev 1 (v5l)
Target: kirkwood/generic

OpenWrt version: 24.10.8
Kernel: 6.6.144
Revision: r29233-443ec4032a

ubus call system board:



{
        "kernel": "6.6.144",
        "hostname": "OpenWrt",
        "system": "Feroceon 88FR131 rev 1 (v5l)",
        "model": "Linksys EA4500 (Viper)",
        "board_name": "linksys,ea4500",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.8",
                "revision": "r29233-443ec4032a",
                "target": "kirkwood/generic",
                "description": "OpenWrt 24.10.8 r29233-443ec4032a"
        }
}

MTD layout



dev:    size   erasesize  name
mtd0: 00080000 00020000 "u-boot"
mtd1: 00020000 00020000 "u_env"
mtd2: 00020000 00020000 "s_env"
mtd3: 01a00000 00020000 "kernel1"
mtd4: 01600000 00020000 "ubi"
mtd5: 01a00000 00020000 "kernel2"
mtd6: 01600000 00020000 "rootfs2"
mtd7: 04a00000 00020000 "syscfg"
mtd8: 00140000 00020000 "unused"

U-Boot environment

Relevant variables:



bootdelay=0
boot_part_ready=3
auto_recovery=yes
enaAutoRecovery=yes
boot_part=1
bootcmd="run nandboot"

The boot commands are:



nandboot=nand read.e 0x2000000 0x200000 0x300000; ...; bootm 0x2000000;

altnandboot=nand read.e 0x2000000 0x1c00000 0x300000; ...; bootm 0x2000000;

So the current bootloader reads 3 MiB for the kernel from both the primary and alternate locations.

Current kernel command line



console=ttyS0,115200
mtdparts=nand_mtd:512k(uboot)ro,128k@512k(u_env),128k@640k(s_env),26m@2m(kernel),26m@2m(rootfs)fs,26m@28m(alt_kernel),26m@28m(alt_rootfs)fs,74m@54m(syscfg)
root=/dev/mtdblock4
ro
rootfstype=jffs2

OpenWrt upgrade script

The installed /lib/upgrade/platform.sh specifically handles the EA4500 using:



linksys,e4200-v2|\
linksys,ea3500|\
linksys,ea4500)
        platform_do_upgrade_linksys "$1"

The relevant part of /lib/upgrade/linksys.sh is:



case $cur_boot_part in
1)
        fw_setenv -s - <<-EOF
                boot_part 2
                bootcmd "run altnandboot"
        EOF
        printf "kernel2"
        return
        ;;
2)
        fw_setenv -s - <<-EOF
                boot_part 1
                bootcmd "run nandboot"
        EOF
        printf "kernel1"
        return
        ;;
esac

Therefore, when upgrading from my current boot_part=1, OpenWrt should write the new firmware to the alternate slot and change the bootloader to:



boot_part=2
bootcmd="run altnandboot"

The upgrade appears to complete, but the router subsequently fails to boot the new firmware and eventually falls back to the working 24.10.8 installation.

NAND health

I also checked UBI:



UBI version:                    1
Count of UBI devices:           1
Volumes count:                  2
Count of bad physical eraseblocks: 0

The current 24.10.8 installation is stable and fully functional, so there does not appear to be an obvious NAND/filesystem failure.

My question

Could someone familiar with the EA4500/Viper bootloader and Kirkwood target explain why OpenWrt 25.12.5 fails to boot on this device?

In particular:

  1. Is the 25.12.5 EA4500 sysupgrade image actually expected to work directly from 24.10.8?
  2. Is the 0x300000 kernel read size in nandboot/altnandboot a problem with newer OpenWrt kernels?
  3. Does the EA4500 require the U-Boot environment to be modified before upgrading to 25.12.x?
  4. Is there a required intermediate firmware version between 24.10.x and 25.12.x?
  5. Could this be a bug/regression in the EA4500-specific platform_do_upgrade_linksys() implementation?
  6. Is there a safe way to determine why the alternate image fails to boot before changing any U-Boot variables?
  7. Are there any specific serial-console messages or additional commands I should collect to diagnose the failed 25.12.5 boot?

I currently have a working OpenWrt 24.10.8 installation, so I would prefer not to manually modify U-Boot or NAND unless the correct procedure is confirmed.

Any guidance on the correct upgrade procedure or the reason for the automatic rollback would be appreciated.

Thanks.

2

Maybe sysupgrade is failing silently somewhere else, it's not particulary verbose in the first place, and sometimes errors occur after it has shut down stdout, so it simply can't show you what's wrong...

What do you see if you just try to validate the new image?

/usr/libexec/validate_firmware_image openwrt-25.12.5-blah-...
3

No, it overwrites itself and leaves the known good alone. After a successful boot it renames them.

It could be booting but not getting a response from you.

Have you tried manually setting the subnet and logging into 192.168.1.1?

You have about 90 seconds after it completes the boot to try, or it will go back to known good.

4

Thanks for the clarification. That helps explain the behavior I am seeing.

My previous assumption about the EA4500/Viper bootloader was incorrect. I was assuming that, when running from boot_part=1, sysupgrade would write 25.12.5 to the inactive firmware partition and then switch boot_part to that partition. From your explanation, that is not how this bootloader's upgrade/rollback mechanism works: the new firmware replaces the currently selected image, while the known-good image remains available for recovery. The bootloader only considers the new image permanent after it successfully boots; otherwise it restores/boots the previously known-good image.

This changes how I interpret the rollback.

With 24.10.8 currently running, the 25.12.5 sysupgrade appears to complete and the router reboots, but after the boot attempt it eventually returns to 24.10.8. Therefore, the rollback alone does not prove that the 25.12.5 kernel/rootfs failed to boot. It could mean that 25.12.5 reaches userspace but does not complete whatever boot-success condition the EA4500/Viper bootloader is expecting within the timeout period.

I will test this by connecting directly to the LAN with a static address and monitoring 192.168.1.1 immediately after the reboot, rather than waiting for the rollback to occur.

I will also validate the image before upgrading with:

/usr/libexec/validate_firmware_image <25.12.5-image>

and collect:

ubus call system board
fw_printenv boot_part
cat /proc/mtd

from 24.10.8.

If 25.12.5 becomes reachable during the boot-validation window, that should distinguish a genuine boot failure from a successful boot followed by the bootloader's rollback mechanism.

I'll report the validation output and boot/partition information before making another upgrade attempt.

5

At first they were separate partitions but now, they just call them that. They are really just files in a complicated overlay.

This is one of the ways they implimented to mitigate people not resetting configs to defaults before updating. Then applying saved configs.

Some high end stuff are put in failsafe and you download whtever firmware the OEM says.

This, extra step of locking down failsafe in sandbox, ensures they fall into a "I'll take certified firmware, now that you, an IT pro, screwed up an update."

:wink:

6

Thanks for the suggestions. I did some additional testing on my EA4500/Viper running OpenWrt 24.10.8.

The 25.12.5 sysupgrade image validates successfully:

/usr/libexec/validate_firmware_image /tmp/openwrt-25.12.5-kirkwood-generic-linksys_ea4500-squashfs-sysupgrade.bin

{
        "tests": {
                "fwtool_signature": true,
                "fwtool_device_match": true
        },
        "valid": true,
        "forceable": true,
        "allow_backup": true
}

So the image passes both the fwtool signature and EA4500 device-match checks.

Current bootloader environment:

boot_part=2
boot_part_ready=3
bootbadcount=0
bootcmd="run altnandboot"

The relevant OpenWrt upgrade script is /lib/upgrade/linksys.sh. It determines the current boot_part, switches to the other partition, changes the corresponding bootcmd, and then writes the sysupgrade image to that target partition.

For my current boot_part=2, the script selects:

boot_part 1
bootcmd "run nandboot"

and targets kernel1/rootfs1.

The EA4500 is currently booting normally from partition 2, and bootbadcount is 0.

I have not attempted the 25.12.5 upgrade again yet. I am going to perform a controlled sysupgrade -v test and monitor the router/network during the initial boot, including checking 192.168.1.1 and the configured LAN address, to determine whether 25.12.5 is actually booting before the bootloader falls back.

I'll report the result after the test.

7

I had to paraphrase; I read that so long ago.
Thanks for the reminder.

8

I tested the OpenWrt 25.12.5 sysupgrade on my Linksys EA4500 (Viper / Kirkwood).

Current system before the upgrade:

  • Model: Linksys EA4500 (Viper)

  • Target: kirkwood/generic

  • Architecture: arm_xscale

  • OpenWrt: 24.10.8 r29233-443ec4032a

  • Kernel: 6.6.144

The 25.12.5 image used was:

openwrt-25.12.5-kirkwood-generic-linksys_ea4500-squashfs-sysupgrade.bin

The image was copied to /tmp and passed the firmware validation successfully:

validate_firmware_image

returned:

fwtool_signature: true
fwtool_device_match: true
valid: true
forceable: true
allow_backup: true

I also ran:

sysupgrade -T /tmp/openwrt-25.12.5-kirkwood-generic-linksys_ea4500-squashfs-sysupgrade.bin

which returned to the shell with no errors.

Before flashing, I checked the boot environment. Relevant values were:

boot_part=2
boot_part_ready=3
bootbadcount=0
bootcmd="run altnandboot"

The NAND layout was:

mtd0 u-boot 0x00080000
mtd1 u_env 0x00020000
mtd2 s_env 0x00020000
mtd3 kernel1 0x01a00000
mtd4 rootfs1 0x01600000
mtd5 kernel2 0x01a00000
mtd6 ubi 0x01600000
mtd7 syscfg 0x04a00000

The current root filesystem was mounted from UBI/overlay:

/dev/ubi0_1 on /overlay type ubifs

I also inspected /lib/upgrade/linksys.sh. The upgrade logic explicitly handles the EA4500's dual-bank layout. When boot_part=2, linksys_get_target_firmware() selects kernel1 as the target, changes the environment to:

boot_part 1
bootcmd "run nandboot"

and then nand_upgrade_tar writes the new firmware to that alternate bank.

Likewise, when boot_part=1, it selects kernel2 and switches the boot environment to:

boot_part 2
bootcmd "run altnandboot"

So I did not manually modify the bootloader variables or write directly to NAND. I allowed the standard OpenWrt sysupgrade mechanism to handle the dual-bank upgrade.

I then performed:

sysupgrade -v -n /tmp/openwrt-25.12.5-kirkwood-generic-linksys_ea4500-squashfs-sysupgrade.bin

The upgrade reported:

upgrade: Commencing upgrade. Closing all shell sessions.

and the SSH connection closed normally.

However, after waiting more than 5 minutes, the router did not respond to 192.168.1.1 over the wired LAN connection. I then performed one controlled power cycle.

After reboot, the EA4500 had automatically returned to the previous OpenWrt 24.10.8 installation. Importantly, the previous configuration was intact and the router was fully functional again.

The EA4500 is now accessible at 192.168.50.1, both 2.4 GHz and 5 GHz Wi-Fi are working, and the previous network configuration is intact.

This appears consistent with the EA4500's dual-firmware/failsafe design: the new firmware was written to the alternate firmware bank, the router failed to successfully boot from that bank, and the device eventually reverted to the previously working firmware bank. The OpenWrt EA4500 documentation describes this exact dual-bank/failsafe behavior.

One point I would particularly like to clarify is whether there is a known issue with the EA4500/Viper when upgrading from OpenWrt 24.10.8 to 25.12.5, possibly related to the kernel/rootfs layout or the bootloader's expected kernel size.

I have not manually changed boot_part, bootcmd, boot_part_ready, or bootbadcount, and I have not performed any raw NAND writes.

Any advice on what should be checked next before attempting another 25.12.5 upgrade would be appreciated.

9

Do a backup, confirm backup; make a couple, not copy one to another place.
Wipe the config. Confirm it wiped. Try upgrade.

10

Just to be clear, that validate_firmware_image script is what sysupgrade -T uses internally to do its validation, the only difference is that when you run sysupgrade it hides all the details from you.

11

Thanks, that clarifies the validate_firmware_image / sysupgrade -T point. I understand now that sysupgrade -T is invoking the same validation script internally, so I wasn't actually performing two independent validation tests.

Regarding the suggestion to wipe the configuration first: I did use sysupgrade -v -n for the 25.12.5 attempt, so the upgrade itself was already instructed not to preserve the existing configuration.

Do you mean that I should first explicitly reset/wipe the 24.10.8 configuration, reboot and confirm that 24.10.8 comes up with a completely clean configuration, and only then attempt the 25.12.5 sysupgrade?

I want to avoid another blind flash because the EA4500 did successfully revert to 24.10.8 after the previous attempt. If there are any specific commands you recommend to verify that the configuration/overlay has really been wiped before attempting the upgrade, please let me know.

I will hold off on another upgrade attempt until I understand this step correctly.

12

I have now performed a second independent test on another identical Linksys EA4500 (Viper), and the result is reproducible.

Testing

EA4500 #1

  • OpenWrt 24.10.8

  • Attempted upgrade to 25.12.5

  • Router failed to remain on 25.12.5

  • Automatically reverted to 24.10.8

EA4500 #2

  • Same EA4500/Viper hardware

  • OpenWrt 24.10.8

  • Performed a factory reset before the upgrade

  • Confirmed the router was running normally after the reset

  • Attempted the same 25.12.5 sysupgrade

  • Exactly the same result: 25.12.5 did not remain booted and the router automatically reverted to 24.10.8

Therefore, this does not appear to be caused by my saved configuration.

Bootloader and partition information

The second router currently reports:

boot_part=2
boot_part_ready=3
bootbadcount=0
bootcmd="run altnandboot"
auto_recovery=yes
enaAutoRecovery=yes

The NAND layout is:

mtd3: 01a00000 00020000 "kernel1"
mtd4: 01600000 00020000 "rootfs1"
mtd5: 01a00000 00020000 "kernel2"
mtd6: 01600000 00020000 "ubi"

The active UBI is:

/sys/class/ubi/ubi0/mtd_num
6

Therefore, the currently running 24.10.8 system is definitely using the second firmware bank.

The OpenWrt 24.10.8 /lib/upgrade/linksys.sh also confirms the dual-bank procedure. When boot_part=2, it changes the boot environment to:

boot_part 1
bootcmd "run nandboot"

and targets kernel1/rootfs1 for the upgrade.

So the expected sequence appears to be:

Bank 2: working 24.10.8
        ↓
upgrade writes Bank 1
        ↓
boot_part=1
        ↓
boot Bank 1 (25.12.5)
        ↓
boot/recovery failure
        ↓
automatic recovery
        ↓
Bank 2: 24.10.8

OpenWrt documentation

The official OpenWrt EA4500 documentation describes the EA4500's dual-firmware arrangement and automatic fallback behaviour after a failed boot.

It also contains an important note for recent OpenWrt versions (24.10 and newer) concerning the EA4500's kernel size and provides a special procedure involving the nandboot and altnandboot environment variables.

This seems particularly relevant because the failure occurs specifically when moving from 24.10.8 to 25.12.5.

Previous EA4500 reports

There are also previous EA4500 reports describing similar behaviour where a newly flashed OpenWrt firmware failed to boot and the Linksys dual-firmware mechanism eventually returned the router to the previous working firmware.

There is also an OpenWrt issue regarding 25.12 release candidates on the EA4500 which reported the router becoming unbootable and requiring recovery through the alternate firmware bank.

Current conclusion

Since the same failure has now occurred on two EA4500 Viper routers, including one that was factory-reset immediately before the upgrade, I don't think this is a configuration problem.

The remaining questions are:

  1. Is there an EA4500/Viper-specific boot problem in 25.12.x?

  2. Is the newer kernel/image layout interacting incorrectly with the original Linksys bootloader?

  3. Does the EA4500 require a special procedure when upgrading from 24.10.x to 25.12.x?

  4. Do the nandboot / altnandboot environment variables need to be changed before the upgrade?

  5. Is there a known working 25.12.x build/procedure for this hardware?

I have the exact openwrt-25.12.5-kirkwood-generic-linksys_ea4500-squashfs-sysupgrade.bin image that I used.

For now I have stopped attempting the upgrade because I don't want to keep triggering the automatic recovery mechanism without understanding the cause.

I would appreciate advice from anyone familiar with the EA4500/Viper bootloader and the 25.12.x upgrade process. In particular, I would like to know the correct and safe procedure for upgrading an EA4500 from 24.10.8 to 25.12.x.

13

I'm not familiar with the device, but could it be that your package list is too big? You might try flashing just the bare bones stock one from downloads, as that's certain to be smaller than one you create with extra packages via any of the ASU clients.

14

Thanks. I did consider the possibility of the image being too large.

However, in this case I used the official stock/bare-bones linksys_ea4500-squashfs-sysupgrade.bin image from the OpenWrt Downloads site rather than an image generated through ASU with additional packages.

I also repeated the test on a second identical EA4500 (Viper). Before attempting the upgrade on the second router, I performed a factory reset and verified that it was running a clean OpenWrt 24.10.8 installation. I then flashed the same official 25.12.5 sysupgrade image, with no additional packages.

The result was identical: after reboot, 25.12.5 did not remain booted and the router eventually reverted automatically to the previous 24.10.8 firmware.

So I think we can reasonably rule out an oversized package list or an ASU-generated image in this particular case.

I still have the exact 25.12.5 .bin file I used, so I can also verify its size, fwtool metadata and image structure if that would be useful.

At this point I'm wondering whether there is something specific to the EA4500/Viper dual-bank bootloader and the 25.12.x image/boot process.

15

Blah, oh well, it was a thought. Definitely need a device expert for this one...

16

Thanks, I agree. The package-size theory can reasonably be ruled out at this point.

I should also add that I have now tested OpenWrt 25.12.1 as well as 25.12.5, and the result was exactly the same: after the sysupgrade, the EA4500 failed to remain on the new firmware and automatically reverted back to 24.10.8.

The 25.12.1 test was also performed with the official bare-bones EA4500 sysupgrade image. So this behavior is not specific to 25.12.5.

Since the same behavior occurs on a second EA4500 after a factory reset, using the official bare-bones images, I think this is more likely something EA4500/Viper-specific.

I also found OpenWrt issue #21452, where an EA4500 (Viper) had a similar failure with the 25.12.0-rc1/rc2 images and recovered through the dual-firmware mechanism.

At this point I am comparing the 25.12.1 and 25.12.5 images and checking the EA4500 NAND/dual-bank layout and boot process before trying anything else.

If anyone familiar with the EA4500/Viper boot process has any suggestions on what to check next, I would appreciate it.

17

Update: EA4500 sysupgrade issue solved by increasing U-Boot NAND read size

I wanted to report back with the results of testing the U-Boot kernel read-size issue on my Linksys EA4500 (Viper).

The original U-Boot environment contained:

nandboot:
nand read.e 0x2000000 0x200000 0x300000

altnandboot:
nand read.e 0x2000000 0x1c00000 0x300000

The newer kernel image was larger than 3 MiB. In particular, the kernel image was approximately 3.18 MiB, so the original 0x300000 read size was not sufficient.

I changed both U-Boot commands to read 4 MiB:

fw_setenv nandboot 'nand read.e 0x2000000 0x200000 0x400000; setenv bootargs $(console) $(mtdparts) $(fs_bootargs_root) serial_number=$(sn) uuid=$(uuid) hw_version=$(hw) device_mac=$(mac) factory_date=$(date) wps_pin=$(wps); bootm 0x2000000;'

fw_setenv altnandboot 'nand read.e 0x2000000 0x1c00000 0x400000; setenv bootargs $(console) $(mtdparts) $(alt_fs_bootargs_root) serial_number=$(sn) uuid=$(uuid) hw_version=$(hw) device_mac=$(mac) factory_date=$(date) wps_pin=$(wps); bootm 0x2000000;'

I verified that both variables were saved correctly.

I then upgraded using:

openwrt-25.12.5-kirkwood-generic-linksys_ea4500-squashfs-sysupgrade.bin

The image SHA-256 was verified before flashing.

The upgrade was successful and the router is now running:

OpenWrt 25.12.5 r33051-f5dae5ece4
Kernel 6.12.94
Target: kirkwood/generic
Model: Linksys EA4500 (Viper)

I also performed additional reboot testing, including an unexpected power-loss reboot. The router came back normally each time.

After the upgrade, the U-Boot environment still shows:

nandboot:
nand read.e 0x2000000 0x200000 0x400000

altnandboot:
nand read.e 0x2000000 0x1c00000 0x400000

boot_part=1
bootcmd="run nandboot"

So, at least on my EA4500, increasing the U-Boot NAND kernel read size from 3 MiB (0x300000) to 4 MiB (0x400000) successfully resolved the sysupgrade failure.

The router is now running OpenWrt 25.12.5 normally.

Thanks to everyone who pointed me in the direction of the U-Boot/kernel size limitation.

18

Second Linksys EA4500 Test – Successful

I repeated the same procedure on a second Linksys EA4500 (Viper) to confirm that the solution was not specific to my first unit.

The second router was initially running:

  • OpenWrt 24.10.8 — r29233-443ec4032a

  • Kernel: 6.6.144

  • Target: kirkwood/generic

  • Model: Linksys EA4500 (Viper)

Before upgrading, I checked the U-Boot environment and found the same limitation as on my first EA4500:

nandboot:
nand read.e 0x2000000 0x200000 0x300000

altnandboot:
nand read.e 0x2000000 0x1c00000 0x300000

I backed up both U-Boot environment partitions:

/dev/mtd1 → u_env
/dev/mtd2 → s_env

The backups were copied to my Windows PC before making any changes.

I then changed both kernel read sizes from 0x300000 (3 MiB) to 0x400000 (4 MiB):

nandboot  → 0x400000
altnandboot → 0x400000

I verified both values with fw_printenv before proceeding.

The MTD layout was also checked and matched the expected EA4500 layout.

I then upgraded using:

openwrt-25.12.5-kirkwood-generic-linksys_ea4500-squashfs-sysupgrade.bin

The image SHA-256 was verified before flashing:

c9e49b545f5c01d8fd0101a67c2a372adf915fc4000a365fc1e5db7d3a0d20fd

sysupgrade -T completed without errors.

The actual upgrade was then performed and the router rebooted successfully.

Result

The second EA4500 is now running:

OpenWrt 25.12.5
r33051-f5dae5ece4
Kernel 6.12.94

After reboot, I verified that the U-Boot changes were persistent:

nandboot     → 0x400000
altnandboot  → 0x400000

The boot slot also switched as expected:

boot_part = 2

This is the second EA4500 on which I have successfully repeated the procedure.

So far, the 4 MiB U-Boot kernel-read adjustment has successfully allowed both of my EA4500 units to upgrade from OpenWrt 24.10.x to OpenWrt 25.12.5 / kernel 6.12.94 without boot failure.

This second successful test gives me considerably more confidence that the original 3 MiB U-Boot read limit was the cause of the boot problem with newer/larger kernel images, rather than a hardware-specific issue with my first router.

I will continue testing both units with multiple reboots/power cycles before considering the procedure completely validated.