Master producing unbootable ath79 builds

Hi all, building from master is resulting in unbootable firmware for ath79. The compile completes ok and no errors, but the resulting firmware will not boot on the device. I build from fresh clones of master on a regular basis for well over a year and this is my first time seeing this.

Steps to reproduce:

git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
./scripts/feeds update -a && ./scripts/feeds install -a
make clean (select target Ubiquiti UniFi AC Pro)
make defconfig
make download
make

Same thing happens when compiling for target Ubiquiti UniFi AC LR. Compile completes ok but the firmware won't boot on the unit. Tried both via sysupgrade from an older working OpenWrt build and from a factory restore via mtd write. U-boot on both models is where it should according to the device wiki and both units have been running builds from master for months.

Thinking it may have been some issue with the server I use for the builds (Debian 10), I reinstalled it with Fedora 33 and have the exact same problem with it producing unbootable ath79 builds.

Strangely, building from the same clone of master for ramips (mt7621) and x86_64 produces working bootable firmware.

Is anyone else having this issue currently?

I have the same Problem with yesterday master Snapshot release on my ArcherC2600 ( IPQ806x ) that produces a bootloop After sysupgrade from an older Snapshot Version.

Would have to using tftp nethod to downgrade to 19.07.x.

I Would know if the Problem are solved or still exists?

Good to know it's not just me seeing this happening. I should probably mention I first encountered this issue yesterday. Building off master a week ago everything worked no problems for any architecture I was compiling for.

Sven Wegener has submitted this pull request to remediate the issue. Thanks @swegener and Michel Thill!

1 Like

Even with Today Master with this Pull Request i have a Bootloop with my Archer C2600. anyone can confirm this ?

C2600 is ipq8064 and not ath79. The pull request linked to only fixes stuff for ath79 (the only architecture the problem affected). I asked Sven on IRC about it yesterday, and he said there was something different going on with ipq806x.

It looks like it's bad timing, and just coincidence. Your issue is probably a different one. If you have serial, you could have a look at what's wrong and maybe open a bug report.

Edit: you might want to try a build without the offending commit though. I remember someone on IRC saying that did the trick for him, and he was running a C2600 as well.

I see thx for the Info.

I've had the same problem as the OP with both my C7 (ath79) and my C2600 (ipq806x). I couldn't recover my C7 with tftp method and I wonder if it's bricked. As to my C2600, I was able to recover it and just tested again a sysupgrade with the most recent master and the problem still persists.

If you're unable to get into the recovery you'll need serial.

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