sam/nixos-4screen
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Publish local repo state

Browse Source
This commit is contained in:
sam rolfe
2026-02-08 13:09:33 +11:00
parent 1fb54400b4
commit de91475de5
33 changed files with 599 additions and 56064 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
docs/00_backup_plan.md
View File

@@ -1,67 +0,0 @@
# Phase 0: Full System Backup (CRITICAL)
**Objective:** To create a complete, offline, and verified backup of all critical data from both the Ubuntu and Windows operating systems before beginning the migration process.
**Do not proceed to any other phase until this phase is 100% complete.** Data loss is irreversible.
## Instructions for Backup Operator (Human or AI)
### 1. Identify Backup Target
- **Requirement:** You will need an external storage device (e.g., a USB hard drive or NAS) with enough free space to hold all the data you intend to back up.
- **Recommendation:** This drive should be dedicated to the backup and stored offline (disconnected from the computer) once the backup is complete.
### 2. Backup Ubuntu Data
Your personal files are the top priority. System files can be reinstalled by the new OS.
- **Primary Tool:** `rsync` is the recommended tool for its efficiency and ability to preserve permissions and metadata.
- **Source Directories:** The most common locations for user data on Linux are within the `/home/<username>` directory. You must identify and back up, at a minimum:
- `/home/<username>/Documents`
- `/home/<username>/Pictures`
- `/home/<username>/Music`
- `/home/<username>/Videos`
- `/home/<username>/Desktop`
- `/home/<username>/Downloads`
- `/home/<username>/dotfiles` (as mentioned in the main plan)
- Any other project or data directories inside your home folder (e.g., `/home/<username>/dev`, `/home/<username>/workspaces`).
- **Docker Data:**
- Stop all running containers: `docker stop $(docker ps -aq)`
- Identify Docker's data directory, typically `/var/lib/docker`. This contains volumes, images, and container configurations. Back this entire directory up.
- **Server Configurations:**
- Snapcast config: Locate and back up the configuration files (e.g., `/etc/snapserver.conf`, `/etc/snapclient.conf`).
- Other server configs (Apache, Node.js services): Back up relevant files from `/etc/` and any service data files.
**Example `rsync` Command:**
```bash
# Replace <username>, <external_drive_mount_point>, and <backup_folder_name>
# The -a flag archives, -v is verbose, -h is human-readable, --progress shows progress.
rsync -avh --progress /home/<username>/Documents /<external_drive_mount_point>/<backup_folder_name>/
```
*Run this for each source directory.*
### 3. Backup Windows Data
- **Method:** Boot into your Windows 10 operating system.
- **Source Directories:** Connect your external backup drive. Manually copy the entire contents of your user folders to the backup drive. These are typically located at:
- `C:\Users\<YourUsername>\Documents`
- `C:\Users\<YourUsername>\Pictures`
- `C:\Users\<YourUsername>\Music`
- `C:\Users\<YourUsername>\Videos`
- `C:\Users<YourUsername>\Desktop`
- `C:\Users<YourUsername>\Downloads`
- **Thoroughness:** Be meticulous. Ensure you copy all personal data. Do not worry about program files or the Windows directory itself.
### 4. Verification
A backup is not a backup until it is verified.
- **Procedure:** After the copy process is complete for both operating systems, safely eject and reconnect the external drive.
- **Spot Check:** Browse the directories on the backup drive. Open a few files of different types (documents, images, music files) from both the Ubuntu and Windows backups to ensure they are not corrupted and are fully readable.
- **Compare Sizes:** Use a disk usage tool (like `du -sh` on Linux or checking folder properties on Windows) to compare the size of a few source directories with their backed-up counterparts. They should be identical.
### 5. Completion
- Once verified, disconnect the external backup drive.
- Store it in a safe, separate physical location.
- You may now proceed to Phase 1.

39
docs/01_system_recon_guide.md
View File

@@ -1,39 +0,0 @@
# Phase 1: System Reconnaissance Guide
**Objective:** To execute the reconnaissance script that gathers essential information about the current system. This information will be used in subsequent phases to plan the file and software migration.
**Prerequisite:** Ensure you have completed **Phase 0: Full System Backup**. Do not run this script until you have a complete and verified offline backup of your data.
## Instructions for Operator (Human or AI)
### 1. Understand the Script
- **Script Location:** `scripts/01_system_recon.sh`
- **Purpose:** This script is designed to be **non-destructive**. It reads information about the system and saves it to a log file. It does not modify any files or settings.
- **Actions Performed:**
- Gathers disk, partition, and filesystem information.
- Calculates the total size of major user directories (Documents, Pictures, etc.).
- Lists installed software from `apt` and `snap`.
- Collects detailed information about the Docker setup (containers, images, volumes).
- Checks for versions of common development languages (Rust, Node, etc.).
- Looks for evidence of common servers and development workspaces (Eclipse, Arduino).
- **Output:** All findings are saved to `logs/01_system_recon.log`.
### 2. Execution
1. Open a terminal on the Ubuntu machine that is being migrated.
2. Navigate to the `nixos-migration` project directory.
3. Run the script. It may ask for a password as some commands (like inspecting Docker's data directory or listing packages) can require elevated privileges to get a complete picture.
```bash
sudo ./scripts/01_system_recon.sh
```
### 3. Review the Output
- Upon completion, the script will have created or updated the log file at `logs/01_system_recon.log`.
- Review this file to ensure the information appears correct and complete. This log is the foundation for all future planning steps.
### 4. Next Steps
Once the reconnaissance is complete and the log file has been generated, you may proceed to **Phase 2: Migration Analysis & Planning**. The data in the log file will be the primary input for this next phase.

0
docs/02_software_migration_plan.md Normal file → Executable file
View File

0
docs/02_software_migration_plan_filled.md Normal file → Executable file
View File

105
docs/03_file_migration_guide.md
View File

@@ -1,105 +0,0 @@
# Phase 3: File Migration Scripting Guide
**Objective:** To prepare for the physical relocation of user data from the old directory structures to the new, consolidated structure on the NixOS system.
**Prerequisite:** A full analysis of the disk and file reconnaissance log (`logs/01_system_recon.log`) must be complete. The target directory structure should be agreed upon.
**Core Principle:** We will not move files directly. We will write a script that **copies** the files. The original data will be left untouched until the new NixOS system is fully configured and the copied data is verified. We will also implement a `--dry-run` feature for safety.
---
### Target Directory for Staging
To avoid disturbing the existing file structure on the 2.7TB drive, the migration script should consolidate all files from the Windows and old Ubuntu partitions into a single, new directory.
- **Staging Directory:** `/mnt/ubuntu_storage_3TB/migration_staging`
The script's primary purpose is to copy data from the other drives *into* this location. From there, you can organize it manually at your leisure after the migration is complete.
---
### Instructions for Operator (Human or AI)
Your task is to create a shell script named `scripts/02_migrate_files.sh`. This script will contain a series of `rsync` commands to copy data from the source drives to the target directories.
#### 1. Script Requirements
- **Shebang:** The script must start with `#!/bin/bash`.
- **Safety:** The script should not perform any operations if run as root without a specific override.
- **Dry-Run Flag:** The script must accept a `--dry-run` argument. If this flag is present, all `rsync` commands should be executed with the `--dry-run` flag, which shows what would be done without making any actual changes.
- **Verbosity:** All commands should be verbose (`-v`) and output human-readable sizes (`-h`) so the user can see the progress.
- **Logging:** The script should log its output to a file in the `logs/` directory.
#### 2. Source Data Locations
The script will need to access data from the following locations. These drives will be mounted on the running NixOS system *before* the script is executed (as defined in `configuration.nix`).
- **Primary Ubuntu Home:** `/home/sam/` on the old root partition. (This will need to be mounted temporarily during migration).
- **Ubuntu Storage Drive:** The contents of `/dev/sdd1` (which will become `/data`). The script will mostly be organizing files *within* this drive.
- **Windows Storage Drive:** `/mnt/windows-storage` (mounted from `/dev/sdb2`).
- **Windows User Folders:** The script may need to access `C:\Users\<YourUsername>` from one of the `ntfs` partitions.
#### 3. `rsync` Command Structure
Use the `rsync` command for all file copy operations. It is efficient, safe, and preserves metadata.
**Example `rsync` command for the script:**
```bash
# -a: archive mode (preserves permissions, ownership, etc.)
# -v: verbose
# -h: human-readable numbers
# --progress: show progress during transfer
# --exclude='*.tmp': example of excluding files
rsync -avh --progress --exclude='cache' /path/to/source/documents/ /data/work/
```
#### 4. Script Skeleton (to be created in `scripts/02_migrate_files.sh`)
```bash
#!/bin/bash
# ---
# Configuration ---
# ---
LOG_FILE="logs/02_file_migration.log"
DRY_RUN=""
# Check for --dry-run flag
if [ "$1" == "--dry-run" ]; then
DRY_RUN="--dry-run"
echo "---
PERFORMING DRY RUN ---"
fi
# ---
# Helper Functions ---
# ---
log() {
echo "$1" | tee -a "$LOG_FILE"
}
# ---
# Main Execution ---
# ---
log "Starting file migration script..."
# Create target directories
log "Creating target directories..."
mkdir -p $DRY_RUN /data/personal /data/work /data/dev /data/backups /data/media
# ---
# Migration Commands ---
# ---
# Add rsync commands here. Be specific.
# Example:
# log "Migrating Documents from Windows..."
# rsync -avh $DRY_RUN /mnt/windows-storage/Users/Sam/Documents/ /data/work/project-archives/
log "File migration script finished."
```
**Next Step:** A developer or another AI instance will now write the full `scripts/02_migrate_files.sh` script based on these instructions and a deeper analysis of the file contents revealed in `logs/02_deeper_scan.log`.

40
docs/05_migration_status_and_next_steps.md
View File

@@ -1,40 +0,0 @@
# Migration Status and Next Steps (Jan 28, 2026)
This document summarizes the current status of the NixOS migration project and outlines the remaining critical steps.
## Current Status
**Phase 1: Data Staging and Relocation - COMPLETE**
* **Initial Data Review:** Identified and confirmed that primary user personal files (Documents, Pictures, Music, Videos, Downloads) were largely already present in `/data/personal`.
* **Missing Project Data Identified:** Discovered missing web projects (XAMPP `htdocs`) and IoT projects (`frei0r`) from the old Windows drive (`/media/sam/8294CD2994CD2111`).
* **Data Staging Completed:** Successfully copied the missing web projects to `/data/work/htdocs` and IoT projects to `/data/work/frei0r`. The `Espressif` toolchain was intentionally excluded.
* **Critical Data Relocation:** Both the entire `/data` directory (containing all staged user data, total ~86GB) and the `nixos-migration` project directory were successfully copied from the original Ubuntu OS drive to the external USB drive: `/media/sam/Integral300/`. This is crucial for safeguarding data before the main drive is formatted.
**Phase 2: Deep System Reconnaissance - COMPLETE**
* A comprehensive `04_nixos_recon.sh` script was created and executed.
* Detailed logs (`logs/04_nixos_recon.log`) have been generated, containing:
* Lists of all installed APT and Snap packages.
* Information on active systemd services and timers (system-wide and user-specific).
* Output from Docker commands (version, info, running containers, images, volumes) and a search for `docker-compose.yml` files.
* Analysis of shell history for frequently used command-line tools.
* Lists of manually installed binaries in `/usr/local/bin`, `~/bin`, and `~/.local/bin`.
**Gitea Archival - COMPLETE**
* The essential `logs/` and `results/` directories from this `nixos-migration` project have been successfully pushed to the `nixos-4screen` Gitea repository (`ssh://git@gitea.lab.audasmedia.com.au:2222/sam/nixos-4screen.git`). This ensures the reconnaissance data and any future NixOS configuration templates are safely version-controlled.
## Next Steps / Remaining Considerations
1. **Review All Reconnaissance Logs:** A thorough manual review of all logs (`04_nixos_recon.log` and `07_deep_cli_scan.log`) is essential to build your final NixOS configurations. The deep scan successfully identified numerous Cargo-installed CLI tools like `atuin`, `starship`, `zellij`, `yazi`, etc.
2. **Build `configuration.nix`:** Use the `results/generated_configuration.nix` as a starting template. Cross-reference with the logs to add any missing system-wide packages and services.
3. **Build `home.nix`:** A new draft, `results/generated_home.nix`, has been created. This file is a comprehensive template for using Home Manager to declaratively build your entire terminal environment, including Zsh, Oh My Zsh, Starship, and all the CLI tools discovered in the deep scan.
4. **Backup of Local Application Data (See `06_application_data_notes.md`):** Ensure critical items like GPG/SSH keys are securely backed up.
5. **Fireship Desktop App:** The "fireship" application was not found via standard package managers or `.desktop` files. It is likely an AppImage. You will need to re-download this manually on your new NixOS system.
Once these review steps are complete, you will be ready to begin the NixOS installation.

0
docs/06_application_data_notes.md Normal file → Executable file
View File