File System Interactions
Relevant source files
The following files were used as context for generating this wiki page:
The safe64switch project interacts primarily with the Raspberry Pi's boot configuration system to transition the operating system from a 32-bit kernel to a 64-bit kernel. The system's primary mechanism of action involves reading from pseudo-file systems to verify hardware compatibility and performing atomic-like backup and append operations on critical system configuration files located in the /boot partition.
The scope of these interactions is limited to system-level configuration files that govern the initial hardware abstraction layer and kernel initialization parameters. By targeting the /boot/config.txt file, the script modifies the firmware's behavior during the next power cycle or reboot.
Sources: safe64.sh:1-35, README.md:1-15
Hardware Validation via Pseudo-File Systems
Before any modifications are written to the disk, the system performs a non-destructive read operation on the Linux pseudo-file system to ensure the environment is a valid Raspberry Pi. This prevents accidental corruption of non-target hardware architectures.
- Path:
/proc/device-tree/model - Operation:
grepsearch for the string "Raspberry Pi" - Logic: If the file does not contain the target string or is inaccessible, the process terminates with an error code to prevent unsafe file system modifications.
Sources: safe64.sh:11-15
Configuration Backup and Persistence
To ensure system recoverability, the script implements a backup procedure before modifying the live configuration. This is a critical safety feature of the "safe" switch implementation.
| File Path | Description | Role |
|---|---|---|
/boot/config.txt | Primary boot configuration file | Active Configuration |
/boot/config.txt.bak | Copy of the original config | Recovery Backup |
Sources: safe64.sh:17-19, README.md:8
Backup Mechanism Flow
The following diagram illustrates the sequence of file system operations performed to ensure a safe transition.
The flow ensures that the backup exists before any write operations (>>) occur on the primary configuration file.
Sources: safe64.sh:11-30
Configuration Injection and Idempotency
The system interacts with /boot/config.txt using conditional append operations. It checks for the existence of specific flags to avoid duplicate entries, maintaining the integrity of the configuration file.
Targeted Modifications
- 64-bit Kernel Activation: Searches for
^arm_64bit=1. if absent, it appends the string to the end of the file. - GPU Memory Optimization: Uses
grep -qxF "gpu_mem=16"to verify if the exact line exists. If not, it appends it to reduce memory overhead on headless or low-memory configurations.
Sources: safe64.sh:21-30
Interaction Logic Table
| Parameter | Value | Logic | Target File |
|---|---|---|---|
arm_64bit | 1 | Append if not found via regex | /boot/config.txt |
gpu_mem | 16 | Append if exact line missing | /boot/config.txt |
Sources: safe64.sh:21-30, README.md:10
Execution Requirements
Because the script modifies system-level files in the /boot directory, it requires elevated privileges. Standard file system permissions on these paths typically restrict write access to the root user.
The diagram shows the synchronous nature of the shell script's interaction with the file system.
Sources: safe64.sh:5-35, README.md:12-15
Summary of File System Impacts
The safe64switch utility maintains a minimal footprint, only interacting with the /proc virtual interface for validation and the /boot partition for configuration persistence. By utilizing a backup file (config.txt.bak), it provides a manual rollback point for users should the 64-bit kernel fail to initialize on specific hardware revisions.
Sources: safe64.sh:18-19, README.md:5-10