SRTOOLS

SRTOOLS is a customized disk rescue and recovery environment based on SystemRescue.

SRTOOLS combines a bootable SystemRescue-based environment with auditable tools for building, converting, writing, cloning, and verifying rescue media. It is designed for administrators who need a practical workflow without having to construct complex Linux rescue commands from memory.

Important

SRTOOLS is an independent customization. It is not an official SystemRescue release.

Current release

• SRTOOLS: 1.0.0
• SystemRescue base: 13.01
• Architecture: x86-64 / amd64
• Public edition: Generic

SRTOOLS uses its own semantic version number. Every release also records the exact SystemRescue version used as its base.

Intended use

SRTOOLS is intended for controlled disk-rescue and recovery work, including:

• inspecting storage devices and filesystems;
• preparing reviewed ddrescue workflows;
• creating and verifying raw disk images;
• writing approved SRTOOLS images to USB media;
• cloning a trusted SRTOOLS USB master to another USB device;
• providing a consistent rescue environment for administrators.

SRTOOLS does not decide whether a damaged disk is scientifically, operationally, or legally safe to modify. The administrator remains responsible for identifying the correct source and target devices and for reviewing destructive operations before execution.

Safety model

SRTOOLS follows a strict separation between command generation and destructive execution.

Tools that prepare rescue workflows generate human-reviewable commands or scripts. They do not automatically start destructive disk-recovery operations. The administrator must inspect the complete command sequence, source device, target device, image path, and mapfile path before running it.

Direct USB writing and USB-to-USB cloning are intentional exceptions because those workflows must remain practical. These tools therefore use stronger safeguards:

• explicit source and target summaries;
• mounted-filesystem checks;
• device-size and identity checks;
• confirmation before writing;
• complete readback verification;
• source re-verification after cloning;
• fail-closed handling of mismatches and read errors.

No software process can eliminate the risk of choosing the wrong disk. Always verify device paths, models, sizes, serial numbers, and mount state before approving a write.

Included host tools

Tool	Purpose
tools/build-srtools-vmdk.sh	Builds a new SRTOOLS VMDK from a verified immutable base VMDK and the complete Generic runtime tree.
tools/convert-vmdk-to-raw.sh	Converts an approved VMDK to a fully allocated raw image and verifies source integrity, size, and logical equality.
tools/write-srtools-usb.sh	Writes an approved raw image to a USB device and requires two complete readback verification passes.
tools/clone-srtools-usb.sh	Clones a trusted SRTOOLS USB source to a target USB and verifies both source stability and target equality.
tools/test-*-synthetic.sh	Runs non-destructive synthetic regression tests for the host tools.

See tools/README.md for tool-specific requirements and usage.

Generic runtime tree

The complete public Generic SRTOOLS runtime tree is stored in:

image-root/

This directory mirrors the content installed on the SRTOOLS partition of the image. It contains the administrator tools, autorun scripts, supporting files, and other runtime content needed by the Generic edition.

Keeping the complete tree in Git means that the public image can be rebuilt and audited without extracting scripts from a previously produced disk image.

The VMDK builder is given this directory with:

--build-tree image-root

The build uses rsync --delete, so image-root/ must always contain the complete intended Generic runtime tree, not a partial update or delta-only overlay.

Private organization-specific files do not belong in image-root/.

Build and trust chain

The Generic build path is:

official SystemRescue 13.01 ISO
→ verified bootable base VMDK

verified base VMDK
+ complete Generic SRTOOLS runtime tree from image-root/
→ tools/build-srtools-vmdk.sh
→ Generic SRTOOLS VMDK
→ verified raw IMG
→ verified USB master

The VMDK-to-IMG trust chain is:

VMDK + SHA-256 sidecar
→ verify source SHA-256
→ qemu-img check
→ fully allocated raw conversion
→ verify virtual and raw sizes
→ qemu-img compare
→ verify source SHA-256 again
→ IMG + SHA-256 + conversion record

The USB-master trust chain is:

IMG + SHA-256
→ verify image
→ review target device
→ write image
→ complete readback pass 1
→ complete readback pass 2
→ MASTER PASS

The USB-clone trust chain is:

current trusted SOURCE USB
→ calculate SOURCE checksum
→ write TARGET
→ complete TARGET readback verification
→ verify SOURCE checksum is unchanged
→ verify TARGET checksum equals original SOURCE checksum

Detailed documentation:

• Building the VMDK
• USB production
• Block verification and automount precautions
• Trust and verification
• Release image preparation

Release image

Public release assets are distributed through GitHub Releases as a compressed Generic raw image with separate SHA-256 and release-manifest files.

A release image is prepared from an approved Generic raw image by:

1. making a separate publication copy;
2. zeroing unused filesystem space in the publication copy;
3. checking the filesystems;
4. calculating a new publication-image SHA-256;
5. compressing the image with xz;
6. testing the compressed stream;
7. decompressing it to a separate image;
8. verifying SHA-256 equality and byte-for-byte identity;
9. converting the decompressed image to a test VMDK;
10. completing boot and SRTOOLS functional tests.

Zeroing unused space intentionally changes the whole-image checksum. The publication image therefore has a different SHA-256 from the production master image.

See Release image preparation.

Writing a USB device

Writing a disk image destroys the previous contents of the selected target device.

Before using the USB writer:

• disconnect unrelated removable storage where practical;
• identify the target using its device path, model, size, and serial number;
• ensure none of its partitions are mounted;
• read the final source and target summary completely;
• do not proceed if any detail is uncertain.

Desktop automount services may remount a target partition while recognizable filesystem metadata is being written. The tools do not automatically unmount filesystems or disable system services. See Block verification and automount precautions before production use.

A successful write and readback is not the final acceptance test. Boot the completed USB and verify at least:

boot
copytoram
startx
start
SRTOOLS self-test

Keyboard layout

A temporary console keyboard layout can be selected at runtime, for example:

setkmap fi

Persistent keyboard-layout changes are made through the SystemRescue configuration stored on the USB media. Such a change modifies the whole-device checksum and requires renewed functional acceptance.

See:

• Keyboard layout
• Available keyboard layouts

Raw-image access

Read-only access to raw dd and ddrescue images is part of the planned public scope.

The planned workflow will:

• distinguish whole-disk and partition images;
• enumerate partitions and filesystems;
• mount selected filesystems read-only;
• use noload for ext filesystems where appropriate;
• show the resulting mount path;
• detach mounts and loop devices cleanly.

The original rescue image must never be repaired in place. fsck, TestDisk, and other repair work must use a copy or dedicated work image. A ddrescue mapfile should be preserved beside its image.

Clonezilla-image support is not part of the current public scope.

See Raw-image access.

Repository layout

.
├── README.md
├── LICENSE
├── CHANGELOG.md
├── THIRD-PARTY-NOTICES.md
├── docs/
│   ├── images/
│   └── *.md
├── image-root/
│   ├── admin/
│   ├── scripts/
│   └── ...
└── tools/
    ├── README.md
    ├── *.sh
    └── tools.sha256

Disk images, VMDKs, ISOs, production logs, private overlays, and local release-staging files are not stored in Git history.

Documentation

• Runtime tree and installed tools
• Host tools
• Building an SRTOOLS VMDK
• Trust and verification
• USB production
• Block verification and automount precautions
• Release image preparation
• Keyboard layout
• Available keyboard layouts
• Image access and file extraction
• Troubleshooting
• Source availability
• Third-party notices

Customization

Organizations can build a private customization layer on top of the Generic SRTOOLS base:

public image-root/
+ private organization overlay
→ separate complete organization-specific build tree

Private overlays should be applied to a new build tree or output artifact. They should not modify an immutable approved source artifact in place.

Organization-specific overlays, internal paths, credentials, network-share definitions, and private release images do not belong in this public repository.

License and third-party software

SRTOOLS project files are licensed under the GNU General Public License v3.0 or later unless otherwise stated.

The distributed disk image is based on SystemRescue and contains third-party software under multiple licenses. Each included component remains subject to its own copyright and license terms. SRTOOLS does not relicense SystemRescue or the software packages included in the image.

See LICENSE and THIRD-PARTY-NOTICES.md.