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

Adding all files and folders

Browse Source
This commit is contained in:
sam rolfe
2026-02-01 12:08:31 +11:00
parent 892f3f2418
commit 1fb54400b4
24 changed files with 63803 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
docs/00_backup_plan.md Normal file
View File

@@ -0,0 +1,67 @@
# 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 Normal file
View File

@@ -0,0 +1,39 @@
# 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.

65
docs/02_software_migration_plan.md Normal file
View File

@@ -0,0 +1,65 @@
# Phase 2: Software Migration Plan & Mapping
**Objective:** To create a clear mapping from currently installed software (via APT and Snap) to their equivalents in the NixOS ecosystem. This list will directly inform the creation of the `configuration.nix` file.
## Analysis Summary
The reconnaissance scan revealed a large number of installed packages. The following is a high-level summary and a plan for the most critical software components identified.
**Instructions:** Review this list. Add any missing critical applications. The "NixOS Package Name" column should be filled in by searching for the application on [NixOS Search](https://search.nixos.org/packages).
---
### Tier 1: Critical Applications & Services
These are essential for your daily workflow and server functions.
| Application Name | Installed Via | Notes | NixOS Package Name / Module |
| ----------------------- | ------------- | ----------------------------------------------- | -------------------------------- |
| Docker | `apt` | Core virtualization tool. | `virtualisation.docker.enable = true;` |
| Docker Compose | `apt` | Used for multi-container Docker apps. | `docker-compose` |
| Firefox | `snap` | Primary web browser. | `firefox` |
| Thunderbird | `snap` | Email client. | `thunderbird` |
| Kitty | `apt` | Terminal emulator. | `kitty` |
| Neovim (from dotfiles) | Manual/Git | Primary text editor. | `neovim` |
| Snapcast (Server/Client)| `apt`? | Need to locate config files (`/etc/snap*`). | `snapcast-server`, `snapcast-client` |
| Gitea (mentioned) | Docker/Manual | Git service. | `gitea` or managed via Docker |
| Nushell | `snap` | Shell. | `nushell` |
| --- | --- | --- | --- |
### Tier 2: Development & CLI Tools
Essential tools for your development and command-line environment.
| Tool Name | Installed Via | Notes | NixOS Package Name |
| ----------------------- | ------------- | ----------------------------------------------- | -------------------------------- |
| Git | `apt` | Version control. | `git` |
| Rust (cargo, rustc) | `apt` | Rust programming language toolchain. | `rustc`, `cargo` |
| Node.js | `apt` | JavaScript runtime. | `nodejs` (specify version) |
| Python 3 | `apt` | Python programming language. | `python3` |
| build-essential / gcc | `apt` | C/C++ compiler and core build tools. | `gcc`, `gnumake` |
| btop | `apt` | Resource monitor. | `btop` |
| eza / bat / fzf | `apt` | Modern CLI tools. | `eza`, `bat`, `fzf` |
| --- | --- | --- | --- |
### Tier 3: Desktop & GUI Applications
Standard desktop applications.
| Application Name | Installed Via | Notes | NixOS Package Name |
| ----------------------- | ------------- | ----------------------------------------------- | -------------------------------- |
| LibreOffice | `apt` | Office suite. | `libreoffice` |
| Flameshot | `apt` | Screenshot tool. | `flameshot` |
| GIMP / Inkscape (if any)| `apt`? | Graphics editors. | `gimp`, `inkscape` |
| GNOME Apps (various) | `apt` | Calculator, Clocks, etc. | Handled by `services.xserver.desktopManager.gnome.enable = true;` |
| --- | --- | --- | --- |
## Plan for Other Packages
- **System Libraries:** The vast majority of packages listed in the log are system libraries (files ending in `...:amd64`, `...-dev`, `lib...`). These will be managed automatically by NixOS as dependencies for the applications you choose to install. You do not need to list them manually.
- **Snap Packages:** All applications installed via `snap` will need to be replaced with their NixOS/Flathub equivalents. NixOS does not support Snap out of the box.
- **De-duplication:** Many packages are related (e.g., `g++`, `gcc`, `cpp`). In NixOS, installing the `gcc` package will provide the necessary toolchain.
**Next Step:** Use this document as a worksheet to build the `environment.systemPackages` list in the `configuration.nix.template` file.

67
docs/02_software_migration_plan_filled.md Normal file
View File

@@ -0,0 +1,67 @@
# Phase 2: Software Migration Plan & Mapping (Filled)
**Objective:** To create a clear mapping from currently installed software (via APT and Snap) to their equivalents in the NixOS ecosystem. This list will directly inform the creation of the `configuration.nix` file.
## Analysis Summary
The following tables are based on the `logs/01_system_recon.log` file.
---
### Tier 1: Critical Applications & Services
These are essential for your daily workflow and server functions.
| Application Name | Installed Via | Notes | NixOS Package Name / Module |
| ----------------------- | ------------- | ----------------------------------------------- | -------------------------------- |
| Firefox | `snap` | Primary web browser. | `firefox` |
| Thunderbird | `snap` | Email client. | `thunderbird` |
| Kitty | `apt` | Terminal emulator. | `kitty` |
| Neovim | `apt` | Primary text editor. | `neovim` |
| Nushell | `snap` | Shell. | `nushell` |
| VS Code | `snap` | Code editor. | `vscode` |
| Telegram Desktop | `snap` | Messaging app. | `telegram-desktop` |
| --- | --- | --- | --- |
### Tier 2: Development & CLI Tools
Essential tools for your development and command-line environment.
| Tool Name | Installed Via | Notes | NixOS Package Name |
| ----------------------- | ------------- | ----------------------------------------------- | -------------------------------- |
| Git | `apt` | Version control. | `git` |
| Rust (cargo, rustc) | `apt` | Rust programming language toolchain. | `rustc`, `cargo` |
| Node.js | `apt` | JavaScript runtime. | `nodejs` (specify version) |
| Python 3 | `apt` | Python programming language. | `python3` |
| build-essential / gcc | `apt` | C/C++ compiler and core build tools. | `gcc`, `gnumake` |
| btop | `apt` | Resource monitor. | `btop` |
| eza | `apt` | Modern `ls` replacement. | `eza` |
| bat | `apt` | Modern `cat` replacement. | `bat` |
| fzf | `apt` | Command-line fuzzy finder. | `fzf` |
| ripgrep | `apt` | Fast search tool. | `ripgrep` |
| zoxide | `apt` | Smarter `cd` command. | `zoxide` |
| --- | --- | --- | --- |
### Tier 3: Desktop & GUI Applications
Standard desktop applications.
| Application Name | Installed Via | Notes | NixOS Package Name |
| ----------------------- | ------------- | ----------------------------------------------- | -------------------------------- |
| LibreOffice | `apt` | Office suite. | `libreoffice` |
| Flameshot | `apt` | Screenshot tool. | `flameshot` |
| VLC | `apt` | Media player. | `vlc` |
| Spotify | `snap` | Music player. | `spotify` |
| Timeshift | `apt` | System restore utility. | `timeshift` |
| GNOME Apps (various) | `apt` | Calculator, Clocks, etc. | Handled by `services.xserver.desktopManager.gnome.enable = true;` |
| --- | --- | --- | --- |
## Plan for Other Packages
- **System Libraries:** The vast majority of packages listed in the log are system libraries (files ending in `...:amd64`, `...-dev`, `lib...`). These will be managed automatically by NixOS as dependencies for the applications you choose to install. You do not need to list them manually.
- **Snap Packages:** All applications installed via `snap` will need to be replaced with their NixOS/Flathub equivalents. NixOS does not support Snap out of the box. The list above includes the most important ones.
- **De-duplication:** Many packages are related (e.g., `g++`, `gcc`, `cpp`). In NixOS, installing the `gcc` package will provide the necessary toolchain.
**Next Step:** Use this document as a worksheet to build the `environment.systemPackages` list in the `configuration.nix` file.

105
docs/03_file_migration_guide.md Normal file
View File

@@ -0,0 +1,105 @@
# 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 Normal file
View File

@@ -0,0 +1,40 @@
# 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.

18
docs/06_application_data_notes.md Normal file
View File

@@ -0,0 +1,18 @@
# Application Data Notes for NixOS Migration
This document outlines considerations for application-specific data that may need special handling during the NixOS migration.
## Important Considerations:
* **GPG Keys:** Your GnuPG keys are critical for cryptographic operations (e.g., signing Git commits, encrypting files). These are typically stored in `~/.gnupg/`. It is paramount to ensure these keys are backed up securely.
* **Action:** Verify that your `~/.gnupg/` directory is either included in a secure backup separate from `/data` (e.g., an encrypted archive) or that you have a recovery method (e.g., revoked subkeys, passphrase-protected master key backup) that is outside of this system.
* **SSH Keys:** Your SSH keys (typically in `~/.ssh/`) are used for secure remote access (e.g., to Gitea, other servers). While you've indicated dotfiles will be managed, SSH private keys should *never* be committed directly to a public repository.
* **Action:** Confirm that you have a secure backup of your `~/.ssh/` directory, especially your private keys, in a location separate from `/data` (e.g., an encrypted USB stick, a secure password manager). These keys should be restored to the new NixOS system as part of your `home-manager` setup or manually.
## Exclusions (No Action Required):
* **Thunderbird Email:** You have confirmed that Thunderbird uses Gmail in the cloud. No local migration of email data is required.
* **Google Chrome / Mozilla Firefox Profiles:** You have confirmed that browser data (bookmarks, passwords, extensions) are synced via your accounts. No local migration of browser profiles is required.
This document serves as a reminder to address these specific local application data points when configuring your new NixOS environment.