Source: https://mayphus.org/systems-hardware-boot/
Title: Boot evidence and recovery planning
Metadata: {"kind":"page","language":"en","route":"/systems-hardware-boot/","tags":["learning","systems","boot","hardware","recovery"],"type":"page"}

# Boot evidence and recovery planning

[Guide and chapter map](/understanding-computer-systems/) · Prerequisites: [observation](/systems-observation/) and [storage](/systems-storage/)

## Learning goal

Locate the last startup boundary for which there is evidence. Explain why a bootloader prompt, kernel banner, shell, network connection and persistent file are different milestones. Prepare a recovery plan before considering any experiment that could remove remote access.

## Startup is a sequence of handoffs

At a high level, firmware or chip-resident startup code finds the next stage, a loader prepares an operating system, a kernel initializes its environment, and userspace starts. The precise sequence depends on the hardware and OS. A desktop UEFI path is not a universal description of a small ARM board.

On Linux, early userspace may locate and prepare the final root filesystem before handing over to the installed system. The [kernel's initramfs explanation](https://docs.kernel.org/filesystems/ramfs-rootfs-initramfs.html) describes the archive and early init mechanism. FreeBSD uses its own loader and startup sequence, explained in the [FreeBSD boot chapter](https://docs.freebsd.org/en/books/handbook/boot/). U-Boot has board- and command-specific behavior; its [official usage documentation](https://docs.u-boot.org/en/latest/usage/index.html) is a reference, not permission to try arbitrary commands on a working board.

For diagnosis, ask what each observation proves. A loader banner shows that enough earlier stages worked to display it. It does not prove the kernel can start. A shell proves that a kernel and enough userspace worked to run that shell. It does not prove a normal multi-user startup, a working network driver or persistence after power loss.

## Exercise: classify a published boot record

**Environment:** a reading exercise using the published NanoPi R2S records. No board connection, OS command, serial wiring, image write or reboot is required. No new hardware experiment was executed for this guide.

Read [From silent UART to a working NanoPi R2S](/nanopi-r2s-alpine-boot/) and make a four-column note: observation, boundary established, alternative still possible, next check. Use these three points from the record:

1. The original serial path was intermittent in loopback.
2. A replacement serial path worked, but the original SD image targeted a different Rockchip family.
3. The corrected setup displayed U-Boot, continued into Linux and reached Alpine userspace.

An appropriate first row says that the measuring path was not reliable; board failure remains unestablished. The second separates a usable serial path from suitable boot media. The third identifies successively later startup stages. The recorded software identities—U-Boot 2017.09, Linux 6.6.134+ and Alpine 3.23.4—belong to that historical test, not to a recommended current image for every R2S.

The exercise's expected result is a set of bounded claims, not a reconstructed installation recipe. Do not copy a baud rate, pinout or voltage to a different board. Before physical work, obtain the exact board revision's documentation and an appropriate adapter. This guide gives no wiring procedure because its exercise needs none.

## Exercise: separate a RAM shell from persistence

Read the [FreeBSD-in-RAM case study](/entries/nanopi-r2s-freebsd-ram-boot/). Identify the evidence for three different claims: the kernel reached a shell, root was RAM-backed, and a later SD installation preserved a file across reboot.

The record reports a FreeBSD 15.0-RELEASE single-user shell with a read-only memory-disk root and a mount check. The persistence result came from a separate SD test. Do not combine those into “the RAM filesystem survived reboot.” The case study also states that startup required manual U-Boot commands and stopped in single-user mode. It is not a completed, generally supported FreeBSD-on-R2S installation guide.

Then read the limitations of the [USB Ethernet experiment](/nanopi-r2s-freebsd-usb-ethernet/). A successful negotiated link and recorded packet delivery are narrower than measured full-rate throughput or proven USB low-power transitions. Networking results from that later experiment must not be silently added to the earlier RAM-boot proof.

Both exercises were reviewed against the public records. Their hardware results are attributed historical observations, not newly reproduced tests. Your notes should preserve that distinction.

## What a recovery plan must answer

Before a future disposable boot lab, write down how you will reach a local or serial console if networking fails; where known-good boot media and matching components are kept; how you will identify the intended test device; and which evidence means the rollback worked. Check that the recovery materials can be reached without the network interface being tested.

Use a spare device or a deliberately disposable virtual machine when practical. A VM can help study an OS startup, but it does not reproduce a physical board's firmware, power behavior or USB controller. A snapshot is useful only within the virtual platform's actual restore behavior; it does not make writes to a passed-through physical disk harmless.

This chapter intentionally stops before firmware settings, bootloader writes, kernel replacement, partition edits or production reboots. Those require a separate procedure grounded in the exact machine and a recovery path that has actually been checked. Knowing where the evidence stops is part of understanding a system, not a missing final command.