Install from USB

Outcome: Create a bootable development stick without modifying internal disks. All data on the selected destination USB device is erased. Unplug any other removable drives before selecting a destination.

Prepare and verify

1. From the download page (newest image, 5db82d6), from huggingface.co/Wa1k3r/LexiSuite (images up to 3db31f8) or the newest release on the Releases page, download LexiSuite-<id>-secureboot-dev.img.xz and its matching .img.xz.sha256 file into one folder (<id> is the commit the image was built from; the newest release has the newest image). Choose an 8 GB or larger USB stick. The image includes no model weights.
2. Identify the entire removable device, not a partition. Writing the wrong target destroys whatever is on it.

Open the stick without booting

Newly assembled distribution images expose a separate LEXISUITE FAT32 volume next to the boot partition. The EFI system partition is for firmware, not for copying the installer to a desktop computer.

The image builder does not create native installer executables: they and the portable program files must already exist in the release's staging directory. The volume contains windows/, macos/, linux/, suite/ and docs/ only when those folders were supplied. The builder creates README.html, MANIFEST.json (build identity, optional pinned source commit, version, relative paths, sizes and SHA-256 digests) and SHA256SUMS. Paths with invalid FAT32 names, symlinks and files of 4 GiB or more are rejected. Large model files belong on LEXIDATA, not FAT32.

From a terminal in the volume's root, run sha256sum -c SHA256SUMS on Linux, or shasum -a 256 -c SHA256SUMS on macOS. On Windows, PowerShell's Get-FileHash -Algorithm SHA256 computes a file digest for comparison with SHA256SUMS or MANIFEST.json. SHA256SUMS covers the manifest and all payload files except itself, since a checksum file cannot contain its own hash. An installer must not be trusted merely because it has a plausible filename; verify the release signature and checksums first.

The USB image also contains a separate, read-only LEXIOS_INSTALL SquashFS partition with the installer source for a live-system install to an internal disk. This is not the same thing as the desktop installers on LEXISUITE. LEXIDATA remains the last partition on disk and is eligible for first-boot growth on the documented single- and dual-kernel layouts.

For image integrators, the development assembly entry point now requires both sources:

lexios-image usb image --kernel KERNEL.EFI --initrd INITRD.CPIO \
  --media-tree ./media-staging --install-tree ./install-staging \
  --out ./lexisuite.img --size 16G --development-only yes

The authenticated A/B release builder accepts the same two source directories and includes both volumes in its partition plan and release receipt, which still needs external signing. Its build-offline.sh wrapper accepts the two directories as its final arguments (or through LEXISUITE_MEDIA_TREE and LEXIOS_INSTALL_TREE). Release publication still requires independent signing and qualification; staging files are not a substitute for a release signature. Set LEXISUITE_BUILD_COMMIT to the pinned 40-character lowercase commit digest for the manifest; when it is absent, build_commit is null rather than an invented commit. The desktop Panel's automatic media-verification interface is separate from the image-builder work and must be integrated before it can automatically report a changed or missing file.

Recommended on Linux — install-to-usb.sh

When the release includes install-to-usb.sh, put it in the same folder and run:

bash install-to-usb.sh --dry-run     # every check, nothing written, no root needed
sudo bash install-to-usb.sh          # writes the newest image in the folder

It verifies the image against its .sha256 file, offers only USB disks, refuses a disk that holds a mounted system folder or is too small, asks you to type the disk's name, writes the image, clears the old backup partition table at the end of the stick, reads the whole image back and compares it, then ejects. You can also name the image and the disk: sudo bash install-to-usb.sh IMAGE /dev/sdX.

Option A — balenaEtcher

1. Select Flash from file and choose the verified .img.xz archive; the application handles decompression.
2. Select the intended USB device, verifying its capacity and identity.
3. Select Flash, approve the disk write and wait until the application finishes its verification/ejection procedure.
4. Safely remove the stick. Do not copy the .xz file onto a normal filesystem expecting it to boot.

Option B — Raspberry Pi Imager

1. Choose the custom image option and open the verified .img.xz archive.
2. Select Storage and verify the intended USB drive.
3. Select Write, confirm the destructive action and allow the operation to finish. The application accepts the compressed image directly.
4. Eject the stick. Do not select unrelated operating system presets.

Option C — Linux command line (dd)

Verify the archive first with sha256sum -c LexiSuite-<id>-secureboot-dev.img.xz.sha256, then identify the device:

lsblk -o NAME,SIZE,MODEL,TRAN,RM,MOUNTPOINTS

Replace /dev/sdX only after independently verifying its model, capacity and removable status. /dev/sdX is a descriptive placeholder, not a real drive to copy literally. Unmount partitions of the selected stick if they were automounted, and check the selected whole-disk destination again. Then run:

xz -dc LexiSuite-<id>-secureboot-dev.img.xz | sudo dd of=/dev/sdX bs=4M conv=fsync status=progress
sync

Because this is a pipe, dd can finish after xz fails. For a safer script, enable set -o pipefail in a Bash shell, and treat any nonzero exit as failure:

set -o pipefail
xz -dc LexiSuite-<id>-secureboot-dev.img.xz | sudo dd of=/dev/sdX bs=4M conv=fsync status=progress

For extra integrity assurance, compare the SHA-256 of the decompressed .img stream with the release's .img.sha256 file before flashing. Do not confuse it with the archive's .img.xz.sha256 digest.

Boot and verify

1. Reboot into the machine's UEFI boot-device menu and choose the USB entry, not the internal system disk.
2. With Secure Boot enabled, the development certificate must first be appended to the trusted db. A refusal before enrollment is expected and protects against unknown signing keys.
3. Choose 1 LexiKernel or 2 LexiOS on Linux 7.4. Start with 2 on a new machine.
4. On first boot the LEXIDATA partition and filesystem grow to fill the stick; this behavior was verified on a physical stick and in a virtual machine.
5. Continue to First Boot and create the administrator account immediately. Enter the setup code if the machine's screen shows one.

Write and boot controls

If a device is not detected, fails to boot, or will not enroll a key, see Troubleshooting, Hardware and Secure Boot.