A live USB lets you start Linux on another computer, but an ordinary session often loses installed applications, settings and files after a reboot. DistroClone USB creates persistent media from a compatible desktop ISO, so you can return to your working environment and carry files in a dedicated Shared folder.

This guide covers version 0.3.1, available on GitHub. It is the graphical companion to distroClone for ISO creation and distroclone-backup for backup and recovery. The interface supports English, Italian, Spanish, French and German.

English interface with a SysLinuxOS ISO and a demonstration USB. The /dev/sdz device shown is a test example.

Requirements and compatibility

Create the USB on an amd64 Linux host compatible with the Debian package, with a GTK desktop and a polkit authentication agent. APT installs the required ISO, filesystem, GRUB and encryption tools. Store the input ISO on your computer or another drive, never on the target USB.

SysLinuxOS and Debian Live: compatible live-boot images; documented verification covers SysLinuxOS 13.2 MATE.
Ubuntu desktop and Linux Mint: recognized casper profiles, without encryption; booting real distribution images still needs specific validation.
Boot: Legacy BIOS and unsigned x86-64 UEFI. Secure Boot must be disabled.
Excluded: MX/antiX, installer-only images, Ubuntu Server, ARM and IA32-only UEFI.

The drive must have room for the ISO, boot area and selected persistence space. The application checks capacity before creation.

Install the Debian package

Download distroclone-usb_0.3.1_all.deb from the 0.3.1 release, open a terminal in the download directory and run:

sudo apt update
sudo apt install ./distroclone-usb_0.3.1_all.deb
distroclone-usb

Use APT so the dependencies are installed too. This guide uses the GitHub release download; adding the SysLinuxOS Tools repository is not required.

On SysLinuxOS, open SysLinuxOS Tools → DistroClone USB. Run the window as your normal user. Administrative authentication is requested when the helper needs to write the USB.

Create the USB step by step

1. Live ISO: choose the desktop ISO. Wait for profile detection and review the displayed information.
2. USB drive: select the device explicitly. Check its model, capacity and serial number. Use Refresh after connecting it and Unmount volumes if the desktop has mounted it.
3. Persistence: set the GiB reserved for applications, settings and files. Shared uses this space too.
4. Security: choose an encryption mode and enter and confirm the passphrase when required.
5. Create USB: review the summary, type the exact device name requested and approve the operation in the system authentication dialog.

All existing data on the selected USB is erased. Back it up before proceeding. The application rejects internal drives and devices in use, but checking the selected target remains essential.

The original ISO is copied intact and verified with SHA-256. It is stored on ext4, so files larger than 4 GiB are supported. Wait for completion, then eject the drive through the desktop.

Choose the encryption mode

Encryption requires a compatible Debian Live/SysLinuxOS ISO. The application checks the required initramfs capabilities before writing the drive. Encrypted creation is unavailable for Ubuntu and Mint.

Use a long, unpredictable passphrase of at least 12 characters. Full encryption requires ASCII characters and uses the US keyboard layout during early boot. Letters, digits and spaces reduce keyboard-layout differences. This tool cannot recover your data if you forget the passphrase.

The persistence volume uses LUKS2 with Argon2id. In full mode the ISO volume uses PBKDF2 so GRUB can unlock it. Both volumes share the same passphrase, which matters for resistance to offline attacks. The small boot area stays readable and is not authenticated.

Boot and check persistence

Restart the computer, open the firmware boot menu and choose the USB. GRUB offers persistent, temporary and safe-graphics sessions. Select the persistent session to keep your work.

With persistence-only encryption, Linux requests the passphrase for a persistent boot. Full encryption asks first in GRUB and then in Linux. Three failed attempts at the Linux prompt stop unlocking; reboot to retry.

Create a small file in Shared, change a setting and reboot into the persistent session again. Check that both remain. A persistent live USB is not a full installation: kernel and initramfs upgrades are not guaranteed to take effect after reboot.

Shared: carry files between Linux systems

In a persistent session, Shared is available in the live user’s home and at /Shared. On another Linux system, mount the persistence volume, unlocking it first if encrypted, and copy your files into its Shared directory. Do not put them in the boot area or volume root expecting them to appear in the live home.

Shared uses persistence space; it is not a public FAT/exFAT partition, and Windows cannot read ext4 natively. Do not edit the internal rw, upper or work directories by hand. A temporary session does not expose encrypted persistent Shared.

Cancel creation and reuse a drive

Cancel requests a stop and cleanup of mounted filesystems and encrypted volumes. Wait for cleanup to finish before unplugging the drive. An interrupted USB may be incomplete and must be recreated.

Creation uses quick formatting. It does not overwrite the whole device or sanitize previous data in unused sectors. Encryption protects newly written contents; this operation is not secure erasure. Existing USBs are not converted or encrypted in place while preserving files. Back up your data before recreating the drive.

Read-only commands and troubleshooting

These commands list devices, inspect an ISO, show a plan and check dependencies without writing the USB. Replace the example path and device:

distroclone-usb --list-devices
distroclone-usb --inspect /path/to/live.iso
distroclone-usb --plan /path/to/live.iso --device /dev/sdX --persistence-mib 4096
distroclone-usb --check-dependencies

Drive unavailable: unmount its volumes and check that swap, RAID or device-mapper is not using it.
Insufficient space: reduce persistence or choose a larger drive.
ISO rejected: check its family and structure; select no encryption for Ubuntu/Mint.
USB does not boot: check that Secure Boot is disabled, the firmware selected the USB and the BIOS/UEFI mode is compatible.
Files disappear: choose the persistent session and use Shared for files transferred from another Linux system.

Downloads and documentation

Repository and source code
Release 0.3.1: Debian package, source archive and SHA256SUMS
ISO compatibility
Shared and encryption details

Distributed under GPL-3.0-or-later. Code and original logo: Franco Conidi.

DistroClone USB persistent live USB sharing and encryption

share

L'articolo DistroClone USB persistent live USB sharing and encryption proviene da SysLinuxOS.

Version 2026.10.1 is available for SysLinuxOS 13 and Debian 13, with a window, a notification-area icon and a command-line tool. The interface supports English, Italian, French, German and Spanish and follows the session language. It is written from scratch for SysLinuxOS, inspired by AnonSurf but sharing none of its code.

SysLinuxOS Anonimo with protection on

How it works

Anonimo does not change your existing network setup. When you switch it on it adds its own nftables table, inet anonimo, and starts its own Tor instance (syslinuxos-anonimo-tor.service). When you switch it off the table is removed and the network is exactly as before.

ufw, Docker and libvirt rules: never touched.
System Tor: /etc/tor/torrc is left alone.
DNS: /etc/resolv.conf and NetworkManager are not edited; DNS is redirected to Tor by the firewall.
If Tor stops: traffic to the Internet stays blocked instead of leaving in the clear.
If nftables is reloaded: anonimo’s table is loaded again at once. After loading nftables rules by hand (nft -f), run anonimo start again.

Requirements

SysLinuxOS 13 or Debian 13 (or a derivative) with a graphical desktop and a polkit authentication agent in the session, which MATE and GNOME normally include. The APT package brings Tor, nftables, obfs4proxy, Python, PyQt5 and pkexec. It was tested on SysLinuxOS 13 with MATE, GNOME and GNOME Classic; it has not been tried on plain Debian or on Ubuntu.

Install from the APT repository

If the SysLinuxOS Tools repository is already configured, run:

sudo apt update
sudo apt install syslinuxos-anonimo

To add the repository, follow the official instructions. The quick method uses the official script to configure the APT source and signing key:

curl -fsSL https://fconidi.github.io/SysLinuxOS-Tools/client/install-repo.sh | sudo bash
sudo apt update
sudo apt install syslinuxos-anonimo

Once the repository is configured, subsequent updates are delivered through APT.

Install the Debian package

Alternatively, download syslinuxos-anonimo_2026.10.1_all.deb from the 2026.10.1 GitHub release, open a terminal in the download directory and run:

sudo apt install ./syslinuxos-anonimo_2026.10.1_all.deb

Use apt rather than dpkg so the dependencies come along. The package also recommends snowflake-client, bleachbit and a polkit agent.

Notification-area icon on GNOME

GNOME has no notification area of its own. To see anonimo’s icon you need the AppIndicator extension, and on GNOME it is mandatory. On SysLinuxOS and Debian it is called ubuntu-appindicators@ubuntu.com, not the identifier used on the upstream site:

sudo apt install gnome-shell-extension-appindicator
gnome-extensions enable ubuntu-appindicators@ubuntu.com

On Wayland, after the first installation, log out and back in. Without the extension anonimo still works, with the window only, and closing the window quits the program. On MATE the icon appears with no extra steps.

How to use it

Open SysLinuxOS Anonimo from the SysLinuxOS Tools menu. The window shows the state and three buttons: switch on or off, New identity (new Tor circuits for new connections) and Check Tor (asks check.torproject.org whether traffic really goes through Tor). The same colour appears on the icon:

Grey: off.
Yellow: connecting.
Green: protected.
Red: error.

SysLinuxOS Anonimo switched off, with its settings

From a terminal:

anonimo start
anonimo status --check
anonimo identity
anonimo stop

anonimo status exits with 0 when protected, 1 on error, 2 while connecting and 3 when off. At the end of anonimo start it checks with check.torproject.org that traffic goes through Tor and exits with an error if it does not.

Settings

Direct local network: on by default, it keeps printers and NAS reachable by IP address. For anonimo the local network is 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, fe80::/10 and fc00::/7.
Bridges: for networks that block Tor. With obfs4, enter the lines you get from bridges.torproject.org in Edit obfs4 bridges, or from a terminal with anonimo bridges --set FILE. Snowflake uses the default addresses of Tor Browser.
Switch on automatically at boot: loads the firewall at boot, before the network comes up.
Close network applications and clean caches: on by default. At every switch on and off it closes network programs and runs BleachBit, which also deletes browser history and form data, as AnonSurf did.

The same settings are available from the terminal, for example anonimo settings --lan off --bridges obfs4.

What does not work while it is on

UDP to the Internet (online games, video calls), IPv6 to the Internet, device discovery (.local), Docker containers and virtual machines.
Services of this computer (SSH, web server, file sharing) cannot answer hosts outside the local network.
Connections to the Internet already open when it switches on are cut.

Good to know

With the direct local network option on, anything sent to a host of the local network leaves outside Tor: a local HTTP or SOCKS proxy, DNS over TLS or over HTTPS to the router or a Pi-hole, a gateway. If everything must go through Tor, switch the option off.

With snowflake bridges the bridge program sends its own DNS queries and its STUN/WebRTC traffic outside Tor: someone watching the network can tell that you use snowflake, as with Tor Browser, but not what you visit.

Firefox blocks .onion names by default. To open .onion sites use Tor Browser, or set network.dns.blockDotOnion to false in about:config.

If the network stays blocked

To get the normal network back:

anonimo stop --no-close-apps
anonimo settings --boot off

If anonimo does not respond, this command removes the table for the current session only:

sudo nft delete table inet anonimo

With start at boot on, the table is loaded again at every boot until you run anonimo settings --boot off. With start at boot off, a reboot always brings the normal network back.

Debian’s Tor and removal

On the first installation, if /etc/tor/torrc was not modified, Debian’s default Tor service (tor.service) is disabled, because anonimo has its own. To remove the program:

sudo apt remove syslinuxos-anonimo

apt remove leaves tor.service disabled; only apt purge syslinuxos-anonimo enables it again.

Code and feedback

The code, the changelog and the list of what was verified are in the GitHub repository. The program is free software, GPL-3.0 or later. For reports and questions open an issue on the repository.

SysLinuxOS Anonimo secure internet browsing

share

L'articolo SysLinuxOS Anonimo secure internet browsing proviene da SysLinuxOS.

This guide covers SysLinuxOS Boot Repair 0.3.1 for amd64, available through the SysLinuxOS Tools APT repository. Version 0.3.0 was tested successfully from SysLinuxOS Live; version 0.3.1 adds integration with the SysLinuxOS Tools menu while keeping the repair helper and graphical interface unchanged.

Original boot recovery illustration; this is not an application screenshot.

When to use SysLinuxOS Boot Repair

The tool can help when GRUB no longer appears, the computer drops into a GRUB console, the menu no longer reflects the installed system, or the bootloader needs reinstalling after changes to the disks. These symptoms can have different causes, so identify the installation and the required action before writing to disk.

Boot Repair handles GRUB recovery for an existing SysLinuxOS installation. It does not fix failing hardware or damaged filesystems, reinstall the operating system, or recover deleted partitions. If a drive reports read errors or files are missing, securing the data and diagnosing the storage should come first.

Supported configurations

A partition appearing in the list does not mean it is eligible for repair. Inspection must confirm that it contains SysLinuxOS, that the root matches fstab, and that the layout is supported.

1. Boot the Live USB in the correct firmware mode

Prepare a SysLinuxOS Live USB and boot the computer from it. Run the repair from the Live session, rather than the installed system being repaired. Before proceeding, have an up-to-date backup of important data and identify the connected drives.

The Live session’s firmware mode must match the installation. Reinstalling UEFI GRUB requires a Live session booted in 64-bit UEFI mode, with EFI variables accessible. A Live session booted in Legacy mode cannot correctly register the corresponding UEFI firmware entry.

From a terminal in the Live session, check its current boot mode:

if [ -d /sys/firmware/efi ]; then
    echo "Live session booted in UEFI mode"
    cat /sys/firmware/efi/fw_platform_size
else
    echo "Live session booted in BIOS/Legacy mode"
fi

For UEFI, this utility expects the value 64. This check describes the running Live session; it does not by itself establish how the installation on disk was configured. If needed, reboot and choose the appropriate USB entry in the firmware’s boot menu.

2. Install Boot Repair in the Live session

With SysLinuxOS Tools already configured and a network connection available:

sudo apt update
sudo apt install syslinuxos-boot-repair

If the repository is missing from the Live image you are using, follow the official SysLinuxOS Tools repository instructions. To configure it with the official installer and then install the package:

curl -fsSL https://fconidi.github.io/SysLinuxOS-Tools/client/install-repo.sh -o /tmp/syslinuxos-install-repo.sh
less /tmp/syslinuxos-install-repo.sh
sudo bash /tmp/syslinuxos-install-repo.sh
sudo apt update
sudo apt install syslinuxos-boot-repair

The repository uses suite tirreno, component main, architecture amd64, and GPG-signed indices. Check the installed and candidate versions with:

apt policy syslinuxos-boot-repair

This guide describes version 0.3.1. If the repository offers a later version, also review its changelog. On a Live USB without persistence, packages installed in the current session generally do not remain available after a reboot.

Installing from a local package

You can also copy the package to the Live environment and install it from the directory where it was saved:

sudo apt install ./syslinuxos-boot-repair_0.3.1_amd64.deb

The .deb does not bundle every dependency. If dependencies are missing from the Live environment and there is no network connection, obtain them beforehand. Installing Boot Repair changes the Live environment; the subsequent repair acts on the selected installation on disk.

3. Open the interface and identify the root partition

Open SysLinuxOS Tools in the applications menu and choose SysLinuxOS Boot Repair. Alternatively, launch it from a terminal:

syslinuxos-boot-repair-launcher

The GUI runs as the desktop user. Operations requiring privileges go through the administrative helper. Live sessions normally provide passwordless sudo; otherwise, an authentication dialog may appear.

The partition list shows the device, size, filesystem, label, disk, state, and mount locations. To compare the devices from a terminal:

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS

Select the installed SysLinuxOS root partition, rather than the Live USB, @home, or the EFI System Partition. For Btrfs, the utility looks for the root in the @ subvolume. If several installations are present, carefully verify the selected system and the devices shown in the plan.

4. Choose an operation

Inspect only is selected by default. Start there even if you expect to reinstall GRUB: it lets you check the system before choosing an operation that writes to disk.

5. Review the plan and confirm the repair

Click Review plan. The helper inspects the selected installation read-only and reports its root, any separate /boot, boot mode, and EFI partition. For an encrypted root, the plan also identifies the decrypted mapping and its backing LUKS container.

For BIOS, reinstallation targets the whole disk containing the selected root, such as /dev/sda, rather than /dev/sda2. Check the actual destination in the plan, especially when multiple disks are connected.

For UEFI, the EFI System Partition is found through the installed system’s /etc/fstab. Do not choose an arbitrary FAT partition: check the detected partition and confirm that the Live session has UEFI access.

For repair operations, click Confirm repair only after reviewing these details. Cancel is the default button. Inspection alone does not offer a repair confirmation. The helper validates the devices again before execution.

Wait for the result and read Details. Before a repair, an existing grub.cfg is copied to a grub.cfg.syslinuxos-backup.* file in the same directory. This backs up the GRUB configuration; it is not a disk image or a complete system backup.

LUKS roots and partitions that are already mounted

LUKS partitions remain visible whether locked or already unlocked. When you select a locked container, the GUI lets you enter its passphrase in an unlock dialog. Unlocking uses UDisks2 and may also request administrative authentication. The passphrase is not passed in command arguments or saved to disk.

An already unlocked or mounted root can be selected directly when its layout is supported. Boot Repair uses private mounts and removes the helper’s mounts when it finishes; the user’s original mounts and open mapping remain available.

The helper validates the container against the installed system’s crypttab. This accommodates different mapping names in the Live and installed environments, but it does not bypass an inconsistent configuration. LUKS headers, keyslots, crypttab, and initramfs are preserved.

When /boot is inside the encrypted root

If /boot is inside the encrypted root, GRUB must be able to read the container before loading the kernel. After confirmation, Boot Repair enables GRUB_ENABLE_CRYPTODISK=y through a dedicated GRUB defaults file.

With stock GRUB, a LUKS2 container holding /boot needs a compatible PBKDF2 keyslot. A layout containing only Argon2 keyslots is rejected before repair. The utility does not convert keyslots or modify the header to work around this restriction. A separate, unencrypted /boot avoids this specific limitation. LVM inside LUKS remains unsupported in the version described here.

Btrfs, snapshots, and rollback

Boot Repair works on the active @ root and preserves @home, @/.snapshots, Snapper configuration, and rollback backups. It does not restore snapshots or rerun snapshot setup.

Menu regeneration invokes the GRUB scripts already installed in the target system. If snapshot integration is installed and working, those scripts participate in the regeneration. Bootloader repair and snapshot rollback are separate operations: use Boot Repair for an issue with booting, and assess rollback separately when the problem concerns the installed system’s state.

Using the terminal workflow

To open the interactive workflow in your current terminal:

syslinuxos-boot-repair-launcher --cli

The following commands are examples. Replace every device path with the one verified on your own computer. To inspect a root and, if appropriate, regenerate its GRUB configuration:

sudo syslinuxos-boot-repair --plan --root /dev/nvme0n1p2
sudo syslinuxos-boot-repair --config --root /dev/nvme0n1p2

For a UEFI reinstall, boot the Live session in 64-bit UEFI mode and ensure the installed system’s fstab correctly identifies its EFI partition:

sudo syslinuxos-boot-repair --reinstall --root /dev/nvme0n1p2

For a BIOS reinstall, also specify the whole disk containing the root:

sudo syslinuxos-boot-repair --reinstall --root /dev/sda2 --disk /dev/sda

In the CLI, unlock a LUKS root first. --root accepts its open mapping or the physical LUKS partition once its direct mapping is available. If the existing mapping is actually named /dev/mapper/cryptroot, an inspection example is:

sudo syslinuxos-boot-repair --plan --root /dev/mapper/cryptroot

Terminal repairs require the entire confirmation line shown by the helper, including the literal word REPAIR in every language. Do not reuse a confirmation from another machine: it contains the current operation’s devices. In the GUI, the explicit confirmation button supplies this same confirmation to the helper.

Interface language

The interface and helper follow the Live session’s language, with English, Italian, German, French, and Spanish support. English is the fallback when the session language is unsupported. To explicitly open the GUI in English:

syslinuxos-boot-repair-launcher --language en

Output from system commands, including GRUB tools, may retain those programs’ own language settings.

Troubleshooting

The application requires SysLinuxOS Live

Reboot from the Live USB. Running the application in the installed system does not provide the recovery environment expected by the helper.

The root is not recognized or does not match fstab

Check that you selected the SysLinuxOS root rather than a home partition, another system, or the Live session itself. For Btrfs, verify that the layout uses @. Do not change UUIDs or configuration files merely to bypass the check; establish the actual partition layout first.

UEFI errors or inaccessible EFI variables

Check how the Live session was booted. UEFI reinstallation requires 64-bit UEFI mode and accessible EFI variables. Boot Repair does not implement a dedicated Secure Boot configuration or signing workflow; Secure Boot problems require separate investigation.

update-grub or grub-install is missing from the installed system

The utility uses the selected installation’s tools and does not install packages inside it. An installation with missing or damaged GRUB packages therefore needs appropriate manual recovery. Reinstalling Boot Repair in the Live session does not restore those files on the target system.

A repair ends with an error

Read and save Details before trying again. A repair may have partially completed: GRUB installation might have succeeded while menu regeneration failed. An error does not automatically undo earlier writes. The grub.cfg backup is not a complete rollback mechanism.

Checks after the repair

After a successful result, close the application and reboot, removing the USB when prompted. Verify that the firmware selects the correct drive, GRUB displays the expected entries, and SysLinuxOS boots completely. If a snapshot menu was configured, check that it is present.

On a dual-boot machine, also check the other entries without assuming reinstallation guarantees detection of every operating system. If SysLinuxOS reaches GRUB but fails while loading the kernel or mounting the root, the cause may involve components Boot Repair does not rebuild, such as initramfs or the installed system’s configuration.

The final check is a real boot of the computer. A completion message reports the outcome of the executed commands; it does not replace that check.

References

For further reading about manual recovery on the same system, see Restoring GRUB on SysLinuxOS with Btrfs subvolumes and Restoring GRUB on SysLinuxOS with LUKS encrypted partitions. Manual procedures require checking the actual layout and should not run concurrently with Boot Repair.

Official SysLinuxOS Tools repository and APT setup
SysLinuxOS project, Live distribution, and documentation
Debian Wiki: GRUB EFI recovery
Debian Wiki: using chroot

For documentation included in the package:

man syslinuxos-boot-repair
man syslinuxos-boot-repair-launcher
less /usr/share/doc/syslinuxos-boot-repair/README.md

SysLinuxOS Boot Repair Guide to GRUB Recovery from Live USB

share

L'articolo SysLinuxOS Boot Repair Guide to GRUB Recovery from Live USB proviene da SysLinuxOS.

Version 2026.10.3 is available for SysLinuxOS 13 and Debian 13. The interface supports English, Italian, French, German and Spanish, automatically following the desktop session language.

What it is for

Use the application to locate a concealed access point, observe how reception changes as you move through a room and distinguish radios sharing a network name. The target is selected by its BSSID, the identifier of an individual radio. One physical access point can expose several BSSIDs across different bands.

The Signal window shows received signal strength in dBm, an analog gauge, the strongest recorded sample and recent history. Beeps become more frequent as the signal grows stronger, allowing you to follow changes without constantly watching the screen.

The application does not calculate distance or direction. Obstacles, metal surfaces and reflections can shift the strongest-signal location. Use the results to narrow the area to inspect above a ceiling; they cannot guarantee the correct individual panel.

Requirements

You need SysLinuxOS 13 or Debian 13 with a graphical desktop, a WiFi adapter recognized by iw and a polkit authentication agent in your desktop session. MATE and GNOME normally include one. The APT package handles the Python, PyQt5, multimedia, iw and pkexec dependencies.

A dedicated USB WiFi adapter may provide steadier scanning while your main adapter maintains its connection. The application does not change adapter mode or disable NetworkManager.

Install from the APT repository

If the SysLinuxOS Tools repository is already configured, run:

sudo apt update
sudo apt install syslinuxos-wifi-analyzer

To add the repository, follow the official instructions. The quick method uses the official script to configure the APT source and signing key:

curl -fsSL https://fconidi.github.io/SysLinuxOS-Tools/client/install-repo.sh | sudo bash
sudo apt update
sudo apt install syslinuxos-wifi-analyzer

Once the repository is configured, subsequent updates are delivered through APT.

Install the Debian package

Alternatively, download syslinuxos-wifi-analyzer_2026.10.3_all.deb from the 2026.10.3 GitHub release. Open a terminal in the download directory and run:

sudo apt install ./syslinuxos-wifi-analyzer_2026.10.3_all.deb

Launch and start scanning

Open the application from the SysLinuxOS Tools menu or launch it from a terminal:

syslinuxos-wifi-analyzer

Run it as your normal desktop user. Only scanning requires administrator authentication through polkit; the interface and audio remain in your user session.

1. Choose the adapter. Select your WiFi adapter, click Start scan and confirm the authentication prompt.

2. Choose the radio. Identify the BSSID of the access point you want to follow. Avoid relying only on the network name when several devices share the same SSID.

3. Open Signal. Select the radio and click Signal…. Scanning focuses on the target frequency and opens the gauge and history window.

Reading signal strength and using beeps

dBm readings are negative: −50 dBm is stronger than −80 dBm. The peak records the best raw sample received; the gauge, history and beeps use a lightly smoothed signal.

Select Enable beeps, adjust the volume and click Test audio to check your audio output. The tone stays at 880 Hz; its cadence changes from one beep every 2.2 seconds to about six beeps per second.

Walk slowly, keeping the receiver at a consistent height and orientation. When you reach a strong-signal area, cross it again from a perpendicular direction. Click Reset peak at the beginning of a new pass. Select Near the AP sensitivity to distinguish variations in already strong signals.

Close Signal to return to discovery across all channels. If the access point changes channel, find it again in the refreshed list.

Try it without hardware

syslinuxos-wifi-analyzer --demo

Demo mode uses simulated radios and signal changes. It lets you try the interface, filters, gauge and audio without performing real scans or requesting privileges.

Troubleshooting

No adapter detected: check the connection and driver. Run iw dev to list recognized interfaces. If WiFi is disabled or blocked, enable it in desktop settings.

No authentication prompt: check that a polkit authentication agent is running in your graphical session. Cancelling authentication prevents the scanning session from starting.

Beeps pause: the application pauses audio when the target disappears, a scan fails or no fresh sample arrives for four seconds. This avoids guiding you with stale readings. A busy adapter or slow scans can also produce pauses.

Stopping takes a moment: each iw invocation has a 15-second timeout. Stopping or closing the application may wait for that invocation to finish.

Source code and license

The project is developed by Franco Conidi and distributed under GPL-3.0-or-later. Its BSS parser is derived from Sparrow WiFi by ghostop14; the interface, tracking, audio and packaging are dedicated to SysLinuxOS Wifi Analyzer.

Source code and IT/EN documentation: GitHub repository.
Packages: GitHub releases.
APT installation and updates: SysLinuxOS Tools.

SysLinuxOS Wifi Analyzer Installation and Usage Guide

share

L'articolo SysLinuxOS Wifi Analyzer Installation and Usage Guide proviene da SysLinuxOS.

Installing NVIDIA drivers on Linux always means the same checks: which GPU you have, whether it needs the open or the proprietary kernel module, whether the headers match the running kernel, and what to do about Secure Boot. SysLinuxOS NVIDIA Setup automates all of it on SysLinuxOS 13 and Debian 13 amd64: a Bash script with a YAD graphical interface and a terminal alternative. Source code: github.com/fconidi/syslinuxos-nvidia-setup.

1. What it does

It detects NVIDIA GPUs (including hybrid laptops), picks the right module from NVIDIA’s official JSON database and installs the driver through APT using signed repositories. CUDA is optional. It asks for administrative privileges only at install time, never restarts the computer and never touches Secure Boot.

2. How the driver is chosen

Modern GPUs that support the open kernel module use NVIDIA’s Debian 13 repository with nvidia-open and nvidia-kernel-open-dkms. GPUs that need the proprietary module use Debian’s nvidia-driver and nvidia-kernel-dkms, with an extra nvidia-detect check. Unknown GPUs and legacy branches older than 580 are reported without forcing anything. The two channels are never mixed, CUDA included.

Headers must match the running kernel: the script does not install or select another kernel. Debian’s 550 drivers are blocked on kernel 6.19 and newer, including SysLinuxOS kernel 7.0, so you need to boot a compatible kernel before retrying.

3. Install from the APT repository

The package is distributed through the signed SysLinuxOS-Tools repository. After setting it up with the linked instructions:

sudo apt update
sudo apt install --reinstall yad syslinuxos-nvidia-setup
syslinuxos-nvidia-setup --check --cli

The repository also works on Debian 13 amd64: the tirreno suite only identifies this extra repository, while Debian’s own repositories stay on trixie. --check shows what would be done without installing anything, without root and without changing the system.

4. Graphical use

In the MATE menu open Applications → SysLinuxOS-Tools → SysLinuxOS NVIDIA Setup. Installing the package does not start any driver installation. In the window choose Driver only or Driver + CUDA, then authenticate: downloads, installation and DKMS compilation continue automatically. The interface supports English, Italian, Spanish, German and French and follows the session language.

5. Terminal use

./syslinuxos-nvidia-setup.sh --cli                 # asks whether to install CUDA
sudo ./syslinuxos-nvidia-setup.sh --cli --no-cuda  # no prompts
sudo ./syslinuxos-nvidia-setup.sh --cli --cuda     # includes CUDA

The portable version needs YAD and pkexec for the GUI: sudo apt install yad pkexec.

6. Secure Boot and verification after restarting

With Secure Boot enabled, if the module signing key is not enrolled the installation ends with exit code 20 and MOK instructions. With the standard DKMS configuration:

sudo mokutil --import /var/lib/dkms/mok.pub

Set a temporary password and restart. In the firmware screen choose Enroll MOK → Continue → Yes and enter the password. After restarting:

nvidia-smi
lsmod | grep nvidia
dkms status
nvcc --version   # only if CUDA was selected; open a new terminal

The CUDA Version field in nvidia-smi describes driver compatibility, not an installed toolkit: use nvcc for that.

7. Logs and removal

The administrative log is /var/log/syslinuxos-nvidia-XXXXXXXX.log. APT, DKMS and initramfs errors stop the operation, but the installation can be partial: there is no automatic rollback. To remove only the utility:

sudo apt purge syslinuxos-nvidia-setup

Drivers, CUDA and APT configuration stay installed. If graphics problems occur, boot a working kernel from the GRUB menu or use a text console, read the log and plan the package removal through APT.

Autoinstall NVIDIA Drivers and CUDA on SysLinuxOS 13 and Debian 13

share

L'articolo Autoinstall NVIDIA Drivers and CUDA on SysLinuxOS 13 and Debian 13 proviene da SysLinuxOS.

On SysLinuxOS 13 Docker ships in the ISO, but docker.service may fail to start and end up in failed state. The fix that worked was to completely remove the Debian packages and reinstall Docker Engine from Docker’s official repository, following the guide at https://docs.docker.com/engine/install/debian/. Here are the steps, adapted to SysLinuxOS.

1. Check what is installed

See whether the installed packages come from the Debian repositories (docker.io) or from the Docker repository (docker-ce):

dpkg -l | grep -Ei 'docker|containerd|runc'

2. Remove the Debian packages

Remove every package that conflicts with the official Docker Engine:

sudo apt purge docker.io docker-compose docker-doc podman-docker containerd runc

sudo apt autoremove --purge

Existing images, containers and volumes live in /var/lib/docker and /var/lib/containerd and are not touched when packages are removed. If you do not need them and want a clean start, delete them by hand. Warning: this cannot be undone.

sudo rm -rf /var/lib/docker /var/lib/containerd

3. Add Docker’s GPG key

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

4. Add the repository with the trixie suite

The official guide reads the suite name from /etc/os-release. On SysLinuxOS 13 the VERSION_CODENAME field is tirreno, which does not exist on Docker’s repository, so apt update would fail. SysLinuxOS 13 is based on Debian 13, so the suite to use is trixie, written directly in the file:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: trixie
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc
EOF

If the file already exists and contains tirreno, replace it with trixie:

sudo sed -i 's/tirreno/trixie/' /etc/apt/sources.list.d/docker.sources

5. Install Docker Engine

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

The package installs and starts the service automatically.

6. Verify it works

sudo systemctl status docker
sudo docker run hello-world

If you see the message Hello from Docker!, the installation is correct.

7. Run Docker without sudo (optional)

sudo usermod -aG docker $USER

Log out and back in so the group takes effect. Keep in mind that members of the docker group effectively have root privileges on the system.

Conclusion

With the official repository you get up-to-date Docker Engine, containerd, Buildx and Compose, managed by apt like any other package. Source: https://docs.docker.com/engine/install/debian/.

Docker on SysLinuxOS 13 from the official repository

share

L'articolo Docker on SysLinuxOS 13 from the official repository proviene da SysLinuxOS.

The SysLinuxOS 13 desktop: syslinuxos-ring-conky in the middle, syslinuxos-conky-window on the right side.

The ring theme: syslinuxos-ring-conky

It is a fork of Auzia Conky (GPL-3.0) with auto-scaling: the scale factor is min(width/1920, height/1080), clamped between 0.5 and 3.0, so at 1920×1080 the layout is identical to the original and on other resolutions it stays proportional. It shows a ring for every CPU core (the core count is detected at boot), CPU and GPU temperature when available, the heaviest processes, RAM and swap, the clock, a disk ring with read and write activity, network traffic and totals, the connection details (interface, SSID, signal, local IP, gateway) and the battery, which only appears if the machine has one.

The disk ring shows a single “Root+Home” ring when / and /home are on the same file system, as with the btrfs subvolumes of SysLinuxOS. The network card follows the default route and is re-checked every 10 seconds, so switching from Wi-Fi to cable needs no restart.

The per-core rings adapt to the thread count: for 2, 4, 6, 8, 10 and 12 threads the hand-tuned layouts are kept, for any other count, such as 16, 20 or 32, the layout is computed with a formula, with one ring per thread and the percentage labels thinned out so they never overlap.

The side panel: syslinuxos-conky-window

The panel takes the right-hand side of the desktop and groups the information into sections: SYSTEM (release, kernel, user, uptime), CPU (model, temperature turning orange above 70°C and red above 85°C, one bar per thread), TOP (the heaviest processes), MEMORY (RAM and swap), FILE SYSTEM and NETWORK (local and external IP, provider, speed, totals and graphs).

The layout adapts to the thread count: up to 6 threads the bars fit in one column with three processes in TOP, from 7 to 12 they go in two columns and above 12 in three or more columns (at most 8 rows), and in that case the TOP section is dropped, since the ring already lists the heaviest processes, so the panel never runs off the screen. The CPU temperature, GPU and fan rows only appear when the machine exposes those values. A row named after the distribution (SYSLINUXOS on SysLinuxOS, DEBIAN on Debian) summarises pending APT updates, failed systemd units and, when the user can read them, the number of snapper snapshots. Here too / and /home become a single row when they share the file system, and the network card is re-read every 10 seconds.

A privacy note: the external IP and the provider are fetched with curl from api.ipify.org and ipinfo.io, so the panel makes those two outbound requests.

Installation

With the SysLinuxOS APT repository (if it is not configured yet, the official script adds it):

curl -fsSL https://fconidi.github.io/SysLinuxOS-Tools/client/install-repo.sh | sudo bash
sudo apt install syslinuxos-ring-conky syslinuxos-conky-window

The panel used to be called conky-window. Anyone with the old package is migrated by apt upgrade thanks to a transitional package with the same name. Paths and scripts did not change, so the menu entries, commands and variables stay the same. The dependency is conky-all; for a complete result you also want lsb-release, curl, lm-sensors and the X11 tools x11-utils and x11-xserver-utils, which the package recommends and apt installs by itself.

Usage

The entries are in the Applications menu, under System Tools: Conky-ring-start, Conky-ring-stop, Conky-window-start and Conky-window-stop. From a terminal:

/opt/scripts/conky-ring-start.sh
/opt/scripts/conky-ring-stop.sh
/opt/scripts/conky-window-start.sh
/opt/scripts/conky-window-stop.sh

To start them automatically at every login, copy the entries into the session autostart folder:

mkdir -p ~/.config/autostart
cp /usr/share/applications/conky-ring-start.desktop /usr/share/applications/conky-window-start.desktop ~/.config/autostart/

Useful variables

Set them in front of the start command. CONKY_RING_SCALE and CONKY_WINDOW_SCALE force a scale factor different from the one computed from the resolution, CONKY_NET_INTERFACE pins a network card instead of following the default route.

CONKY_RING_SCALE=1.5 /opt/scripts/conky-ring-start.sh
CONKY_WINDOW_SCALE=1.2 /opt/scripts/conky-window-start.sh
CONKY_NET_INTERFACE=eth0 /opt/scripts/conky-window-start.sh

In the panel, the two graphs at the bottom of the NETWORK section stay tied to the network card detected at startup: if you switch cards while it is running, speed and totals follow, the graphs do not, until you restart it.

What about Debian?

The two packages do not depend on SysLinuxOS components. I tried them on a clean Debian 13: installation from the repository, with the recommended dependencies, and start of both on an X11 session. I have not verified Wayland sessions, such as the default GNOME on Debian: conky runs there only through XWayland and the “below other windows” placement and transparency may not work. To remove them: sudo apt remove syslinuxos-ring-conky syslinuxos-conky-window.

Sources and releases on GitHub: syslinuxos-ring-conky and syslinuxos-conky-window.

Conky themes for SysLinuxOS: syslinuxos-ring-conky and syslinuxos-conky-window

share

L'articolo Conky themes for SysLinuxOS: syslinuxos-ring-conky and syslinuxos-conky-window proviene da SysLinuxOS.

Recovery guide for a SysLinuxOS system installed on a LUKS-encrypted partition that no longer boots because GRUB is corrupted, overwritten, or was never installed correctly. This is the natural follow-up to Restoring GRUB on SysLinuxOS (btrfs with subvolumes): here the btrfs root lives inside a LUKS volume, so it has to be unlocked before the @ subvolume can be mounted.

When you need this

• The PC shows error: no such device or drops into a grub> rescue shell, and the installed system uses LUKS for the root filesystem.
• Another OS (e.g. Windows) was installed after SysLinuxOS and overwrote the boot loader shared on the ESP.
• The ESP (EFI System Partition) is shared between several installs and needs to be rewritten without losing the other NVRAM entries.
• A kernel or GRUB update was interrupted midway on a system with an encrypted root.

Prerequisites

A bootable SysLinuxOS Live USB (MATE or Gnome). The cryptsetup package must be present on the Live (it is, by default). You need the LUKS passphrase of the volume you’re restoring.

1. Unlock the LUKS volume to restore

Identify the encrypted partition with lsblk -f (it shows up as crypto_LUKS), then unlock it:

sudo cryptsetup luksOpen /dev/sdXN sdXN_crypt

sdXN_crypt is an arbitrary mapper name for this recovery session only: it doesn’t need to match what’s in the installed system’s /etc/crypttab. The decrypted volume shows up at /dev/mapper/sdXN_crypt.

2. Mount the btrfs root subvolume (@)

sudo mkdir -p /mnt/sdXN_crypt
sudo mount /dev/mapper/sdXN_crypt /mnt/sdXN_crypt
sudo btrfs subvolume list /mnt/sdXN_crypt   # check the root subvol's name (@)
sudo umount /mnt/sdXN_crypt
sudo mount -o subvol=@ /dev/mapper/sdXN_crypt /mnt/sdXN_crypt

Just like in the non-encrypted case, the chroot only works when you explicitly mount subvol=@, not the top level (subvolid=5).

3. Mount the ESP and the bind mounts

If the ESP is shared with other installs (the typical multi-boot case):

sudo mount /dev/sdYM /mnt/sdXN_crypt/boot/efi
sudo mount --bind /dev  /mnt/sdXN_crypt/dev
sudo mount --bind /proc /mnt/sdXN_crypt/proc
sudo mount --bind /sys  /mnt/sdXN_crypt/sys
sudo mount --bind /run  /mnt/sdXN_crypt/run

Binding /run matters just as much as /dev, /proc and /sys: without it, update-grub inside the chroot won’t see the LUKS device-mapper entries correctly.

4. Reinstall GRUB from the chroot

sudo chroot /mnt/sdXN_crypt /bin/bash -c "
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=SysLinuxOS --recheck
"

--bootloader-id must exactly match the folder that already exists under EFI/ on the ESP (check with ls /boot/efi/EFI/ before installing): get it wrong and a new one gets created, losing the NVRAM entry shared with the other installs.

5. Unlock the other encrypted volumes (for os-prober)

If the same disk or other disks hold further SysLinuxOS installs on LUKS volumes that should appear in the GRUB menu, unlock them before regenerating the configuration:

sudo cryptsetup luksOpen /dev/sdZN other_crypt

A LUKS volume that isn’t unlocked is invisible to os-prober: if an expected entry is missing from the menu, this is the first thing to check.

6. Regenerate the full grub.cfg

sudo chroot /mnt/sdXN_crypt /bin/bash -c "update-grub"

GRUB_ENABLE_CRYPTODISK=y must already be set in the installed system’s /etc/default/grub — if not, add it and re-run both grub-install and update-grub before leaving the chroot.

7. Verify (optional)

sudo grep -n "^menuentry\|^submenu" /mnt/sdXN_crypt/boot/grub/grub.cfg

Confirm the entries for the unlocked encrypted systems are present before rebooting.

8. Unmount everything and close the LUKS volumes

sudo umount /mnt/sdXN_crypt/dev
sudo umount /mnt/sdXN_crypt/proc
sudo umount /mnt/sdXN_crypt/sys
sudo umount /mnt/sdXN_crypt/run
sudo umount /mnt/sdXN_crypt/boot/efi
sudo umount /mnt/sdXN_crypt
sudo cryptsetup luksClose sdXN_crypt
sudo cryptsetup luksClose other_crypt

Keep the order: unmount the bind mounts before the main mount, and only run luksClose once everything is unmounted.

9. Reboot

sudo reboot

Remove the USB drive while it reboots.

Notes for reuse on other machines

• The mapper names (sdXN_crypt, other_crypt) are arbitrary, picked for the session: they don’t need to match /etc/crypttab.
• Unlocking the other encrypted volumes (step 5) is only needed if they should show up in the GRUB menu; non-encrypted btrfs volumes are already detected automatically by os-prober.
• If the multi-boot layout also includes non-encrypted @ subvolumes, the notes in Restoring GRUB on SysLinuxOS (btrfs with subvolumes) about the os-prober bug #921004/#940710 and the automatic fix in syslinuxos-snapshots ≥ 0.3.0 apply here too.

A word of caution

This procedure touches the boot loader and the encrypted volumes of real systems: always double-check with lsblk -f which partition you’re unlocking and which disk grub-install is writing to, especially with several disks attached and several LUKS volumes unlocked at once.

Restoring GRUB on SysLinuxOS with Encrypted Partitions (LUKS)

share

L'articolo Restoring GRUB on SysLinuxOS with Encrypted Partitions (LUKS) proviene da SysLinuxOS.

The terminal-router workspace keeps the router session and the AI observer in two independent panes.

This article follows terminal-router AI assistants on Cisco and Huawei routers. The earlier article introduced the idea of recording a terminal session and allowing Claude Code or Codex to read the log. Version 1.1.0 turns that mechanism into a complete operational workspace for system integrators and network administrators.

The Italian article is available on francoconidi.it. The source code and the technical documentation are published in the fconidi/terminal-router repository.

What changed in the new release

terminal-router opens two independent terminal widgets. The left widget is reserved for the router or switch session. The right widget runs Claude Code or Codex as an observer. The observer reads the recorded output, analyses the device state and answers questions from the operator.

The remote device is never exposed directly to the AI assistant. The operator owns the SSH or serial connection, types the commands and decides whether to apply any suggestion. The assistant does not authenticate to the router and does not need a direct channel to the device.

The new workspace also supports guarded command proposals. This feature is disabled by default. When enabled, every command group is displayed to the operator, validated and sent only after a one time confirmation code is entered.

Workspace architecture

The launcher creates a private tmux server for the workspace and two separate sessions. The router session is recorded under the user directory ~/.claude-logs. The observer session is not recorded by the workspace launcher. The observer follows a stable link to the router log belonging to that workspace.

This isolation prevents a second workspace from redirecting the observer to the wrong device. Pausing and resuming capture also preserve the correct link. The user’s global tmux configuration is not loaded into the private server used by the workspace.

Mouse behavior is deliberately different in the two widgets. In the router widget, selection and copying work as they do in a normal terminal. In the observer widget, the mouse wheel browses up to 50,000 lines of tmux history. Hold Shift while dragging to select text in the observer. Scrolling therefore does not inject arrow key escape sequences into the assistant prompt.

Quick start

After installation, the command without arguments opens the workspace and selects Claude Code when it is available. If Claude Code is not available, Codex is selected.

terminal-router
terminal-router claude
terminal-router codex
terminal-router workspace claude
terminal-router workspace codex

The commands that name an engine require that exact program. If the selected engine is missing or unauthenticated, terminal-router reports the error and does not silently replace it with the other engine.

The first launch displays a security notice. The log contains whatever is printed on screen and the captured output is sent to the AI provider through its authenticated CLI. The user must explicitly acknowledge this condition. Installing the package does not enable recording and does not automatically edit personal configuration files.

Connecting to a router over SSH

Open the SSH connection in the left widget. Host key prompts, password prompts and interaction with the remote shell remain in the router terminal.

ssh admin@192.168.1.1

When the router produces new output, the observer receives it according to the automatic analysis cadence. The operator can ask questions in the right widget, for example requesting an explanation of a routing table, a review of an ACL or an interpretation of the current interface state.

Serial console

The router widget also displays reference commands for a serial console. tio is the recommended program and is installed as a mandatory dependency. screen and picocom are optional alternatives.

tio --list
tio --baudrate 9600 --databits 8 --parity none --stopbits 1 --flow none /dev/ttyUSB0
screen /dev/ttyUSB0 9600
picocom --baud 9600 --databits 8 --parity n --stopbits 1 --flow n /dev/ttyUSB0

Depending on the adapter, the device can be /dev/ttyACM0. When available, the stable path under /dev/serial/by-id/ is preferable. With tio defaults, 115200 8N1 with no flow control, the following is sufficient.

tio /dev/ttyUSB0

Press Ctrl-t q to exit tio. Recording also works with screen and picocom, but guarded command delivery requires tio or ssh to be the foreground program.

Automatic analysis and AI context

The observer groups output after two seconds of quiet time, or after a maximum of five seconds of continuous output. At least ten seconds must pass between automatic requests. Unchanged output does not trigger a new request.

Each request contains up to the latest 128 KiB of router output and the previous exchange. This keeps enough context for typical command results without sending an unbounded session history. The visible assistant scrollback can reach 50,000 lines, which is separate from the bounded snapshot sent to the provider.

A request that has already been submitted may finish after capture is paused. Pausing prevents new automatic analysis. If the AI CLI or its authentication fails, automatic mode stops and can be enabled again after the problem is corrected.

Guarded configuration mode

Configuration mode is disabled at startup and remains active only for the current observer. The AI may propose commands, but the proposal is treated as untrusted input. Every line is validated, the complete group is displayed and nothing is sent until the operator confirms it.

The mode accepts up to 32 commands in one ordered group. Delivery is allowed only when the router widget has an ssh or tio session in the foreground. Shell operators, control characters and embedded newlines are rejected.

:config on
Configure interface Gi0/1 with description UPLINK and enable it

Pending router commands:
1. configure terminal
2. interface Gi0/1
3. description UPLINK
4. no shutdown
5. end

:confirm A1B2C3D4E5F6

The code is valid for 120 seconds and authorizes only the displayed group. New AI analyses wait while the proposal is pending. F9, a transport change or pausing the router pane cancels the pending group. Every line still needs to be reviewed before confirmation, especially when the device is in production.

Global recording and single session recording

terminal-router install enables recording for every interactive terminal opened by the user. It adds marked blocks to ~/.bashrc or ~/.zshrc and to ~/.tmux.conf. Each tmux pane is connected to the logger and ~/.claude-logs/latest points to the newest log.

terminal-router launch creates a self contained session for one task. Hooks are applied only to that tmux session and disappear when it ends. It does not edit ~/.bashrc, ~/.zshrc or ~/.tmux.conf. Terminator and other open terminals remain independent.

Both modes are per user and keep data inside the user home. Do not run the command as root. The configuration belongs to the calling user and sudo would target root’s home directory.

The terminal-router icon is installed in the SysLinuxOS applications menu.

Administrative commands

After install, the shell shortcuts logpause and logresume are available. Detaching from tmux with Ctrl-b d does not stop recording or the observer. Use F9 or terminal-router pause when capture must stop.

Security and privacy

The log contains everything printed on screen. A password typed at an interactive SSH or sudo prompt is normally not recorded because the terminal does not echo it. Secrets that are made visible by the operator are recorded, including passwords in command arguments, tokens in HTTP headers, plaintext exported variables and the output of .env files or private keys.

The ~/.claude-logs directory uses mode 0700 and log files use mode 0600. The logger runs with umask 077. Nightly rotation removes logs older than 30 days. The directory is outside cloud synchronized folders. Pause capture before sensitive work and resume it into a new file afterwards.

The CLI keeps its normal authentication, while the observer disables shell tools and configured integrations and ignores project configuration. Codex runs read only. Use TR_CLAUDE_MODEL or TR_CODEX_MODEL to select a model. The observer language follows the system locale or can be set explicitly with TR_LANGUAGE=en.

Installation on SysLinuxOS

On SysLinuxOS the package is available in the SysLinuxOS Tools repository.

echo "deb https://fconidi.github.io/SysLinuxOS-Tools tirreno main" | sudo tee /etc/apt/sources.list.d/syslinuxos-tools.list
wget -qO- https://fconidi.github.io/SysLinuxOS-Tools/syslinuxos-archive-keyring.asc | sudo tee /usr/share/keyrings/syslinuxos-archive-keyring.asc > /dev/null
sudo apt update
sudo apt install terminal-router
terminal-router

Installation on Debian and Ubuntu

The GitHub repository publishes the Debian package and its SHA 256 checksum.

wget https://github.com/fconidi/terminal-router/releases/download/v1.1.0/terminal-router_1.1.0_all.deb
wget https://github.com/fconidi/terminal-router/releases/download/v1.1.0/terminal-router_1.1.0_all.deb.sha256
sha256sum -c terminal-router_1.1.0_all.deb.sha256
sudo apt install ./terminal-router_1.1.0_all.deb
terminal-router

To build the package from source:

git clone https://github.com/fconidi/terminal-router.git
cd terminal-router
bash build-deb.sh
sudo apt install ./terminal-router_1.1.0_all.deb
terminal-router

The final command must be run as the normal user. The main requirements are Bash, tmux 3.0 or newer, Python 3 with its standard library, tio and Terminator. Cron is recommended for log rotation. The workspace requires an installed and authenticated Claude Code or Codex CLI.

Upgrading from the 1.0 series

Users of global mode should run terminal-router install again after upgrading. The command updates only marked blocks, creates .terminal-router.bak backups and preserves surrounding settings.

An already running tmux server keeps its previously loaded hooks. Reload the configuration with tmux source-file ~/.tmux.conf when needed. In existing panes, use terminal-router pause and terminal-router resume. For a single task, start a fresh terminal-router launch session.

Conclusion

terminal-router 1.1.0 turns terminal recording into a complete AI assisted operating environment for router and switch work. Separating the device pane from the observer pane preserves human control while the log gives the assistant the real context of the session. Guarded configuration adds a controlled path for proposing commands without turning the assistant into an autonomous administrative connection.

For the full documentation, read the terminal-router GitHub repository and the manual installed with the package through man terminal-router.

terminal-router 1.1.0 an integrated AI observer for Cisco and Huawei routers

share

L'articolo terminal-router 1.1.0 an integrated AI observer for Cisco and Huawei routers proviene da SysLinuxOS.

Recovery guide for a SysLinuxOS system that no longer boots because GRUB is corrupted, overwritten (typically after installing Windows in dual-boot), or was never installed correctly. This covers SysLinuxOS’s standard btrfs layout, with the root filesystem in the @ subvolume and @home kept separate.

When you need this

• The PC shows error: no such device or drops straight into a grub> rescue shell.
• No GRUB menu appears at boot; the PC jumps straight to another OS or fails outright.
• Windows was installed after SysLinuxOS and overwrote the boot loader.
• A kernel or GRUB update was interrupted midway.

Prerequisites

You need a bootable SysLinuxOS Live USB (MATE or Gnome build, same procedure either way). Boot the PC from the USB and open a terminal.

1. Identify the disk and subvolumes

Find the btrfs root partition and its subvolumes:

lsblk -f
sudo mount /dev/sdXN /mnt
sudo btrfs subvolume list /mnt

Look for the lines with path @ and path @home. If the disk holds more than one SysLinuxOS install (multiple @ subvolumes), check which one is the system you want to repair before continuing — for instance by inspecting /etc/hostname inside each subvolume. Then unmount the temporary mount:

sudo umount /mnt

2. Mount the right subvolume

Common mistake: mounting the partition at the top level (subvolid=5) instead of the @ subvolume. The chroot only works if you explicitly mount subvol=@:

sudo mount -o subvol=@ /dev/sdXN /mnt
sudo mount /dev/sdXM /mnt/boot/efi   # UEFI systems only, if ESP is a separate partition
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys

If @home lives on a separate subvolume, there’s no need to mount it for a GRUB reinstall — it isn’t touched by this procedure.

3. Enter the chroot

sudo chroot /mnt /bin/bash

From this point, commands run inside the installed system, not the Live environment.

4. Reinstall GRUB

On UEFI systems (the most common case today):

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=SysLinuxOS --recheck

On legacy BIOS systems, install onto the whole disk (MBR), never a partition:

sudo grub-install --target=i386-pc --recheck /dev/sdX

/dev/sdX is the whole disk (e.g. /dev/sda), never a partition, for legacy BIOS.

5. Regenerate the configuration

sudo update-grub

If the grub-btrfs package is installed, this step also regenerates the SysLinuxOS — snapshots submenu with the latest bootable snapshots. Confirm the command finishes without errors before leaving the chroot: an error here (e.g. a failing /etc/grub.d/ script) leaves the old grub.cfg in place and needs investigating before you reboot.

6. Exit and reboot

exit
sudo umount -R /mnt
sudo reboot

Remove the USB drive while it reboots.

Notes on multi-boot layouts

If the same disk holds several Linux installs on btrfs with @ subvolumes, Debian’s os-prober won’t detect them: it looks for /etc/os-release at the partition’s top level instead of inside /@/etc/os-release (upstream Debian bugs #921004 and #940710, still open). On SysLinuxOS with syslinuxos-snapshots ≥ 0.3.0 this is already handled automatically by a dedicated script that still surfaces them in the GRUB menu.

Notes on encrypted partitions

If another SysLinuxOS install lives on an encrypted partition, mount (unlock) it first so it gets detected, then run:

sudo update-grub

A word of caution

This is a standard GRUB recovery procedure, adapted to SysLinuxOS’s btrfs subvolume layout. Commands like grub-install write to the boot sector: always double-check the target disk (lsblk) before running these commands, especially with more than one disk attached.

Restoring GRUB on SysLinuxOS (btrfs with subvolumes)

share

L'articolo Restoring GRUB on SysLinuxOS (btrfs with subvolumes) proviene da SysLinuxOS.