TP-Link Archer c2600 v1.0 - Snapshot builds boot looping


I don't know if this is strictly the correct forum. Mods, please move if not.

I have an Archer C2600 v1.0 and have managed to install 19.07.5 on it using TP-Link WebUI ->, OpenWRT CLI sysupgrade ->, Luci sysupgrade -> and TFTP -> All no issues, as long as I stick with release.

My problem is installing/booting snapshot builds. I have tried various snapshot builds from 2020-12-20, 2020-12-24 and 2020-12-28. None of these builds will boot. I've tried going from TP-Link WebUI -> snapshot.factory.img, OpenWRT 19.07.5 Factory.img Luci -> snapshot.sysupgrade.img (both with keep settings and not), TFTP -> snapshot.factory.img, OpenWRT 19.07.5 CLI sysupgrade from factory.img -> snapshot.sysupgrade.img, and OpenWRT 19.07.5 CLI sysupgrade from sysupgrade.img -> snapshot.sysupgrade.img

I am keen to try snapshot as I would like to try using DAWN, which currently only has packages available for snapshot images. My D-Link DIR-882 is on snapshot by default and will load DAWN no problems at all.

In all of the above attempts I have hit the same problem. The router reboots/bootloops constantly. It starts with the internet light coming on orange + solid for about 3 seconds, then all lights come on white + solid for about 3 seconds, then all lights off for about 3 seconds and it loops. I have left it for up to 5 hours.

I have run Wireshark and post snapshot install, the router sends regular ARP requests looking for who has, similar to the TFTP recovery, but it stops short of looking for a TFTP server and just keeps looking for that IP indefinitely. I have set my PC to static, mask and even with TFTPD64 running a DHCP server, it gets replies from my PC, but doesn't try to get DHCP, nor does it try to do a TFTP transfer, just looking for the IP repeatedly.

I can always do TFTP recovery by holding reset either as I turn it on, or as it bootloops. I can always reboot to 19.07.5 without problem post TFTP recovery. I can use Wireshark to watch that it does quite different things once it kicks into TFTP mode, fetching the image, then loading, rebooting and then it switches to and I can reconfigure my Ethernet card to DHCP and pick up an IP Address OK.

Since I have tried going from both the 19.07.5.factory.img -> snapshot.sysupgrade.img and 19.07.5.sysupgrade.img -> snapshot.sysupgrade.img and also TFTP -> snapshot.factory.img from both TP-link firmware and OpenWRT, and also back to 19.07.5 many times, I am pretty confident the router is OK. All attempts to go to snapshot have shown exactly the same result (bootloop, same light patterns, bootloop, rinse and repeat). I have also noted that changes to the kernel partition from 2Mb -> 4Mb occurred in source in 2018, so I don't think that plays into it, since every version I have ever installed will have those changes already built in.

Installing 19.07.5 seems to do the same pattern of lights to a point, but instead of boot looping back to an orange internet light then all lights on and repeat, it reboots only once to the orange internet light, then a flashing white power light, which seems to be the actual boot sequence and then boots the router fully to a constant white power light and ethernet light.

I therefore suspect a problem with the snapshot images themselves.

Any thoughts or suggestions?



1 Like

There's been multiple reports of people having bootloops with a C2600 (I've seen them on IRC and here and here on the forums).

Best thing would be to connect serial and inspect the output. And open a bug report, ideally. I couldn't find any yet, while this has been going on for a few days and been hitting multiple people.

1 Like

The problem is due to this commit below from a few days ago, particularly with the introduction of option CONFIG_CMDLINE_OVERRIDE=y in file /target/linux/ipq806x/config-5.4.

ipq806x: add support for ASRock G10

You can manually edit such file as such to make it work again:


There's a bug report open already.


Could you link to it?

Sure, here it is (reported by @hnyman):

1 Like

Thanks. He encountered the issue on a R7800, so it's not just limited to the C2600. Probably affecting all ipq806x devices.

1 Like

The effects likely vary a bit between ipq806x devices, depending on how the kernel command line gets mangled compared to the normal in each respective device.

Or R7800, the device boots ok, but the serial console is disabled and it is impossible to sysupgrade from an affected build, so you need TFTP recovery flash. (And you can't debug sysupgrade as the serial console is broken :frowning: )

In addition to the bug report above, I also mailed to the developer mailing list a plea to get the offending commit reverted.


There is now a revert for that kernel option.


Thanks everyone for your help. Hopefully that fixes it.

Happy New Year! :wink:

Just a thought. If that patch now leaves the ASRock broken, could it be selectively enabled by something like an ifdef?

In buildbot the same kernel is built for all ipq806x devices. So, all devices share the same ifdefs based on kernel options.

The problem lies somewhere in kernel code, where the introduction of the new symbol (controlling the ifdef) somehow triggers unintentional inclusion of certain strings to the kernel command line, also for devices that do not actually have the devicetree string corresponding to the new option.

1 Like

Tested and sysupgrade worked well from 19.07.5 to Snapshot r15360-57e4cc8261.

Thanks again!

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

This seems to have been fully resolved by;a=commit;h=6230b235b229742bc92a317710ca8e6991b08f47 and then the Asrock G10 support was re-enabled by;a=commit;h=ac25b64350ef2b40bf975e617a3a1b33959a697e

Did a sysupgrade from Snapshot r15360-57e4cc8261 (just after the revert of the buggy patch) to r15403-1b002434f0 (just after fix of the buggy patch) and sysupgrade went OK on my Archer c2600.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.