I removed busybox-selinux, thinking it would only be needed if SELinux was enabled. Afterwards, LuCI gives:
Unable to launch the requested CGI program:
/www/cgi-bin/luci: No such file or directory
and OpenSSH gives Connection reset by peer.
Is my router bricked at this point? I can fairly easily reflash via U-Boot, though I don’t have any backups (my fault…).
Probably bricked as there's no default shell now; glad you've got u-boot in your back pocket...
The -selinux variants are just linked against the selinux lib (https://github.com/openwrt/openwrt/blob/main/package/utils/busybox/Makefile#L65), but are otherwise the full suite, so you're not only missing the shell but everything else, too.
Just out of curiosity, did you happen to explicitly install the selinux version, or did you get caught out by our shenanigans a few months ago where the package's "alternative priorities" were screwed up and sometimes you got selinux versions of various things?
I did install the SELinux version, back when I thought that SELinux was actually supported on OpenWRT. It turns out it isn’t, which as someone who has used SELinux professionally was somewhat disappointing.
Would the original squashfs still be there, just without any way to use it? I thought failsafe mode would ignore any user-installed packages.
Yes, if your device is using squashfs.
What is the device in question?
When you remove packages in a squashfs environment, it simply marks them as deleted in the writable partition, but the packages still exist in the ROM partition (I.e. the actual squashfs part).
Yes... failsafe boots a very minimal system purely out of the ROM... so if your device is using squashfs, you should be able to boot into failsafe mode and then reset to defaults (firstboot -y && reboot)
GL.iNet AX6000
That should be using squashfs. So as long as the package removal was done post-flash, failsafe should work (if, on the other hand, you removed BusyBox in a custom image, it wouldn't exist in the ROM; but I think you did this post-flash, right?)
Correct. I actually was trying to see if I could remove enough packages that my image would happen to be one already in cache, so that ASU would work given the server bottleneck. (Hopefully OpenWRT can get sponsorship from a cloud provider for that!)
Next question: how do I enter failsafe mode? I attempted to do it a few times (push the button, set IP address to 192.168.1.10/24, SSH to router) but the router never responded to ARP queries.
Chances of your exact package setup being the same as one in the cache are nearly zero. However, you could simply download a default image and then reinstall your desired packages post-flash.
Did you see the wiki article?
I usually spam the button during the initial booting (immediately after applying power to the device)... you'll see the LED go from a slow flash to a rapid one when failsafe is engaged.
Then, obviously you need to be connected via Ethernet to your router (no other connections; make sure wifi is disabled on your computer, too). Then ssh to the device (ssh root@192.168.1.1).
For failsafe, when booted up, press and hold the restet button for maybe 15 seconds. Then release. It should then reboot to the original image you flashed.
There is also uboot-webui.
For this, unplug the power, press and hold the reset button then powerup while still pressing the button. Wait 15 seconds then let go.
Access the uboot webui on 192.168.1.1.
There are different led patterns for both of these but I forget what they are - I could reset one if it would help.
Unfortuantely, none of those worked. Failsafe mode seems to engage, but the router does not respond to pings.
I think you need LAN port 1 or try all ports
That is wrong advice for failsafe mode. Sounds more like a normal reset during the already operational OpenWrt.
Like said in the wiki, for failsafe a button needs to be pressed during a specific short time window during the boot process. Timing varies by the router model, based on the duration of the early boot process.
Simplest - recommended for most people: Power on the device, wait for a flashing LED and press a button. This can be the WPS, Reset, or other button on the device.
The LEDs provide clues for timing the button press. Watch the LED blinking speeds immediately after powering up the router. Most routers show three different (power) LED blinking speeds during boot:
A power-on sequence of lights that is specific to the device's bootloader
- Then a semi-rapid 5-per-second blinking rhythm during four seconds, while router waits for a button press. Push a button during this blinking
- Then either:
- A really fast 10-per-second blink if failsafe mode was triggered. The device is listening on 192.168.1.1
- A slower, 2.5-per-second blink continuing to the end of normal boot, if the failsafe was not triggered
If you missed the timing and see the slower blink rate, just power off the device, wait a couple seconds, and try again.
Best way is to monitor the LEDs and push a button several times when the blinking change after the early boot process steps. The OpenWrt failsafe mode has a really rapid blinking, so if you succeeded to enter, it should be visible.
It may also vary, which buttons do trigger the failsafe. In principle all buttons work, but depending on the device's hardware and DTS, there may be exceptions.
And like egc says, a wired LAN connection. LAN port 1 is the most commonly working port.
Ah! I've always assumed "failsafe" was the same thing as "factory-reset", but clearly not.
So is it as follows?:
Presumably you mean MT6000.
I regularly use "Factory" and "Uboot-WebUI" on MT6000 when doing dev work.
The procedure I use is to build a custom image with Imagebuilder or Firmware selector with a known good configuration, then work from there, then add more known good changes to the custom image and continue to iterate.
Somewhat so.
But from boot process perspective, the order is actually the opposite...
Early hardware boot process, and it depends on the OEM manufacturer if there is an easy to use process/interface (like e.g. Netgear & Mediatek have), or just default u-boot console (that may also be locked). https://openwrt.org/docs/guide-user/troubleshooting/vendor_specific_rescue
Yeah, it is in the early part of OpenWrt boot, the preinit phase, where kernel is already running but the possible filesystem overlay has not yet been mounted. So, it is just the flashed firmware that is active. The preinit process listens for a button press for 4 seconds. (earlier only 2 seconds until commit https://github.com/openwrt/openwrt/commit/5004f3780de581c7d67c4be0a57833ca1423a021 by me.) Available only in system with rom+overlay filesystem approach, meaning mainly routers with traditional flash.
Actually, press reset button (more tahn 5 seconds) when OpenWrt is already running normally after boot, so that button hotplug scripts are evaluated normally. In practice, it wipes out the overlay, so it is not available in all systems.
Exactly what the OP would need to unbrick.
It probably should be. It certainly is available on all Gl-inet devices afaik.
The OP has an GL-MT6000 and she knows Uboot-WebUI is available.
But the factory reset is a lot quicker. Which one to use depends on what it is you are doing, or have done to brick it and if you are developing and iterating, as I described earlier.
Yes, worth mentioning. But on an x86, RPi etc with storage that is not soldered in, the whole problem is, well, not a problem at all.
Yeah, hopefully it works for the OP.
But from my own experience during the years, messing with busybox itself may render even failsafe unusable in some cases.
Then the http WebGUI from Mediatek would be the best option. I have used it a few times with my own MT6000. (it took me a while to recognize that https does not work with it, as only http is supported)