The image, flashing, and recovery

The kit's entire operating system lives on the microSD card: bootloader, kernel, our device tree and driver patches, and the WarpKVM daemon. There is no eMMC and nothing baked into the board, which cuts both ways: the card is the single thing that can go wrong, and replacing it is a full repair.

Rewriting a card

Any card of 8 GB or more works. From any machine with a card reader:

1. Format the card with SD Card Formatter.
2. Write the WarpKVM image with balenaEtcher.
3. Insert the card and power on.

Etcher verifies the write, so a card that flashes clean and still does not boot is worth trying in a different reader or replacing; worn cards fail writes silently in cheap readers.

Rewriting the card erases everything on the device, including your account and settings. That is also what makes it the reset of last resort.

What to expect from the storage

Honestly stated, because it is the part most likely to generate a support question:

• The root filesystem is ext4 on the card, with no A/B fallback today. A power cut during a write is ordinarily absorbed by the journal, but a card that does get corrupted is recovered with a card reader and a reflash, not on-device.
• Settings are written atomically (temp file, then rename), so a power cut can lose the most recent change but not the settings file itself.
• On-device updates with an A/B fallback are planned; see the roadmap. Until they land, an update is a reflash.

Buy a decent card if you replace the shipped one. The card is the kit's disk, running a real Linux system, not a camera storing photos.

The clock, and why the console cares

The board has no battery-backed clock, so every cold boot starts with the wrong time until the image syncs over NTP. The daemon refuses to serve TLS with an untrusted clock; it waits, retries, and starts the moment time arrives. On a normal network this costs a few seconds at boot and you never notice.

The consequence worth knowing: on a network with no route to an NTP server, the console will not come up. The device is not dead, it is waiting. Give the management network a time source, or a route to one, and the kit follows immediately.

Serial console

For bring-up, debugging, or watching the kernel boot, the Aura exposes a debug UART on the 40-pin header, at 1,500,000 baud. That rate is the detail that matters: it is not the usual 115,200, and an adapter that cannot do 1.5 M prints garbage.

• Use a CH343, FT232, or CP2102 USB serial adapter. PL2303 and CH340 adapters generally cannot hold this rate; skip them.
• Wire TX, RX, and GND. Pin locations are on the Luckfox pinout diagram.
• 1,500,000 baud, 8 data bits, no parity, 1 stop bit, no flow control.

Recovery modes: the board is not brickable

The RV1126B's boot ROM cannot be overwritten from software, so no state of the microSD card, and no failed flash, can permanently kill the board. Two recovery levels exist below the operating system, both standard Rockchip:

• Loader mode: hold the BOOT button while powering on with the USB-C port connected to a PC. The board enumerates as a Rockchip loader device, and Rockchip's flashing tools (SocToolKit on Windows, upgrade_tool on Linux and macOS) can write storage directly.
• MaskRom mode: the level below that, for a board that will not even reach the loader. On the Aura it is entered by shorting two pads on the board while connecting power; the Luckfox getting-started page shows their location.

For the kit you should never need either: the card is removable, so the entire recovery story is "reflash the card in a reader". The modes are documented because they are the safety net that makes experimenting on the kit consequence-free.