1. Overview
The RecoveryMain module provides the recovery-mode integration layer for BastionGuard Backup.
Recovery mode launches the standard graphical interface and keeps the normal backup, restore, configuration, and wizard functions available. The module does not implement a separate recovery interface and does not directly alter the snapshot engine.
Its responsibilities are limited to:
- Detecting whether the system was started in BastionGuard recovery mode
- Displaying a recovery warning dialog after the main application window becomes visible
- Informing the user that backup and restore operations remain available
The module is implemented in Vala and uses GLib and GTK.
2. Recovery Mode Design
The recovery environment uses the normal MainWindow instead of a dedicated recovery-only window.
All standard functions remain available, including:
- Creating a new backup from the currently running live system
- Restoring an existing snapshot
- Opening the guided configuration wizard
- Configuring the backup device
- Accessing the normal application settings
The operational difference between a normal start and a recovery start is the informational warning displayed when the graphical interface opens.
3. Namespace
All recovery-specific functions are grouped inside:
namespace BastionGuardRecovery
The namespace isolates recovery helpers from the main backup controller and graphical application classes.
The module exposes two principal functions:
is_recovery_boot()– detects the recovery boot parametershow_recovery_banner()– displays the recovery-mode warning
4. Dependencies
The module imports:
using GLib;
using Gtk;
GLib is used to read the Linux kernel command line, while GTK provides the recovery warning dialog.
No additional BastionGuard-specific service or backend dependency is required by this module.
5. Recovery Boot Detection
5.1 is_recovery_boot()
public bool is_recovery_boot()
The is_recovery_boot() function determines whether the current Linux system was started using the BastionGuard recovery boot option.
The function reads:
/proc/cmdline
This virtual file contains the arguments passed to the Linux kernel by the bootloader.
5.2 Recovery Kernel Parameter
Recovery mode is identified through the following kernel parameter:
bastionguard.recovery=1
The function returns true when this value is present in the kernel command line:
return "bastionguard.recovery=1" in cmdline;
When the parameter is absent, the function returns false.
5.3 File Reading
The kernel command line is loaded through:
FileUtils.get_contents("/proc/cmdline", out cmdline);
The complete file contents are stored in the local cmdline string and inspected for the recovery marker.
5.4 Detection Error Handling
The file-reading operation is enclosed in a try/catch block:
try {
string cmdline;
FileUtils.get_contents("/proc/cmdline", out cmdline);
return "bastionguard.recovery=1" in cmdline;
} catch {
return false;
}
If /proc/cmdline cannot be read, recovery mode is considered inactive.
The function therefore uses a fail-safe default:
false
No exception is propagated to the application startup sequence.
6. Interaction with Live-System Detection
The recovery module does not directly modify the normal live-system detection logic.
Instead, the main application recognizes the recovery execution mode and prevents it from being treated as a restricted live session.
This distinction is important because a normal live environment may disable scheduled or system-modifying operations, while the recovery environment must permit both:
- Snapshot creation
- Snapshot restoration
The recovery boot parameter identifies the environment, while the main controller is responsible for enabling the corresponding operational behavior.
7. Recovery Banner
7.1 show_recovery_banner()
public static void show_recovery_banner(Gtk.Window parent)
The show_recovery_banner() function creates and presents a modal warning dialog.
The function receives the visible main application window as its parent:
Gtk.Window parent
Associating the dialog with the main window ensures that the warning remains attached to the BastionGuard interface.
7.2 Invocation Point
The function is intended to be called by the graphical application startup code after the main window has been displayed.
The expected startup sequence is:
- Initialize the BastionGuard application
- Create the normal
MainWindow - Display the main window
- Verify the recovery boot state
- Call
show_recovery_banner()
Displaying the main window first prevents the warning from appearing without a visible parent interface.
8. GTK Message Dialog Configuration
The recovery banner is implemented with:
Gtk.MessageDialog
The dialog uses the following properties:
- Parent: the main BastionGuard window
- Dialog flags:
Gtk.DialogFlags.MODAL - Message type:
Gtk.MessageType.WARNING - Buttons:
Gtk.ButtonsType.OK
The dialog is created through:
var dlg = new Gtk.MessageDialog(
parent,
Gtk.DialogFlags.MODAL,
Gtk.MessageType.WARNING,
Gtk.ButtonsType.OK,
"%s",
message
);
8.1 Modal Behavior
The MODAL flag requires the user to acknowledge the recovery notice before returning to the main application window.
This ensures that the user understands that BastionGuard is running from the recovery environment before starting a backup or restore operation.
8.2 Warning Message Type
The dialog uses:
Gtk.MessageType.WARNING
This visually distinguishes the recovery notification from ordinary informational messages without presenting it as a fatal application error.
8.3 Dialog Button
The dialog provides a single confirmation button:
Gtk.ButtonsType.OK
No alternative action or cancellation choice is required because the dialog is informational and does not initiate a backup or restore operation.
9. Recovery Banner Content
The warning identifies the application state with:
BastionGuard™ — Modalità Recovery
The message explains that the operating system was started from the recovery environment and lists the functions that remain available.
The displayed actions are:
- Crea – creates a backup from the running live system
- Ripristina – restores an existing snapshot
- Configurazione guidata – configures the backup device
The message also explains that shutdown and restart controls are available through the desktop context menu.
10. Dialog Title
The window title is explicitly configured as:
BastionGuard™ Recovery
The title is assigned through:
dlg.set_title("BastionGuard™ Recovery");
This title appears in the window decoration and identifies the dialog independently from its body text.
11. Dialog Presentation
After configuration, the dialog is displayed through:
dlg.present();
The function presents the dialog without starting a separate nested GTK event loop.
The surrounding graphical application remains responsible for GTK event processing and dialog lifecycle management.
12. User Workflow
The complete recovery-mode workflow is:
- The recovery bootloader adds
bastionguard.recovery=1to the kernel command line - Linux exposes the parameter through
/proc/cmdline is_recovery_boot()detects the parameter- The normal BastionGuard Backup graphical interface starts
- The main application enables recovery-mode behavior
show_recovery_banner()displays the warning- The user acknowledges the dialog
- The user creates a backup, restores a snapshot, or opens the configuration wizard
13. Separation of Responsibilities
The recovery module does not perform backup or restore operations directly.
Responsibility is divided as follows:
- RecoveryMain – detects recovery boot and displays the warning
- AppGtk – initializes the graphical application and invokes the banner
- MainWindow – exposes the normal backup and restore interface
- Main – manages snapshots, repositories, devices, exclusions, backup, and restore operations
This design avoids duplicating the main application interface and backup logic inside the recovery environment.
14. Runtime Considerations
- Non-invasive detection: recovery mode is detected by reading the kernel command line and does not modify system configuration.
- Fail-safe behavior: an unreadable
/proc/cmdlineproduces a normal non-recovery result. - Standard interface reuse: recovery mode uses the same
MainWindowand controller as a normal application session. - Feature availability: backup and restore functions remain available instead of being disabled as they may be in an ordinary live session.
- User acknowledgement: the modal dialog informs the user before recovery operations begin.
- No direct privilege escalation: this module does not execute privileged commands or modify protected files.
- No background threads: recovery detection and banner creation run synchronously during application startup.
- No persistent state: the module does not write configuration files or store the detected recovery state.
15. Implementation Considerations
- Exact parameter matching: detection depends on the literal
bastionguard.recovery=1value being present in/proc/cmdline. - Linux-specific implementation: the detection mechanism requires the Linux
/procvirtual filesystem. - Startup integration: the caller must invoke the banner only after the main window has been created and presented.
- Parent window requirement:
show_recovery_banner()requires a validGtk.Window. - Dialog lifecycle: the function presents the dialog but does not explicitly connect a response handler or destroy the dialog.
- Localization: the current dialog title and message are embedded directly in Italian and are not passed through a translation function.
- Presentation-only module: recovery security and operational restrictions must be enforced by the main controller, not by this file.
16. Licensing
The source header identifies the module as part of the BastionGuard Backup fork and declares:
BastionGuard™
Copyright (C) 2025–2026 Calogero Scarnà
GPLv3
The module is distributed under the GNU General Public License version 3.
