WRT1900ACSv2 trouble booting OpenWrt

The router came with 2.0.3.201002 stock firmware.

I followed the instructions on the wiki. I selected OpenWrt 19.07.7 for installation. The router UI issued the standard warning and disclaimer about flashing non-OEM firmware, but presented me the option to continue. After flashing appeared to finish, the router booted the stock firmware.

@marcwagner had a similar difficulty, with different details. The issue in this case was that the router (hardware v1) had been running v2 firmware, which apparently prevented flashing alternate firmware. Flashing the router with v1 firmware allowed OpenWrt to be flashed.

I suspected that v2 firmware removed support for flashing non-OEM firmware. To test this, I tried flashing v1 firmware (FW_WRT1900ACS_1.0.3.187766_prod.img). This bricked it, perhaps to no surprise since the hardware is not v1. I switched the bootloader to select the alternate partition by doing the power switch dance. So the experiment is inconclusive; I do not know why the router appears to flash a non-OEM image but continues to boot the OEM firmware.

Digging a bit deeper, I noticed that the JavaScript frontend of the web UI validates the firmware filename. The Table of Hardware (ToH) claims that firmware must be named shelby.img, but this is no longer true. The frontend validates the filename against some conditions, one of which is a regular expression:

^.*FW_[^_]+_(\\d+)\\..+$

The OEM-supplied files satisfy this regex. Apparently the validation is used only to warn the user, not to deny flashing non-satisfying filenames. However, even after renaming the OpenWrt image file to satisfy the conditions, the router still boots stock.

Should be no issue flashing OpenWrt. Maybe try flashing again, after it reports success but boot back to OEM, try using the power switch to boot to the other partition, perhaps the environment variables are not getting set.

1 Like

Not at all the case I assure you.

I've done as you suggested, but it is still booting stock. I am unsure whether it is even trying to boot OpenWrt or if it immediately boots OEM. It may be that flashing succeeded but that OpenWrt failed to finish booting, so the bootloader reverts to the alternate.

Without a way to debug the bootloader, it'll be hard to make progress on this. I plan to obtain a serial connection. After I procure that, I'll report what I find.

I occasionally have the same problem on my wrt1200 and just powering off/on once (meaning not the 3x switch to alt partition) after flashing would boot into OpenWrt, no idea if it will work on the 1900, but worth a try (if you haven't already).

I've tried your suggestion, but a single power cycle after flashing still results in OEM booting.

However, after flashing, I carefully watched the LEDs and noticed that they repeated the same blinking pattern three times before the pattern changed and OEM firmware was booted. Thus, my current guess is that OpenWrt is flashing but failing to boot; the bootloader gives it three attempts, then switches to the alternate partition. This suggests I should try a different OpenWrt image which is more likely to boot. However, without knowing why it's failing to boot, I'm not sure what kind of image would be more likely to boot.

Again, it seems that more information is required, so I think getting a serial connection is the next step.

Maybe try a 21.x RC release, or a master snapshot. There is also a community release thread here, and there are master images off the link on my avatar which I am currently running.

1 Like

I tried r15710-f5f01bcacd.i18n/openwrt-mvebu-cortexa9-linksys_wrt1900acs-squashfs-factory.img; doesn't boot. Will try others when I find time.

Using a TTY-USB cable from Adafruit, I captured an incomplete boot log after flashing the 19.07.7 image I originally tried.

I noticed on multiple occasions that the router did not boot with a live serial connection. It booted only when the USB connector was unplugged. This makes it hard to be certain the whole log is being captured. If a complete log is necessary, I'll try again. However, there's a pretty clear error message.

It's failing to mount the root device. A brief search on this error suggests that the image is missing the initramfs.

If you can get the boot stopped you might be able to take a look at the contents of MTD7.

patch, I started putting that in my images at some point (it was not in the one you tried); appears to circumvent (go about it differently) the check, it has not been pushed to master.

@anomeome very interesting. I'll try your latest image next chance I get.

As far as stopping the boot, I assume that would require it calling a debug shell, which means I'd have to build my own image? If not for your images, that's what I would be doing anyway.

You would have to resolve the serial connection issue so you can hit return to stop boot and issue commands at the uboot prompt. Seem to recall having the same issue with a shelby that I owned briefly, resistor???, resolution escapes me at the moment.

The TTY-USB is 3.3V so I'm not worried about voltage levels, but who knows; might need some tinkering.

I'm new to MTDs; would it be possible to inspect the contents of mtd7 in the image itself? I could use radare for that, no need to stop the boot.

Looks like the answer might be yes? I see hits for "mtd", including "mtd7", in the stock firmware. None at all in the 19.07.7 image.

@sblindha had a similar issue, but no resolution.

Here's boot log #2 using r16966-940c196be1.51044/openwrt-mvebu-cortexa9-linksys_wrt1900acs-squashfs-factory.img. This appears to be the full log, but I still wasn't able to interrupt the bootloader. The router still hangs when booting with a live serial connection.

Anyway, looks like the same problem.

Since the apparently corrupted MTD7 is just rootfs2, it seems reasonable to think that if you can get to the uboot prompt you should be able to tftp an image to both partitions simultaneously.

I checked out 19.07.7 in Git and built it according to the beginner's build guide. This image gives the same results.

I searched for the string before mounting root device and it turned up kernel init code, so the patch @anomeome shared seems not relevant? The kernel itself is checking for a magic value. The error is not occurring during an upgrade script.

My next thought is that I need to configure u-boot to go directly to a console and not boot the kernel automatically.

It would be helpful if other WRT1900ACS users could reproduce this problem. I guess many of them did not flash the 19.07.7 image to get OpenWrt on their system; judging by forum activity related to this router, they may have installed OpenWrt at an earlier time, using an older version. I might try that.

My current guess is that the kernel parameters are not right. Per the OpenWrt boot log on the wiki, root=/dev/mtdblock5. This makes sense as it is also declared as "rootfs". Whereas, my image has root=/dev/mtdblock7, which refers to a UBI partition. No other parameters differ, which leads me to believe this change is incorrect. MTD7 is not the rootfs.

To test this, I'll need to change the boot parameters, but I haven't figured that out yet.

Will be dependant on which partition is to be booted, mtd5 ==rootfs1, mtd7==rootfs2

After a conversation with Tusker on IRC, I learned that the suspected reason for hanging when the serial connection is live is that the TTL-USB adapter's pullup resistor has too low a value. I can't do anything about this at the moment, as the solution involves soldering a transistor.

I suspect that all the firmware images I have tried, aside from OEM, assume they are booting from a certain partition, and thus fail to boot when this is not the case. I fixed this problem, therefore, by flashing OEM (overwriting the non-booting OpenWrt image), which causes the router to switch to booting from that partition. Then, I flashed OpenWrt again. It booted without issue.