Mi Router 4A Gigabit Edition stuck in initramfs mode

Hi there ... I think I made a serious mistake by flashing the wrong *.bin file in the process of flashing OpenWrt with OpenWrtInvasion into my router (Xiaomi 4A Gigabit Edition). Not exaclty sure what file I took, but now I have the following situation showing in Luci:

  • OpenWrt 22.03.2 r19803-9a599fee93 / LuCI openwrt-22.03 branch git-22.288.45147-96ec0cd
  • System is stuck in recovery (initramfs) mode.
  • login via ssh possible but: cat /proc/mtd shows no partition at all !!!
  • Firmware upgrade (luci or commandline) has no effect, perorms a reboot but still initramfs mode
  • tried to debricking with TinyPxe on Windows but always ends with the LED flashing in pink color

What I can do is:

  • ssh onto the router and
  • it basically brings me online
  • thats it.

I have no idea what to do now and how to recover this device.
Is there a way of 'rebuilding' the required mtd partitions?

Any help is appreciated ...

Root shell exploit for several Xiaomi routers

~ From - https://github.com/acecilia/OpenWRTInvasion

@acecilia - is this official-OpenWrt-related?

@lleachii AFAIK it's an exploit to get OpenWrt running on those devices, not some fork or OEM SDK derivative.

1 Like

Yea, I understood that part. From what I read:

  • It's an "exploit" on the OEM firmware

For more info and support go to:

You try there?

(it's over 2000 posts...wow)

BTW - welcome to the community.

1 Like

You are right, that is probably a better thread to ask Xiaomi stuff. Thanks guys, I will ask there.

(the thread is closed, you're good here)

1 Like

Thanks for the nice welcome. Awesome community here. :slight_smile:

1 Like

Where did you get the files from, there's V2 model that's only just got support in snapshot releases.

What's the model number on the bottom of the router?

1 Like

Model: R4A

Well, I took the file that was on my Desktop because I (successfully) flashed another Xiaomi 4A Gigabit Edition some weeks ago but I renamed it openwrt.bin at that time so maybe there was my fault. From the filesize I recon it was not the squashfs file and then the trouble began. (trying to fix it the whole day)

The good thing is, whatever I tried for the last 12h it didn't get worse at least. OpenWrt starts every time but in recovery mode only. The device connects properly to the internet as soon as I connect the WAN cable. Sure it has forgotten all the settings I made after a boot.
I tried via WebUI-Flash-image and via sysupgrade when connected via ssh without any visible effect, so I am stuck on OpenWrt 22.03.2 (initramfs) I just have no idea what else I could try ...

An initramfs implies booting from RAM, that needs to be fed to the device in some way. It sounds like your device is just getting stuck in cold boot, which would suggest it's not finding the rootfs?

Can you pastebin dmesg output? If you can SSH in you can copy things over.

Sure thing, here you go: https://pastebin.com/uzEbuYYG

1 Like


[    4.307592] spi-mt7621 1e000b00.spi: sys_freq: 220000000
[    4.314423] spi-nor spi0.0: unrecognized JEDEC id bytes: 1c 71 18 1c 71 18
[    4.321311] spi-nor: probe of spi0.0 failed with error -2

You should thank yourself that you flashed the initramfs version of OpenWrt, so you can login after boot instead a bootloop! :upside_down_face:

By the way, you are hit by issue 9442:

Which was fixed on master then backported to 22.03 (released as 22.03.3) and to 21.02 but the latter isn't released yet, so you have to use 21.02-SNAPSHOT builds if you need to stick to that oldstable release!

1 Like

I see two solution only:

  1. serial access to your router, and
    • boot an OpenWrt SNAPSHOT or 22.03.03 of initramfs.bin through TFTP
    • do a simple sysupgrade with the same version of OpenWrt but now with a sysupgrade.bin
    • changing bootloader to a third party bootloader (at least for temporary)
    • flashing the correct version of OpenWrt
    • (optional) rollback to current bootloader
    • (if you mess up something you only way is #2)
  2. reprogramming your flash with an SPI programmer

Ok, there could be a third solution, but it depends on the bootloader your device has:
If it does support your CF EON flash chip you could use it's recovery function:

  • OEM booloader (an U-Boot) supports TFTP recovery, but accepts only stock firmwares
    • I have no access to a stock firmware which contains an U-Boot which supports this new chip and it's TFTP recovery isn't bugged! :see_no_evil:
  • BREED bootloader (third party BL, use the breed-mt7621-pbr-m1.bin edition) has nice HTTP GUI for recovery
    • newer versions support your flash chip
  • updated U-Boot by @db260179 (you should self-build it for now), it also has a nice HTTP GUI for recovery
    • the support was committed to the repository but no new release was made

Oh no ... I was hoping not to climb down so deep into the rabbit hole, but what the heck, it's fun right? So I have a serial adapter at hand, but no spi programmer. (which I am willing to order if neccessary)
Even though the device is brand new and I could just send it back, but nope thats not me ... I won't give up that easy! Btw. thanks everbody for all your help, really apprecite it. :slight_smile:

Given my USB zu TTL Seriell Adapter is there anything usefull I could try before ordering an spi programmer? How do I convince my device to boot the initramfs.bin you mentioned? Usefull tools (Linux/Windows doen't matter) for that task? Does the present bootloader give me an option to do that? Sorry for asking basic stuff, but I do consider myself in the group of beginners ...

Before attempting the flashing bootloader, connect the serial adaptor to your router board.

Get a serial program running like putty, then connect up, turn on router and if u can capture the putty output to a log file for us to see.

If you did the openwrt invasion part correctly, u should be able to hit enter to set u-boot commands, if not - 1. reflash the oem firmware back or 2. spi programmer read the flash chip (sometimes works, sometimes doesnt without removing the chip from the board)

My gitlab https://gitlab.com/db260179/openwrt-base/-/tree/openwrt-22.03-mt7621 has folder called docker, in there is a docker container that can boot images as its a TFTP,dhcp and dns all in one server. You will need to get your own oem firmware as your board has the new EON chips my example firmware has only support for the GIGA flash chips.

Did you do this part when doing the openwrtinvasion part?

nvram set uart_en=1
nvram set boot_wait=on
nvram set boot_delay=5
nvram commit

if not, you will need reflash to oem firmware and do the hack again, making sure you do the above part so you can enter the u-boot command line from the serial console aka putty

1 Like

Use the wiki to learn how to open the case, but you need to peel off the product label to unhide the screws.

Okay, device opened an here is a picture and the pastebin link: https://pastebin.com/N8GJm94u

Do I have to order the spi programmer yay or nay?

Press (and hold) 4 when / before the menu shows up:

Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.

If you are able to enter the U-Boot prompt, then help or ? to get help.
If you are unable to enter the U-Boot prompt, then you missed the serial access parameters setup, see below:

You could set those params from OpenWrt too with fw_setenv. Ahhh!!! fw_setenv won't work as the flash is unkown currently. :frowning:

1 Like

Hm ... not sure. I am at the console (root@OpenWrt:/#) after 10 seconds or so.
You are right: /bin/ash: fw_setenv: not found

I executed that script: remote_command_execution_vulnerability.py
during the process 2 days ago. That did not set those variables, right?