Web installer: install and manage Linux on the ZTE F50 / U30 Air from the browser

Before you start

A ZTE F50 / MU300 or U30 Air that is already rooted with Magisk 26 or newer. The page shows whether the device is rooted and what its bootloader says about its lock, and changes neither: it does not root a device and does not unlock a bootloader.
Chrome, Edge or another Chromium browser on Windows, macOS or Linux. Firefox and Safari have no WebUSB.
USB debugging on in Android, the device plugged in, and no other program holding it. A running adb server holds it (stop it with adb kill-server), and so does another browser window that has this page open and is connected.
Best with an internet connection on the device (a SIM with mobile data): the device then downloads the release itself. Without one, you download a file and hand it to the page.
A release from after v2026.10.23: the Magisk zips of older releases do not know this page.

What the page does, and what runs on the device

The page is a small adb client. It talks to the device over USB and does three things there: it puts a few of the project's scripts and the release's Magisk zip on the device, it starts the zip's own installer (the one the Magisk app runs) with your answers, and it shows what that installer prints. The installing, the checks and the order of the writes are the device's, the same as for a zip flashed in Magisk.

Install from a rooted Android: one or two systems, the kernel, internal storage or an SD card, the VPN module.
Manage a device that runs MU300 Linux (with adb on): version, updates, kernel, which system starts, restart, back to Android, logs.
Back up what an installation writes, and uninstall.

It does not shrink Android's data partition on the 32 GB variant (it shows the figures and points to the installer for computers), and it does not grow it back.

You choose the system, the kernel and the release; the page names the file that belongs to that choice and its size, and gets it onto the device without you downloading anything: it asks the device to download the file itself from the project's releases on GitHub, over the device's own internet connection, and shows how far it is. A download that breaks continues where it stopped. That costs the file's size (39 to 124 MB per system) of the device's mobile data, which an operator may charge by volume. When the device has no connection, the page says so and this computer downloads the file from the project's mirror of the release on GitHub and sends it over the cable (GitHub does not let a web page read a release's own files, so the project keeps a copy where a page can). As a last way you download the file yourself and choose it.

Whichever way a file comes, the device uses it only when it has the checksum GitHub publishes for the release, which the browser reads from GitHub directly. A file's integrity comes from that pinned checksum, not from the connection it travelled over: the downloader on the device (Magisk's busybox) cannot verify GitHub's certificate, so nothing is believed because of where it seems to come from. The page also holds a download to the size the release names and stops one that is sent anywhere but GitHub.

If the browser cannot open the device

Everywhere

A running adb server (Android Studio, adb on a terminal, scrcpy, some phone tools) has claimed the device, or another browser window has this page open and is connected to it. Only one program at a time can talk to the device.

adb kill-server, close those programs and that other window or tab, connect again. The page says “another program is using the device” when this is the reason.

Windows

The browser can only use an interface that has the WinUSB driver. Android's adb interface asks Windows for it by itself on most devices; whether the F50 and U30 Air do has not been measured. A maker's own adb driver in its place blocks the browser.

In Device Manager, look at the device's “ADB Interface”. If it has another driver or none, install Google's USB driver (it is WinUSB) or bind WinUSB to that interface with Zadig. Change only the adb interface, not the network or modem ones.

Linux

The device node belongs to root, so the browser may not write to it.

Add a udev rule for adb interfaces, then plug the device in again:

echo 'SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="ff", ATTR{bInterfaceSubClass}=="42", MODE="0660", TAG+="uaccess"' | sudo tee /etc/udev/rules.d/51-adb-webusb.rules
sudo udevadm control --reload && sudo udevadm trigger

A browser installed as a snap or flatpak may need its own permission for USB.

macOS

Nothing to install. Only another program holding the device stops the browser.

Quit that program.

The page says which of these it ran into, as far as the browser tells it.

Managing MU300 Linux: turn adb on first

From the release after v2026.10.23 on, Linux offers adb over the same cable to every computer, and the page can manage it without any preparation. An older Linux has adb off (sudo mu300-usb adb on), and one that was set to authorised keys only lets in just the computers whose adb key it knows; there is no screen to ask on. This browser has a key of its own (the page shows it under “This browser's adb key”). To authorise it, run on the device, over SSH:

echo '<the key line the page shows>' | sudo mu300-usb adb key -
sudo mu300-usb adb on

Whoever holds an authorised key gets a root shell on the device, so authorise only your own browsers and computers.

If the tab closes or the cable comes out

The installation is a job on the device. It does not need this page: closing the tab, a browser crash or a sleeping computer ends the page's view of it, not the job. Connect again and the page shows where it is. A cable pulled from an F50 is a power cut (it has no battery); a U30 Air runs on.

Stopped while	The device then
sending files, working out the plan, building the boot image	Nothing has been written to its storage. It starts Android.
installing the system	An unfinished Linux filesystem that nothing starts. The boot partitions and misc are untouched: it starts Android. Run the installation again.
writing the boot image	Only the Linux slot's boot partition is written, never Android's. The half-written image is not the boot target: the 32 bytes that make the device try it are written last, after the image was read back. It starts Android.
arming (32 bytes of misc)	One small write, read back, and undone if it does not verify. Either Android's block or the Linux trial block is there.
after that	Linux is tried; a Linux that does not finish starting falls back to Android by itself.

Uninstalling goes the other way round: Android is made the boot system first, then the Linux slot gets Android's boot image back, then the Linux filesystem is erased. Whatever stops it, the device starts Android.

What the page sees and keeps

It contacts GitHub's API for the list of releases, and this site for its own files. Nothing else: no analytics, no fonts or scripts from other sites. The release itself is downloaded by the device from GitHub, or by the browser from the project's mirror on raw.githubusercontent.com, whichever you choose.
It never asks the device for its IMEI, IMSI, ICCID or phone number, and never reads the partitions that hold the device's identity and radio calibration.
Serial numbers are shown masked. The log, on screen and in the file you can save, has serial numbers, identity numbers, phone numbers, MAC addresses, passwords and keys masked.
It keeps one thing in the browser's storage for this site: this browser's adb key.

From a phone?

Chrome on Android has WebUSB too, so a phone with an OTG cable could in principle run this page. It is not built or tested for that: the phone would have to power an F50 through the adapter for the whole installation, and the release files would have to be on the phone. Use a computer.