Usage

Every real use of Bootscry on a real machine, including failures and manual steps. Mock runs are not listed here. Repeatable tests are on the evidence pages.

How this table is made

Rows are added by hand today, which means they can drift or miss a use. Later, a script will build this table from usage logs that every command and session writes, so a row will not depend on someone remembering to write it.

Recorded uses, oldest first

This is one operator's lab. It is a record of use, not a success rate. A market claim with no row here behind it is only a goal (see where this is going). Some uses are not in the ledger yet and are listed as gaps in the project repository. Machines are described by kind, not by lab name. No addresses or secrets appear.

Date	Target	Task	Class	Highest tier	Outcome	Human steps	Evidence
September twenty-ninth, 2026 (operator account)	A NAS	Boot loop after a vendor update, headless	Rescue	Not recorded (before the MCP server)	Recovered, per the operator and the field manual. One incident, not a rate.	The operator started the session and was asleep for the fix. Details are limited to the manual.	NAS recovery record
September thirtieth, 2026	A test machine with an AMI Aptio BIOS	Reach BIOS setup by tapping Delete through boot, then exit with Discard Changes	Inspect	Power	One successful run. A second capture the same day ended with the operator leaving setup by hand. No success rate.	The operator pressed Escape and Enter in the second capture.	boot-menu catch record
October first, 2026	A Foxconn NetBox	Unattended Debian thirteen install to SSD, then to SD card, then a rescue card	Install	Media, power	The SSD install was verified, with twenty-one of twenty-six checks passing the first time. The second install hung at the end.	One cold boot by a person.	install and rescue record
October second, 2026	The standing test PC and a second machine	Boot the fleet rescue card through the Comet and receive a deliberate kernel panic as text	Rescue	Media, power	Booted and checked.	Not recorded on the summary.	Summarised in the install and rescue record.
October second, 2026	The standing test PC	MCP server read-tier session against real hardware	Inspect	Read	Ran. The input, media and power tiers were not run on hardware.	Not recorded.	No public page yet.
October second, 2026, early	The standing test PC	One-shot boot into the rescue card, then back to the installed system	Rescue	Read (no key or media action in the audit)	The audit holds frames and notes covering the running system, the one-shot reboot and the return. A commit records the one-shot as proven. The note does not say which channel ran the reboot commands.	Not recorded.	No public page yet.
October second, 2026, early	The standing test PC	Read the BIOS submenus, change nothing, leave with Discard	Inspect	Input	Key presses and frames were logged. A commit records the submenus as read.	Not recorded.	No public page yet.
October second, 2026, late	The first ODROID-M1S board	First look, then a clean reboot to read the board model from its boot messages	Inspect	Input	The vendor Ubuntu login was read. The board was identified from the boot screen, to be confirmed by eye, and came back after the reboot.	Not recorded.	No public page yet.
October third, 2026	The Comet itself, with a USB stick in its port	Test whether a thirty-two gigabyte stick can be the Comet's permanent image store	Experiment	Media, power (a KVM reboot, not a target)	Worked once: the stick was kept by its identifier, survived a KVM reboot, and upload and delete were tested. Defects: a switch-partition call timed out and its revert returned a busy error, though the final state matched the baseline; a slow write was resent by the client and later fixed. One run, no rate.	Not recorded. The stick was in the Comet, not on a target.	No public page yet.
October third, 2026	The first ODROID-M1S board	Boot the verified Armbian image presented by the Comet as a USB drive	Experiment	Media, input	Failed as an install route. Ctrl+Alt+Del did not reboot the board twice; the magic keys did, into the vendor Ubuntu again, with no Armbian text in any frame. The board's bootloader does not boot a USB drive presented by the Comet by default. The drive was ejected afterwards.	Not recorded.	No public page yet.
October third, 2026	The first ODROID-M1S board, vendor Ubuntu	Four read-only checks: do keys reach the console, is the microSD card seen, then log in and list disks	Inspect	Input	A typed character echoed at the login prompt, so keys reach the console with the drive attached. Disk listings were read from the screen. The maker's default login was used and its value is not recorded here.	Not recorded.	No public page yet.
October third, 2026	The first ODROID-M1S board	Boot with the Armbian SD card in: warm, cold, and cold with the card out as a control	Experiment	Input	The Armbian trunk image froze on the SD card. The card and slot were proven good. The cold boot with the card in produced no-signal entries and no picture.	Not recorded. The card handling is not logged.	No public page yet.
October third, 2026	The first ODROID-M1S board	Deliver a device tree with a PHY address fix to Armbian through the Comet's virtual drive, in four boots	Setup, experiment	Media, input	Ended with Armbian running from the SD card after three fixes. Two of the four boots logged a no-signal entry. Per-boot results are in transcripts, not summarised here.	Not recorded.	No public page yet.
October third, 2026	The first ODROID-M1S board	ARM rescue test: a blank card in the slot, does the board still boot its eMMC	Experiment	Read	Passed. The vendor Ubuntu login came up from the eMMC.	The operator swapped the cards and powered the board.	No public page yet.
October third, 2026	The first ODROID-M1S board	Watch the first boot of Armbian from the eMMC with the SD slot empty	Install	Input	Armbian came up on the console with automatic root login. The image was byte-verified, per the tracker. The eMMC write itself ran over ssh, not through the Comet.	The operator powered the board.	No public page yet.
October third, 2026	The second ODROID-M1S board	First look, then a cold boot with the card out to see what is on its eMMC	Inspect	Read	The card boot showed an Armbian console. The card-out boot showed an Android-style screen, matching the tracker's note that the vendor eMMC has the Android layout. The real MAC address was read from the router, not from the Comet.	The operator moved the Comet, pulled the card and cycled power.	No public page yet.
October fourth, 2026	An ODROID-M1S on the Comet (which board was the question)	Take one frame to see which board the Comet was attached to	Inspect	Read	One frame, one audit entry. The result is not recorded in the session folder.	Not recorded.	No public page yet.
October fifth, 2026	The two ODROID-M1S boards	Armbian to eMMC, rescue card hand-over, and a watchdog experiment	Setup, experiment	Media, power	Both boards were brought up. The hardware watchdog reset left one board dark until power was cycled by hand.	A manual power cycle.	board bring-up record
October fifth, 2026	A Libre Computer Le Potato board (model from the operator's listing, not read from the board)	Read-only look at what the Comet shows from an Android board, and try keyboard navigation to its About page	Inspect	Input	The screen showed Android with a recorder app and a root access notice. The About page was not reached: keyboard navigation gave no usable focus. That this board is the one on the Comet rests on timing and the switch port, not proof. No audit file exists.	The operator pasted the product listing.	No public page yet.
October ninth, 2026	A mini PC used as a jumpbox	Read-only BIOS pass to check power-loss behaviour	Inspect	Input	Frames with OCR text and an audit log were captured. Nothing was saved. Setup was left with Discard Changes and Exit.	Not recorded.	No public page yet.
October ninth, 2026, later	A mini PC used as a jumpbox	Apply three BIOS changes (power-loss wake behaviour, Secure Boot, and the setup prompt timeout), save once, then a second read-only pass	Setup	Input	Saved through the Save and Exit dialog, which is on record. The second pass matched the target table, Windows booted with Secure Boot on, and the host answered. Two waits for a login phase ended not found.	Not recorded.	No public page yet.
October fifteenth, 2026	A Raspberry Pi host	The operator moved the host to another router and lost ssh. A firewall rule was typed at the console through the Comet to restore access.	Rescue	Input	Ssh worked again, checked from another machine. One rule was typed but not checked separately. Defects: one snapshot call failed on a usage error; one call put a password variable name on the command line and the tool warned; the Comet reported the mouse offline. The password feature was written in the same session, shortly before its first use. No audit file exists for this use.	The operator did the physical move and had lost ssh. Whether the operator tried anything else first is not recorded.	No public page yet.
October sixteenth, 2026	The Comet itself	Check that the MCP server starts against the real Comet after a missing setting in the operator's environment was fixed.	Inspect	Read	The server started and listed its tools. The Comet reported its signal and keyboard online. No screen content was read and no input was sent.	The operator asked for the fix. No other human step.	Console output only.
October sixteenth, 2026	A Sipeed NanoKVM Mini the operator plugged into a Raspberry Pi host	Find the new unit on the network so it can become the second KVM that bootscry supports.	Setup	None	The unit was found from the router lease list and its web page named it. Its API refused requests without a login, so nothing past identity was read. The operator then agreed to a fixed address on the router. No driver exists yet and nothing has been driven through this unit.	The operator plugged the unit in and agreed to the fixed address.	Console output only.

Considered and left out

These were not counted as uses of Bootscry. A repeat of the same install is not a second use. Boot tests and video renders on a lab server touched no real device. Building rescue cards on another host, ssh and card work with no Comet record, router and network tooling, and ssh cleanup after the console fix are not Bootscry work. Mouse and typing test suites are tests, and stay on the evidence pages.

The ledger also lists gaps: some rows are thin, a few Comet sessions may be missing, and the first September session is only partly recorded.

Review measured evidence Read the threat model