Add NixOS dual-configuration setup with isolated dev and gaming profiles #1

Merged
Copilot merged 5 commits from copilot/create-nixos-dual-configs into main 2026-02-01 19:51:45 +00:00
Copilot commented 2026-02-01 19:33:01 +00:00 (Migrated from github.com)
  • Address PR review comments
    • Replace initialPassword with hashedPassword placeholder for security
    • Change hardware.enableAllFirmware to hardware.enableRedistributableFirmware
    • Fix gamemode renice value to -10 (higher priority for games)
    • Remove duplicate amd_pstate=active kernel param from gaming.nix
    • Remove mitigations=off for security (was disabling CPU mitigations)
    • Update system.stateVersion from "25.05" to "24.11"
    • Add greetd configuration for auto-starting MangoWC
    • Add assertion to verify mango flake module exists
    • Add security note about flake.lock and supply chain protection
    • Update nerd fonts comment for clarity
    • Add comment about profile-specific group membership in gaming.nix
    • Add comment about Docker group logout requirement in dev.nix
    • Uncomment filesystem examples with clear placeholder UUIDs
    • Improve README with clearer setup instructions
    • Add comment clarifying mango binary source in greetd config
Original prompt

NixOS Dual-Configuration Setup Plan

Overview

Create a NixOS system with two fully isolated configurations:

  1. Dev - Stable, LTS kernel, web development tooling (Docker, Node.js, direnv)
  2. Gaming - Zen kernel, Steam, Lutris, performance tools

Both share a common base: MangoWC (Wayland compositor) + Noctalia Shell, AMD RDNA 4 GPU support, and a shared /home directory with mutable dotfiles.

Why Separate Configs (Not Specialisations)?

NixOS offers "specialisations" for boot-time variants, but this plan uses separate nixosConfigurations because:

  • True isolation: Dev has zero gaming packages, Gaming has zero dev tools
  • User preference: Explicitly requested complete separation
  • Clarity: Each config is self-contained and easier to reason about

Trade-off: You must rebuild both configs separately and keep them in sync to avoid kernel/Mesa version drift (critical for RDNA 4). If you prefer simpler maintenance, specialisations are a valid alternative.


Target System Specifications

Hardware

Component Model Architecture Notes
CPU AMD Ryzen 7 5700G Zen 3 (Cezanne) Mature support, iGPU available for secondary display
GPU AMD RX 9060 XT RDNA 4 (Navi 44) Requires Kernel 6.14+, Mesa 25.0+
Motherboard MSI B550 Tomahawk AM4 Chipset Excellent IOMMU groups for passthrough

Software

Component Value
Compositor MangoWC
Shell Noctalia (built on Quickshell)
Nixpkgs Channel nixos-unstable (tracks Kernel 6.15+, Mesa 25.x)
Dev Kernel Latest stable (linuxPackages_latest)
Gaming Kernel Zen (linuxPackages_zen)
Home Manager Not used - mutable dotfiles

RDNA 4 Requirements

The RX 9060 XT (released ~June 2025) has specific requirements:

  • Kernel: 6.14+ mandatory (nixos-unstable provides this)
  • Mesa: 25.0+ mandatory (nixos-unstable provides this)
  • Firmware: Requires navi44_*.bin blobs - must enable all firmware

Prerequisites

Before running this plan:

  1. NixOS must already be installed (minimal install is fine)
  2. hardware-configuration.nix must exist from the installation
  3. Flakes must be enabled in the existing config or via:
    nix-shell -p nixFlakes
    
  4. User must know their:
    • Desired hostname
    • Desired username
    • Timezone (e.g., America/New_York, Europe/London)
    • Locale (e.g., en_US.UTF-8)

Directory Structure

Create the following structure in /etc/nixos/ or a preferred config directory:

nixos-config/
|-- flake.nix                           # Main flake definition
|-- flake.lock                          # Auto-generated after first build
|-- hosts/
|   +-- <hostname>/
|       +-- hardware-configuration.nix  # Copy from /etc/nixos/
+-- modules/
    |-- common.nix                      # Shared configuration
    |-- dev.nix                         # Development profile
    +-- gaming.nix                      # Gaming profile

File Contents

1. flake.nix

Location: nixos-config/flake.nix

Purpose: Defines flake inputs (nixpkgs, MangoWC, Quickshell, Noctalia) and two separate nixosConfigurations.

{
  description = "NixOS - Isolated Gaming & Dev configurations";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

    mango = {
      url = "github:DreamMaoMao/mango";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    quickshell = {
      url = "github:outfoxxed/quickshell";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    noctalia = {
      url = "github:noctalia-dev/noctalia-shell";
      inputs.nixpkgs.follows = "nixpkgs";
      inputs.quickshell.follows = "quickshell";
    };
  };

  outputs = { self, nixpkgs, mango, quickshell, noctalia, ... }@inputs:
  let
    system = "x86_64-linux";
    specialArgs = { inherit inputs system; };

    # IMPORTANT: Replace <hostname> with actual hostname
    commonModules = [
      ./hosts/<hostname>/hardware-configuration.nix
      ./modules/common.nix
      mango.nixosModules.mango
    ];
  in {
    nixosConfigurations = {
      # Development configuration
      dev = nixpkgs.lib.nixosSystem {
        inherit system specialArgs;
        modules = commonModules ++ [ ./modules/dev.nix ];
      };

      # Gaming configuration
      gaming = nixpkgs.lib.nixosSystem {
        inherit system specialArgs;
        modules = commonModules ++ [ ./modules/gaming.nix ];
      };
    };
  };
}

Required substitutions:

  • Replace <hostname> in the commonModules path with the actual hostname

2. modules/common.nix

Location: nixos-config/modules/common.nix

Purpose: Shared configuration for both profiles - hardware, GPU, desktop environment, user account, base packages.

{ config, pkgs, inputs, system, ... }:

{
  # --------------------------------------------------------------------------
  # BOOT
  # -----------------...

</details>



<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.
- [x] Address PR review comments - [x] Replace `initialPassword` with `hashedPassword` placeholder for security - [x] Change `hardware.enableAllFirmware` to `hardware.enableRedistributableFirmware` - [x] Fix gamemode renice value to -10 (higher priority for games) - [x] Remove duplicate `amd_pstate=active` kernel param from gaming.nix - [x] Remove `mitigations=off` for security (was disabling CPU mitigations) - [x] Update `system.stateVersion` from "25.05" to "24.11" - [x] Add greetd configuration for auto-starting MangoWC - [x] Add assertion to verify mango flake module exists - [x] Add security note about flake.lock and supply chain protection - [x] Update nerd fonts comment for clarity - [x] Add comment about profile-specific group membership in gaming.nix - [x] Add comment about Docker group logout requirement in dev.nix - [x] Uncomment filesystem examples with clear placeholder UUIDs - [x] Improve README with clearer setup instructions - [x] Add comment clarifying mango binary source in greetd config <!-- START COPILOT CODING AGENT SUFFIX --> <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> # NixOS Dual-Configuration Setup Plan ## Overview Create a NixOS system with **two fully isolated configurations**: 1. **Dev** - Stable, LTS kernel, web development tooling (Docker, Node.js, direnv) 2. **Gaming** - Zen kernel, Steam, Lutris, performance tools Both share a common base: MangoWC (Wayland compositor) + Noctalia Shell, AMD RDNA 4 GPU support, and a shared `/home` directory with mutable dotfiles. ### Why Separate Configs (Not Specialisations)? NixOS offers "specialisations" for boot-time variants, but this plan uses separate `nixosConfigurations` because: - **True isolation**: Dev has zero gaming packages, Gaming has zero dev tools - **User preference**: Explicitly requested complete separation - **Clarity**: Each config is self-contained and easier to reason about **Trade-off**: You must rebuild both configs separately and keep them in sync to avoid kernel/Mesa version drift (critical for RDNA 4). If you prefer simpler maintenance, specialisations are a valid alternative. --- ## Target System Specifications ### Hardware | Component | Model | Architecture | Notes | |-----------|-------|--------------|-------| | CPU | AMD Ryzen 7 5700G | Zen 3 (Cezanne) | Mature support, iGPU available for secondary display | | GPU | AMD RX 9060 XT | RDNA 4 (Navi 44) | Requires Kernel 6.14+, Mesa 25.0+ | | Motherboard | MSI B550 Tomahawk | AM4 Chipset | Excellent IOMMU groups for passthrough | ### Software | Component | Value | |-----------|-------| | Compositor | MangoWC | | Shell | Noctalia (built on Quickshell) | | Nixpkgs Channel | nixos-unstable (tracks Kernel 6.15+, Mesa 25.x) | | Dev Kernel | Latest stable (linuxPackages_latest) | | Gaming Kernel | Zen (linuxPackages_zen) | | Home Manager | Not used - mutable dotfiles | ### RDNA 4 Requirements The RX 9060 XT (released ~June 2025) has specific requirements: - **Kernel:** 6.14+ mandatory (nixos-unstable provides this) - **Mesa:** 25.0+ mandatory (nixos-unstable provides this) - **Firmware:** Requires `navi44_*.bin` blobs - must enable all firmware --- ## Prerequisites Before running this plan: 1. NixOS must already be installed (minimal install is fine) 2. `hardware-configuration.nix` must exist from the installation 3. Flakes must be enabled in the existing config or via: ```bash nix-shell -p nixFlakes ``` 4. User must know their: - Desired hostname - Desired username - Timezone (e.g., `America/New_York`, `Europe/London`) - Locale (e.g., `en_US.UTF-8`) --- ## Directory Structure Create the following structure in `/etc/nixos/` or a preferred config directory: ``` nixos-config/ |-- flake.nix # Main flake definition |-- flake.lock # Auto-generated after first build |-- hosts/ | +-- <hostname>/ | +-- hardware-configuration.nix # Copy from /etc/nixos/ +-- modules/ |-- common.nix # Shared configuration |-- dev.nix # Development profile +-- gaming.nix # Gaming profile ``` --- ## File Contents ### 1. flake.nix **Location:** `nixos-config/flake.nix` **Purpose:** Defines flake inputs (nixpkgs, MangoWC, Quickshell, Noctalia) and two separate nixosConfigurations. ```nix { description = "NixOS - Isolated Gaming & Dev configurations"; inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; mango = { url = "github:DreamMaoMao/mango"; inputs.nixpkgs.follows = "nixpkgs"; }; quickshell = { url = "github:outfoxxed/quickshell"; inputs.nixpkgs.follows = "nixpkgs"; }; noctalia = { url = "github:noctalia-dev/noctalia-shell"; inputs.nixpkgs.follows = "nixpkgs"; inputs.quickshell.follows = "quickshell"; }; }; outputs = { self, nixpkgs, mango, quickshell, noctalia, ... }@inputs: let system = "x86_64-linux"; specialArgs = { inherit inputs system; }; # IMPORTANT: Replace <hostname> with actual hostname commonModules = [ ./hosts/<hostname>/hardware-configuration.nix ./modules/common.nix mango.nixosModules.mango ]; in { nixosConfigurations = { # Development configuration dev = nixpkgs.lib.nixosSystem { inherit system specialArgs; modules = commonModules ++ [ ./modules/dev.nix ]; }; # Gaming configuration gaming = nixpkgs.lib.nixosSystem { inherit system specialArgs; modules = commonModules ++ [ ./modules/gaming.nix ]; }; }; }; } ``` **Required substitutions:** - Replace `<hostname>` in the `commonModules` path with the actual hostname --- ### 2. modules/common.nix **Location:** `nixos-config/modules/common.nix` **Purpose:** Shared configuration for both profiles - hardware, GPU, desktop environment, user account, base packages. ```nix { config, pkgs, inputs, system, ... }: { # -------------------------------------------------------------------------- # BOOT # -----------------... </details> <!-- START COPILOT CODING AGENT TIPS --> --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.
ragusa-it (Migrated from github.com) reviewed 2026-02-01 19:33:01 +00:00
ragusa-it (Migrated from github.com) approved these changes 2026-02-01 19:43:49 +00:00
copilot-pull-request-reviewer[bot] (Migrated from github.com) reviewed 2026-02-01 19:45:13 +00:00
copilot-pull-request-reviewer[bot] (Migrated from github.com) left a comment

Pull request overview

This PR implements a NixOS flake-based configuration system with two isolated profiles (dev and gaming) that share a common base configuration. The setup targets a specific hardware configuration (AMD Ryzen 7 5700G with AMD RX 9060 XT RDNA 4 GPU) and uses MangoWC compositor with Noctalia shell.

Changes:

  • Created a flake-based NixOS configuration with dual profiles supporting independent kernel and package selections
  • Implemented shared base configuration with AMD RDNA 4 GPU support, PipeWire audio, and MangoWC/Noctalia desktop environment
  • Added comprehensive documentation covering setup, usage, troubleshooting, and post-installation steps

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 19 comments.

Show a summary per file
File Description
flake.nix Defines dual nixosConfigurations (dev/gaming) with flake inputs for MangoWC, Quickshell, and Noctalia
modules/common.nix Shared configuration for AMD GPU/CPU optimization, desktop environment, user account, and system settings
modules/dev.nix Development profile with latest kernel, Docker, Node.js 22, and CLI development tools
modules/gaming.nix Gaming profile with Zen kernel, Steam, performance tools, and gaming-specific system tuning
hosts/hostname/hardware-configuration.nix Placeholder hardware configuration file with example structure and warnings
README.md Comprehensive documentation with setup instructions, configuration summary, and troubleshooting guide

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

## Pull request overview This PR implements a NixOS flake-based configuration system with two isolated profiles (dev and gaming) that share a common base configuration. The setup targets a specific hardware configuration (AMD Ryzen 7 5700G with AMD RX 9060 XT RDNA 4 GPU) and uses MangoWC compositor with Noctalia shell. **Changes:** - Created a flake-based NixOS configuration with dual profiles supporting independent kernel and package selections - Implemented shared base configuration with AMD RDNA 4 GPU support, PipeWire audio, and MangoWC/Noctalia desktop environment - Added comprehensive documentation covering setup, usage, troubleshooting, and post-installation steps ### Reviewed changes Copilot reviewed 6 out of 6 changed files in this pull request and generated 19 comments. <details> <summary>Show a summary per file</summary> | File | Description | | ---- | ----------- | | flake.nix | Defines dual nixosConfigurations (dev/gaming) with flake inputs for MangoWC, Quickshell, and Noctalia | | modules/common.nix | Shared configuration for AMD GPU/CPU optimization, desktop environment, user account, and system settings | | modules/dev.nix | Development profile with latest kernel, Docker, Node.js 22, and CLI development tools | | modules/gaming.nix | Gaming profile with Zen kernel, Steam, performance tools, and gaming-specific system tuning | | hosts/hostname/hardware-configuration.nix | Placeholder hardware configuration file with example structure and warnings | | README.md | Comprehensive documentation with setup instructions, configuration summary, and troubleshooting guide | </details> --- 💡 <a href="/ragusa-it/nixos/new/main/.github/instructions?filename=*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.
@@ -1 +1,228 @@
# nixos
# NixOS Dual-Configuration Setup
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:09 +00:00

The README states that files must be staged in git before building (line 69: "git add .") and mentions this again in troubleshooting (line 182), but the initial setup instructions in step 4 "Build and Switch" don't explicitly remind users to do this before running nixos-rebuild. Users might miss step 3 and try to build without staging files, leading to confusing errors. Consider adding a reminder or verification step in the build instructions.

The README states that files must be staged in git before building (line 69: "git add .") and mentions this again in troubleshooting (line 182), but the initial setup instructions in step 4 "Build and Switch" don't explicitly remind users to do this before running nixos-rebuild. Users might miss step 3 and try to build without staging files, leading to confusing errors. Consider adding a reminder or verification step in the build instructions.
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:10 +00:00

The README instructs users to "rename hosts/hostname/ to match your actual hostname" (line 63), but the actual flake.nix expects the path to be "./hosts/<hostname>/hardware-configuration.nix" where <hostname> is a placeholder that needs to be replaced in the flake.nix itself (line 31). This creates ambiguity: should users rename the directory AND update flake.nix, or just update flake.nix? The instructions should be clearer that both the directory name and the reference in flake.nix need to match the actual hostname.

Also rename the `hosts/<hostname>/` directory to match your actual hostname, and ensure the same hostname is used for all `<hostname>` placeholders (including in `flake.nix`).
The README instructs users to "rename hosts/hostname/ to match your actual hostname" (line 63), but the actual flake.nix expects the path to be "./hosts/&lt;hostname&gt;/hardware-configuration.nix" where &lt;hostname&gt; is a placeholder that needs to be replaced in the flake.nix itself (line 31). This creates ambiguity: should users rename the directory AND update flake.nix, or just update flake.nix? The instructions should be clearer that both the directory name and the reference in flake.nix need to match the actual hostname. ```suggestion Also rename the `hosts/<hostname>/` directory to match your actual hostname, and ensure the same hostname is used for all `<hostname>` placeholders (including in `flake.nix`). ```
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:10 +00:00

The README instructs users to run "sudo nixos-rebuild boot --profile-name gaming" (line 86) but this will only build the gaming profile without making it immediately available. The user won't be able to boot into the gaming profile until after a reboot. Consider clarifying in the README that the gaming profile will only be available after the next reboot, or consider using "sudo nixos-rebuild test --flake .#gaming" first to verify the gaming config works before committing to it as a boot option.

# (Optional but recommended) Test gaming config without committing it as a boot option
sudo nixos-rebuild test --flake .#gaming

# Build gaming config as a separate boot profile (will be available after the next reboot)
The README instructs users to run "sudo nixos-rebuild boot --profile-name gaming" (line 86) but this will only build the gaming profile without making it immediately available. The user won't be able to boot into the gaming profile until after a reboot. Consider clarifying in the README that the gaming profile will only be available after the next reboot, or consider using "sudo nixos-rebuild test --flake .#gaming" first to verify the gaming config works before committing to it as a boot option. ```suggestion # (Optional but recommended) Test gaming config without committing it as a boot option sudo nixos-rebuild test --flake .#gaming # Build gaming config as a separate boot profile (will be available after the next reboot) ```
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:12 +00:00

The autostart script created in lines 138-142 uses "qs -c noctalia-shell" but this requires the quickshell binary to be in PATH. While quickshell is installed as a user package (common.nix line 83), the full command might need to be more specific or use the full path. Additionally, there's no error handling if noctalia-shell fails to start. Consider adding error handling or verification steps to the README.

The autostart script created in lines 138-142 uses "qs -c noctalia-shell" but this requires the quickshell binary to be in PATH. While quickshell is installed as a user package (common.nix line 83), the full command might need to be more specific or use the full path. Additionally, there's no error handling if noctalia-shell fails to start. Consider adding error handling or verification steps to the README.
@@ -2,0 +46,4 @@
cd ~/nixos-config
# Create the host directory (replace <hostname> with your actual hostname)
mkdir -p hosts/<hostname>
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:11 +00:00

The README instructs users to "cp /etc/nixos/hardware-configuration.nix hosts/<hostname>/" (line 49), but this assumes the hosts/<hostname>/ directory already exists. If users haven't renamed the directory yet (as per line 63), this command will fail. The setup instructions should specify creating or renaming the directory first, then copying the hardware configuration.


# Create the host directory (replace <hostname> with your actual hostname)
mkdir -p hosts/<hostname>
The README instructs users to "cp /etc/nixos/hardware-configuration.nix hosts/&lt;hostname&gt;/" (line 49), but this assumes the hosts/&lt;hostname&gt;/ directory already exists. If users haven't renamed the directory yet (as per line 63), this command will fail. The setup instructions should specify creating or renaming the directory first, then copying the hardware configuration. ```suggestion # Create the host directory (replace <hostname> with your actual hostname) mkdir -p hosts/<hostname> ```
@@ -2,0 +115,4 @@
sudo nixos-rebuild boot --profile-name gaming --flake .#gaming
```
### Updating Flake Inputs Only
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:12 +00:00

The update instructions start with "git add ." (line 101) which suggests staging all changes, but this is only appropriate if the user has made configuration changes. If they're just updating flake inputs (as shown in lines 108-112), they only need to stage flake.lock. The "git add ." command could accidentally stage unwanted changes. Consider clarifying when to use "git add ." versus just "git add flake.lock".

The update instructions start with "git add ." (line 101) which suggests staging all changes, but this is only appropriate if the user has made configuration changes. If they're just updating flake inputs (as shown in lines 108-112), they only need to stage flake.lock. The "git add ." command could accidentally stage unwanted changes. Consider clarifying when to use "git add ." versus just "git add flake.lock".
@@ -0,0 +1,58 @@
{
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:11 +00:00

The flake.nix uses "mango.nixosModules.mango" (line 33) but there's no verification that this module exists or is exported by the mango flake. If the mango repository doesn't export a nixosModules.mango output, this will cause a build failure. Consider adding a note in the README about verifying the flake inputs or handling potential issues if the upstream flakes change their output schema.

    mangoModule =
      let
        lib = nixpkgs.lib;
      in
      assert lib.hasAttrByPath [ "nixosModules" "mango" ] mango;
      mango.nixosModules.mango;

    # IMPORTANT: Replace <hostname> with actual hostname
    commonModules = [
      ./hosts/<hostname>/hardware-configuration.nix
      ./modules/common.nix
      mangoModule
The flake.nix uses "mango.nixosModules.mango" (line 33) but there's no verification that this module exists or is exported by the mango flake. If the mango repository doesn't export a nixosModules.mango output, this will cause a build failure. Consider adding a note in the README about verifying the flake inputs or handling potential issues if the upstream flakes change their output schema. ```suggestion mangoModule = let lib = nixpkgs.lib; in assert lib.hasAttrByPath [ "nixosModules" "mango" ] mango; mango.nixosModules.mango; # IMPORTANT: Replace <hostname> with actual hostname commonModules = [ ./hosts/<hostname>/hardware-configuration.nix ./modules/common.nix mangoModule ```
@@ -0,0 +21,4 @@
url = "github:noctalia-dev/noctalia-shell";
inputs.nixpkgs.follows = "nixpkgs";
inputs.quickshell.follows = "quickshell";
};
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:13 +00:00

The flake inputs declare third-party NixOS modules (mango, quickshell, noctalia) via mutable GitHub references without a committed flake.lock, so new clones or rebuilds will automatically track whatever commit is at the head of those repositories. Because these modules are integrated into the system as NixOS modules (running code as root at build and runtime), a compromise of any upstream repo or a malicious update could silently introduce arbitrary code into your system. Commit a flake.lock to pin these inputs to specific immutable commits (and update them only via nix flake update) or otherwise explicitly pin them to trusted revisions to reduce this supply-chain risk.

The flake `inputs` declare third-party NixOS modules (`mango`, `quickshell`, `noctalia`) via mutable GitHub references without a committed `flake.lock`, so new clones or rebuilds will automatically track whatever commit is at the head of those repositories. Because these modules are integrated into the system as NixOS modules (running code as root at build and runtime), a compromise of any upstream repo or a malicious update could silently introduce arbitrary code into your system. Commit a `flake.lock` to pin these inputs to specific immutable commits (and update them only via `nix flake update`) or otherwise explicitly pin them to trusted revisions to reduce this supply-chain risk.
@@ -0,0 +1,44 @@
# This is a placeholder hardware-configuration.nix file.
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:11 +00:00

The filesystem mount configuration is commented out, which means the system won't have any filesystems defined. This will prevent the system from booting. While this is a placeholder file, the commented-out nature makes it more dangerous because it might not fail fast during build time. Consider uncommenting the example filesystem configurations with clear placeholder UUIDs like "REPLACE-WITH-YOUR-ROOT-UUID" to make it more obvious that this needs to be configured.

  fileSystems."/" = {
    # Replace this UUID with the actual root filesystem UUID for your system.
    device = "/dev/disk/by-uuid/REPLACE-WITH-YOUR-ROOT-UUID";
    fsType = "ext4";
  };

  fileSystems."/boot" = {
    # Replace this UUID with the actual /boot filesystem UUID for your system.
    device = "/dev/disk/by-uuid/REPLACE-WITH-YOUR-BOOT-UUID";
    fsType = "vfat";
  };

  swapDevices = [
    # Replace this UUID with the actual swap partition UUID for your system.
    { device = "/dev/disk/by-uuid/REPLACE-WITH-YOUR-SWAP-UUID"; }
  ];
The filesystem mount configuration is commented out, which means the system won't have any filesystems defined. This will prevent the system from booting. While this is a placeholder file, the commented-out nature makes it more dangerous because it might not fail fast during build time. Consider uncommenting the example filesystem configurations with clear placeholder UUIDs like "REPLACE-WITH-YOUR-ROOT-UUID" to make it more obvious that this needs to be configured. ```suggestion fileSystems."/" = { # Replace this UUID with the actual root filesystem UUID for your system. device = "/dev/disk/by-uuid/REPLACE-WITH-YOUR-ROOT-UUID"; fsType = "ext4"; }; fileSystems."/boot" = { # Replace this UUID with the actual /boot filesystem UUID for your system. device = "/dev/disk/by-uuid/REPLACE-WITH-YOUR-BOOT-UUID"; fsType = "vfat"; }; swapDevices = [ # Replace this UUID with the actual swap partition UUID for your system. { device = "/dev/disk/by-uuid/REPLACE-WITH-YOUR-SWAP-UUID"; } ]; ```
@@ -0,0 +1,182 @@
{ config, pkgs, inputs, system, ... }:
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:09 +00:00

Setting initialPassword to a plaintext "changeme" is a security concern. While this is mentioned in the comment as temporary, it means the system will boot with a known weak password. Consider using hashedPassword instead, or at a minimum, add a prominent warning in the README that users must change this password immediately after first boot. The current README does mention changing the password in the Post-Installation section, but it should be more prominent.

    # IMPORTANT: Set a secure password hash (e.g. via `mkpasswd -m sha-512`) before using this config
    hashedPassword = "<replace-with-password-hash>";
Setting initialPassword to a plaintext "changeme" is a security concern. While this is mentioned in the comment as temporary, it means the system will boot with a known weak password. Consider using hashedPassword instead, or at a minimum, add a prominent warning in the README that users must change this password immediately after first boot. The current README does mention changing the password in the Post-Installation section, but it should be more prominent. ```suggestion # IMPORTANT: Set a secure password hash (e.g. via `mkpasswd -m sha-512`) before using this config hashedPassword = "<replace-with-password-hash>"; ```
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:10 +00:00

The PR description mentions that RDNA 4 requires "navi44_*.bin" firmware blobs and uses "hardware.enableAllFirmware = true" to enable them. However, this setting enables ALL firmware including potentially problematic non-free firmware. A more targeted approach would be to use "hardware.enableRedistributableFirmware = true" which enables AMD GPU firmware but excludes some problematic firmware. If specific navi44 firmware is needed that's not in redistributable, users can be directed to add specific firmware packages.

  hardware.enableRedistributableFirmware = true;
The PR description mentions that RDNA 4 requires "navi44_*.bin" firmware blobs and uses "hardware.enableAllFirmware = true" to enable them. However, this setting enables ALL firmware including potentially problematic non-free firmware. A more targeted approach would be to use "hardware.enableRedistributableFirmware = true" which enables AMD GPU firmware but excludes some problematic firmware. If specific navi44 firmware is needed that's not in redistributable, users can be directed to add specific firmware packages. ```suggestion hardware.enableRedistributableFirmware = true; ```
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:10 +00:00

The comment states "Nerd fonts - syntax changed in nixpkgs after 24.05" and shows the new individual package syntax being used. However, this configuration is explicitly targeting nixos-unstable which should use this syntax. The comment could be misleading for users on unstable who won't encounter the old syntax. Consider updating the comment to clarify this is the current syntax for nixos-unstable (and nixos versions after 24.05).

    # Nerd fonts: current syntax for nixos-unstable and NixOS ≥ 24.05
    # For older nixpkgs (before this change), use:
    #   (nerdfonts.override { fonts = [ "JetBrainsMono" ]; })
The comment states "Nerd fonts - syntax changed in nixpkgs after 24.05" and shows the new individual package syntax being used. However, this configuration is explicitly targeting nixos-unstable which should use this syntax. The comment could be misleading for users on unstable who won't encounter the old syntax. Consider updating the comment to clarify this is the current syntax for nixos-unstable (and nixos versions after 24.05). ```suggestion # Nerd fonts: current syntax for nixos-unstable and NixOS ≥ 24.05 # For older nixpkgs (before this change), use: # (nerdfonts.override { fonts = [ "JetBrainsMono" ]; }) ```
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:11 +00:00

The system.stateVersion is set to "25.05" which does not follow the NixOS versioning convention. NixOS versions follow the pattern YY.MM (e.g., "24.05", "24.11"), and "25.05" would be released in May 2025. Given the PR description mentions requiring kernel 6.14+ and Mesa 25.0+ from nixos-unstable, and the current date is February 2026, this should likely be "24.11" or "25.05" if that release exists. Verify the correct NixOS release version.

  system.stateVersion = "24.11";
The system.stateVersion is set to "25.05" which does not follow the NixOS versioning convention. NixOS versions follow the pattern YY.MM (e.g., "24.05", "24.11"), and "25.05" would be released in May 2025. Given the PR description mentions requiring kernel 6.14+ and Mesa 25.0+ from nixos-unstable, and the current date is February 2026, this should likely be "24.11" or "25.05" if that release exists. Verify the correct NixOS release version. ```suggestion system.stateVersion = "24.11"; ```
@@ -0,0 +68,4 @@
# Enable seatd for session management
services.seatd.enable = true;
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:12 +00:00

The configuration enables seatd (line 70) which is necessary for MangoWC to function, but there's no configuration for starting MangoWC automatically on boot or login. Users have to manually start it or configure it themselves (as shown in the README post-installation section). For a complete setup, consider mentioning in the README that MangoWC needs to be started manually after the first boot, or provide a display manager option.


  # Use greetd to automatically start a MangoWC session on login
  services.greetd = {
    enable = true;
    settings.default_session = {
      # MangoWC compositor command; ensure this matches the MangoWC binary name
      command = "mango";
      # IMPORTANT: Replace <username> with the same username defined below
      user = "<username>";
    };
  };
The configuration enables seatd (line 70) which is necessary for MangoWC to function, but there's no configuration for starting MangoWC automatically on boot or login. Users have to manually start it or configure it themselves (as shown in the README post-installation section). For a complete setup, consider mentioning in the README that MangoWC needs to be started manually after the first boot, or provide a display manager option. ```suggestion # Use greetd to automatically start a MangoWC session on login services.greetd = { enable = true; settings.default_session = { # MangoWC compositor command; ensure this matches the MangoWC binary name command = "mango"; # IMPORTANT: Replace <username> with the same username defined below user = "<username>"; }; }; ```
@@ -0,0 +22,4 @@
};
};
# IMPORTANT: Replace <username> with actual username
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:12 +00:00

Docker requires the user to log out and log back in after being added to the docker group for the group membership to take effect. Since this configuration adds the user to the docker group, users won't be able to use Docker immediately after the first build without logging out and back in. Consider adding this information to the README in a "Post-Installation" or "First Steps" section for the dev profile.

  # IMPORTANT: Replace <username> with actual username
  # NOTE: This adds the user to the "docker" group so Docker can be used without sudo.
  #       After first enabling/applying this dev profile, you must log out and log
  #       back in (or reboot) for the new group membership to take effect.
  #       Consider documenting this in the README under a "Post-Installation" or
  #       "First Steps" section for the dev profile.
Docker requires the user to log out and log back in after being added to the docker group for the group membership to take effect. Since this configuration adds the user to the docker group, users won't be able to use Docker immediately after the first build without logging out and back in. Consider adding this information to the README in a "Post-Installation" or "First Steps" section for the dev profile. ```suggestion # IMPORTANT: Replace <username> with actual username # NOTE: This adds the user to the "docker" group so Docker can be used without sudo. # After first enabling/applying this dev profile, you must log out and log # back in (or reboot) for the new group membership to take effect. # Consider documenting this in the README under a "Post-Installation" or # "First Steps" section for the dev profile. ```
@@ -0,0 +1,99 @@
{ pkgs, ... }:
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:10 +00:00

The renice value of 10 will make games run with LOWER priority (higher niceness = lower priority). For gaming performance optimization, this should be a negative value like -10 to give games HIGHER priority. The current setting will degrade gaming performance rather than improve it.

        renice = -10;
The renice value of 10 will make games run with LOWER priority (higher niceness = lower priority). For gaming performance optimization, this should be a negative value like -10 to give games HIGHER priority. The current setting will degrade gaming performance rather than improve it. ```suggestion renice = -10; ```
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:11 +00:00

The amd_pstate=active kernel parameter is already set in common.nix (line 49), making this redundant. While the comment mentions it's "for clarity," having duplicate kernel parameters can lead to confusion and maintenance issues. Consider removing this duplicate entry.


The amd_pstate=active kernel parameter is already set in common.nix (line 49), making this redundant. While the comment mentions it's "for clarity," having duplicate kernel parameters can lead to confusion and maintenance issues. Consider removing this duplicate entry. ```suggestion ```
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:12 +00:00

The gaming profile sets boot.kernelParams to include "mitigations=off", which disables CPU security mitigations for speculative execution and related vulnerabilities. This exposes the system to a broad class of local-attack and potential VM escape primitives, especially in multi-user or virtualization scenarios, purely for a small performance gain. Remove "mitigations=off" (or use more targeted mitigation flags) so the kernel retains its default hardening against these attacks.


The gaming profile sets `boot.kernelParams` to include `"mitigations=off"`, which disables CPU security mitigations for speculative execution and related vulnerabilities. This exposes the system to a broad class of local-attack and potential VM escape primitives, especially in multi-user or virtualization scenarios, purely for a small performance gain. Remove `"mitigations=off"` (or use more targeted mitigation flags) so the kernel retains its default hardening against these attacks. ```suggestion ```
@@ -0,0 +54,4 @@
# the gaming profile. If you need consistent group membership across
# both profiles, add these groups to common.nix instead.
# IMPORTANT: Replace <username> with actual username
users.users.<username>.extraGroups = [ "corectrl" "gamemode" ];
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-02-01 19:45:09 +00:00

Both gaming.nix (line 52) and dev.nix (line 26) attempt to add extraGroups to the same user that is already configured in common.nix (line 76-80). In NixOS, when multiple modules configure the same user attribute (extraGroups in this case), the lists are concatenated. However, the common.nix already defines extraGroups = [ "wheel" "networkmanager" "video" "seat" ], and both profiles add their own groups. This works correctly, but it means switching between profiles will have different group memberships for the same user, which could lead to permission issues if files/processes from one profile expect certain groups. Consider documenting this behavior or ensuring both profiles include all necessary groups.

  # NOTE:
  # The user must be in the "corectrl" and "gamemode" groups for these
  # programs to function correctly. To avoid profile-specific differences
  # in group membership, add these groups to `users.users.<username>.extraGroups`
  # in your common user configuration (e.g. common.nix), rather than here.
Both gaming.nix (line 52) and dev.nix (line 26) attempt to add extraGroups to the same user that is already configured in common.nix (line 76-80). In NixOS, when multiple modules configure the same user attribute (extraGroups in this case), the lists are concatenated. However, the common.nix already defines extraGroups = [ "wheel" "networkmanager" "video" "seat" ], and both profiles add their own groups. This works correctly, but it means switching between profiles will have different group memberships for the same user, which could lead to permission issues if files/processes from one profile expect certain groups. Consider documenting this behavior or ensuring both profiles include all necessary groups. ```suggestion # NOTE: # The user must be in the "corectrl" and "gamemode" groups for these # programs to function correctly. To avoid profile-specific differences # in group membership, add these groups to `users.users.<username>.extraGroups` # in your common user configuration (e.g. common.nix), rather than here. ```
ragusa-it commented 2026-02-01 19:47:36 +00:00 (Migrated from github.com)

@copilot apply changes based on the comments in this thread

@copilot apply changes based on the comments in [this thread](https://github.com/ragusa-it/nixos/pull/1#pullrequestreview-3736541306)
Copilot commented 2026-02-01 19:50:28 +00:00 (Migrated from github.com)

@copilot apply changes based on the comments in this thread

Applied all review feedback in commit df02e01. Key changes:

Security:

  • Replaced initialPassword with hashedPassword placeholder
  • Changed to enableRedistributableFirmware (more targeted than enableAllFirmware)
  • Removed mitigations=off kernel parameter
  • Added flake.lock security note for supply-chain protection
  • Added assertion to verify mango module exists

Bug fixes:

  • Fixed gamemode renice to -10 (was 10, which lowered priority instead of raising it)
  • Removed duplicate amd_pstate=active from gaming.nix
  • Updated system.stateVersion to "24.11"

Improvements:

  • Added greetd for auto-starting MangoWC
  • Uncommented filesystem examples with clear placeholder UUIDs
  • Improved README with clearer setup steps (mkdir before cp, git staging reminders, test before boot)
  • Added notes about Docker group logout requirement and profile-specific groups
> @copilot apply changes based on the comments in [this thread](https://github.com/ragusa-it/nixos/pull/1#pullrequestreview-3736541306) Applied all review feedback in commit df02e01. Key changes: **Security:** - Replaced `initialPassword` with `hashedPassword` placeholder - Changed to `enableRedistributableFirmware` (more targeted than `enableAllFirmware`) - Removed `mitigations=off` kernel parameter - Added flake.lock security note for supply-chain protection - Added assertion to verify mango module exists **Bug fixes:** - Fixed gamemode `renice` to -10 (was 10, which lowered priority instead of raising it) - Removed duplicate `amd_pstate=active` from gaming.nix - Updated `system.stateVersion` to "24.11" **Improvements:** - Added greetd for auto-starting MangoWC - Uncommented filesystem examples with clear placeholder UUIDs - Improved README with clearer setup steps (mkdir before cp, git staging reminders, test before boot) - Added notes about Docker group logout requirement and profile-specific groups
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ragusa-it/nixos#1