Topic: recovery
-
A recovery-access checklist before remote changes to boot configuration
Before editing anything that affects how a remote system starts — a boot loader default, a kernel parameter, an fstab entry, a network-dependent unit added to a boot target — confirm a second way in still exists, console access actually works right now, a known-good state can be restored, and a rollback is written down, not improvised after the fact.
-
Booting a rescue or live system and chrooting into an installed Linux to repair it
When a system will not boot at all, the standard recovery path is to boot an independent rescue or live medium, mount the installed root and its related filesystems, bind-mount the kernel's virtual filesystems into it, chroot in to run the installed system's own tools (grub-install, package manager, passwd), then unmount everything cleanly before rebooting.
-
Checkpoint long work at side-effect boundaries
Persist intent and confirmed receipts around external actions so a restarted agent can reconcile uncertain outcomes.
-
Recovery readiness before a hardening change: console access, a backup, a scheduled automatic rollback, and a change log
A methodology for making any hardening change reversible before it is applied: confirm out-of-band access, back up what is about to change, arm a scheduled rollback that fires if nothing confirms success, and log the change — so a network or authentication mistake self-heals instead of requiring a site visit.
-
BitLocker on Windows Server: enabling it, checking volume status, and backing up recovery information before you reboot
The BitLocker feature must be installed before manage-bde or Get-BitLockerVolume exist; a recovery-password protector is what lets a locked-out administrator back in, and it is only durable once it has been backed up to Active Directory or Microsoft Entra ID and confirmed present there before the next reboot.
-
systemd rescue.target and emergency.target: entering them and getting back to normal
rescue.target starts the base system and a single-user shell; emergency.target skips almost everything and starts a shell on the console with the root filesystem possibly still read-only. Both are reached with a systemd.unit= kernel parameter and both require deliberately returning to default.target afterward.
-
Reconciling an interrupted bulk edit from object-level receipts
Resume a bulk edit after a lost response by reconstructing the outcome of each intended object change instead of repeating the entire batch.
-
Rechecking volatile facts when resuming a coding session
Resume an interrupted coding task without treating an earlier session summary as a current observation of files, running processes, or external state.
-
Report partial failure structurally
Return per-operation outcomes and an explicit aggregate state so successful work is not repeated after a mixed result.
-
macOS startup options for administrators: Recovery, Startup Security Utility and Disk Utility First Aid
macOS Recovery (reached differently on Apple silicon and Intel Macs), the Startup Security Utility, Safe Mode and Disk Utility's First Aid together cover most non-destructive recovery on a Mac an administrator physically controls; System Integrity Protection limits what even an administrator process can change outside these paths.
-
Windows boot troubleshooting: WinRE, reagentc and the BCD store
The Windows Recovery Environment provides Startup Repair and a command prompt when Windows fails to boot; reagentc reports and controls whether WinRE is active, and bcdedit reads and edits the Boot Configuration Data store that controls what boots and how — back it up with bcdedit /export before changing it.
-
An opaque response journal for interrupted API writes
Preserve a bounded raw response before parsing it so an unfamiliar or incomplete reply remains evidence for recovery rather than becoming a reason to repeat a write.
Machine-readable: JSON