Why did my Archer C7 v2 brick?


A few months ago, after flashing an update of a openwrt image I compiled, my router (Archer c7v2) became unreachable. Even failsafe mode doesn't seem to work. I consider myself a pretty big newb, but I had been compiling and flashing unstable images about once per month for a year prior to this with no issue, so it was pretty perplexing. It even turned me off the idea of compiling my own firmware for some time, but I decided to jump back into it today with another router - this time it's a stable build

I was just wondering if anyone could provide some insight into what may have happened. From my point of view I followed the exact same procedure as usual. Are there perhaps some common pitfalls of flashing your own firmware that I might not be aware of? Are you kind of playing russian roulette by flashing unstable images or something, and I just got unlucky this time?

I'm not really looking for advice on how to un-brick the other router. I tried TFTP to no avail, and I think I would need to take it apart and do some procedure involving a serial cable, but I can't be bothered.

Any feedback is appreciated!

Older routers tend to have a couple “fatal” problems; power-supply caps failing and, to a lesser extent, flash failure. A serial connection would be how I’d diagnose, if TFTP really didn’t work. On my Archer C7v2 units, it’s been highly reliable, dozens of times over the years.

Thank you @jeff.

So it seems that this might be due to some weird hardware issue, so in other words bad luck. This is the newer of my two Archer c7v2 by a fair amount (the one I am using now is from late 2015), but I guess it might still qualify as old.

Anyway, I'm not sure if that is encouraging or not :slight_smile: but I think I'll keep going with unstable images after I work up a bit more courage. The satisfaction I get out of running the latest software is worth the cost of a bricked router or two.

Thanks again.

1 Like

Never hard-bricked any of my five Archer C7v2 from years of my own builds, including pre-LEDE. It’s pretty bulletproof, if you stay away from writing directly to flash with dd, mtd, or the like. Have fun with it!

While it's rare... building your own ( off development branches ) always carries a risk...

If I really valued a router... I personally wouldn't, without serial and above average confidence in how to recover it.

I'm currently booting off usb for that exact reason...
In the last 18 months;

  • Flashed/built 1000's of times
  • not bootable ~5% of those > all my fault ( although some ath10k crashes have come close )

tftp/initramfs testing for crashes is another "write friendly" method to exclude basic crashes first.

Only recently... i've started to keep an eye on "git log"... as there have been alot of teency fundamental br/target/update-grade tweaks of late....

These potentially break my scripts / cause a make to fail.... but again... it is pretty rare for a device to be zapped by them...

and if it was, it would likely be around an unforseen driver bug and less common the upgrade/upgrade process...

70% of those issues can be resolved on most devices by reading basic docs and using sensible procedure ( do not keep files etc. etc. )

Thanks @anon50098793, much appreciated.

I take it you mean keeping your config files between sysupgrades? Because this is something I always do for sake of convenience. I wondered if this might have played a role in the brick.

I've never looked into this, but it sounds like I should.

Same with this.

I was just thinking about taking the plunge and building another dev branch, but looks like I've got some homework to do.

Incompatible config might cause a loss of connectivity or, in a very, very rare situation, a soft brick. Since the boot-loader and other sensitive partitions are generally read-only in recent OpenWrt images, it seems incredibly unlikely that config caused a hard brick.

:+1: on checking the git commit log. Always good not to build in the middle of a major rework of your target or board!

Ok good to know. I did get myself into the habit of checking the git logs, but I got more and more lax as time went on. I was mostly looking for 'cool new updates' anyway, and I'm not sure if I would have been able to tell that a major rework was underway. Anyway I'll try to keep a lookout for signs of that sort of activity.