Testing postmarketOS on a Nexus 7 (2013) Without Flashing It

Published on August 21, 2026

I had a Nexus 7 from 2013 sitting unused in a drawer. The hardware still worked, so installing Linux sounded like a good way to give it a second life.

postmarketOS was the obvious experiment. It supports many old mobile devices, uses Alpine Linux as its base, and documents a port for the Wi-Fi Nexus 7, known as asus-flo.

The experiment did not end with postmarketOS permanently installed on the tablet.

That was the successful outcome.

Instead of starting with a flash command, I treated the installation as an investigation: identify the exact hardware, verify current support, back up the tablet, build a reproducible image, boot it without writing storage, and let the evidence decide whether permanent installation made sense.

Start with the Device, Not the Image

“Nexus 7 2013” is not specific enough. The Wi-Fi model is flo; the LTE model is deb. The postmarketOS wiki treats them differently.

ADB confirmed this tablet as:

manufacturer: asus
model: Nexus 7
device: flo
product: razor
architecture: armeabi-v7a
Android: 6.0.1 (MOB30X)
bootloader: FLO-04.08

The names are easy to confuse:

flo is the hardware/device codename used by postmarketOS.
razor is the Google factory-image product name for the same Wi-Fi tablet.

This mattered later when selecting both the postmarketOS port and the correct Android rollback image.

Current Support Was the First Warning

At the time of the test, postmarketOS listed asus-flo in the testing category. The device package existed in the master pmaports branch, but not in the stable v26.06, v25.12, or v25.06 branches.

That meant:

use postmarketOS edge;
build an image with pmbootstrap;
do not expect a normal prebuilt release image;
expect incomplete hardware support.

The device page already marked display, touch, Wi-Fi, and 3D as unsupported. It also documented an unusual installation requirement: the stock boot partition is too small for the generic kernel, so permanent installation requires lk2nd 23.0 or newer.

Those were not minor caveats. They became explicit stop conditions in the plan.

macOS Could Flash, but Could Not Build

The host machine was an Apple Silicon Mac.

Android Platform-Tools were straightforward:

brew install --cask android-platform-tools

That installed both adb and fastboot natively on macOS.

pmbootstrap was different. Its official documentation requires Linux because it creates and manages Alpine chroots. macOS is not supported.

I installed UTM and created an Ubuntu 24.04 ARM64 VM. The initial 25 GB virtual disk used Ubuntu's default LVM layout, which exposed only 11 GB to the root filesystem. After expanding the logical volume, the VM had enough room for pmbootstrap's chroots, package cache, and generated images.

The final build configuration was:

channel: systemd-edge
vendor/device: asus-flo
architecture: armv7
kernel: apq8064
UI: console
service manager: systemd
lk2nd: 23.1

The apq8064 kernel selection was intentional. Although pmbootstrap offered stable as the default, the device-specific wiki explicitly required linux-postmarketos-qcom-apq8064.

USB Debugging Was Not the First USB Problem

The first cables only delivered power. macOS showed no USB child device at all—not in Android, MTP mode, USB debugging mode, or fastboot.

That distinction was useful. An unauthorized ADB device is an Android authorization problem. No USB device in ioreg or System Information is a lower-level cable, connector, adapter, or port problem.

After changing the cable again, macOS finally detected the Nexus 7 at USB 2.0 speed. ADB reported unauthorized, the tablet displayed its RSA prompt, and accepting it changed the state to device.

Only then did the software investigation continue.

Back Up Before Learning About the Bootloader

Before rebooting to fastboot, I copied the shared storage, recorded device and partition metadata, generated a SHA-256 manifest, and compared streamed source hashes against local files.

I also downloaded Google's official razor factory image matching the installed Android build:

razor-mob30x-factory-52684dff.zip

The archive came directly from dl.google.com, its SHA-256 began with the hash encoded in the filename, and its ZIP structure passed an integrity test.

The bootloader reported conflicting machine-readable values: getvar all said unlocked, while fastboot oem device-info said false. The physical bootloader screen resolved the ambiguity by showing LOCK STATE - UNLOCKED.

No unlock command was needed, and no erase command was sent.

Build Verification Caught a Headless-Recovery Bug

The first image build completed successfully, but verification found that the dedicated SSH public key had not been embedded in the root filesystem.

The cause was configuration timing. pmbootstrap init had recorded ssh_keys=False before the key existed. Adding the key file afterward was not enough; the option also had to be enabled explicitly.

A rebuild then hit a stale loop-partition race under UTM while formatting the generated ext4 image. Rather than hide the failure, I preserved the successful image, added the public key to a working copy, and mounted that corrected image read-only for independent verification.

The verification checked:

the expected SSH key fingerprint;
file mode 600 and the correct user ownership;
enabled sshd;
hostname and timezone;
the selected device, kernel, UI, and lk2nd package versions;
clean loop-device teardown.

This was a useful reminder: a successful build is not the same as a usable recovery path. On a device with uncertain display support, missing SSH access could turn a booting image into an inaccessible one.

Netboot Before Flash

The asus-flo wiki documents netboot through fastboot. That made it possible to test postmarketOS without writing the boot or userdata partitions.

The process required a netboot-enabled initramfs and an NBD server:

pmbootstrap initfs hook_add netboot
pmbootstrap netboot serve --replace

The tablet then received only a boot image in RAM:

fastboot boot boot-netboot.img

Because the NBD server ran inside UTM while USB networking terminated on macOS, I used a temporary SSH port forward between the Mac's 172.16.42.2:9999 USB-network address and the VM's NBD server.

Fastboot accepted and booted the 20 MB image. Within seconds, the tablet appeared as a USB Ethernet device. The NBD client connected, the root filesystem mounted from /dev/nbd0p2, and SSH became reachable at 172.16.42.1.

Nothing had been flashed.

What Actually Worked

The headless system was healthier than the wiki status table suggested:

Component	Netboot result
Kernel	Linux 7.1 booted successfully
Init/system	systemd reached `running`; zero failed units
Root filesystem	ext4 mounted read/write over NBD
USB networking	Working
SSH	Working with the embedded key
Battery	Full, 100%, reporting voltage/current
Display subsystem	DSI connector registered at 1200×1920
Touch controller	Elan input device registered

But registration is not the same as usability.

What Did Not Work

The physical screen remained black and touch produced no visible response.

Kernel logs explained the contradiction between a registered display connector and a black panel:

panel-jdi-lt070me05000: failed to init panel: -22
dsi_link_clk_set_rate_v2: Failed to set rate pixel clk, -22

The system also exposed no Wi-Fi interface and no audio card.

So the practical result was:

display: not usable;
touch: not usable;
Wi-Fi: unavailable;
audio: unavailable;
USB-tethered headless Linux: working.

Why I Chose Not to Flash

A permanent installation would have erased userdata, replaced the boot partition with lk2nd, and removed a working Android installation.

In return, I would have gained a Linux system that required a USB cable and another computer for network access, with no usable screen, touch, Wi-Fi, or audio.

That did not meet the original goal of giving the tablet a useful second life.

I shut the netbooted system down through systemd, stopped the NBD server and SSH tunnel, removed the temporary VM network address, and confirmed that no ADB or fastboot device remained. The tablet's storage had never changed, leaving Android intact for a normal boot.

Lessons from the Experiment

The most valuable part of this project was not the image. It was the sequence of reversible gates.

Confirm the exact hardware codename. Product names are not precise enough.
Read the current device page and package branches. “Supported” can mean “boots in some sense.”
Separate USB enumeration from ADB authorization. They fail at different layers.
Prepare rollback artifacts before bootloader work. Do not improvise recovery later.
Verify generated images, especially remote access. Build success is only one signal.
Use netboot when the device supports it. A RAM-only test can prevent an unnecessary destructive installation.
Define usefulness before flashing. A kernel boot is not automatically a second life.

postmarketOS did exactly what I needed from an experimental mobile Linux distribution: it let me investigate old hardware honestly. The result was not a converted tablet, but it was a confident decision backed by runtime evidence instead of optimism.

As postmarketOS edge evolves, the result for asus-flo may change. For this test, on August 21, 2026, stopping before the flash was the right installation outcome.