Files
debianito-post-install/docs/kernel.md
T
stornic56 2708d6dcb5 add retroarch, nvidia - java - internet refactor
- NVIDIA CUDA extrepo refactor in `modules/gpu/nvidia.sh`: removed unnecessary `i386_active` lines, updated warning to reference `v590 (unified metapackage)`, simplified installation from 18+10 versioned packages → `nvidia-driver-pinning-590 nvidia-driver firmware-nvidia-gsp`, eliminated `apt-mark hold` since pinning packages now handle it. DKMS verification and `NVIDIA_DRIVER_MODE="cuda-repo"` preserved.
- CUDA repo case fix in `modules/gaming.sh`: replaced silent bypass with detection of `nvidia-driver-libs:i386` v590 installation; if missing, prompts user confirmation before installing via active CUDA repo + pinning.
- Palemoon internet module overhaul (`modules/extras/internet/internet.sh`): removed deprecated `_enable_palemoon_repo()`, created new `install_palemoon()` with AVX2→AVX→SSE2 CPU detection from `/proc/cpuinfo`, proper `extrepo enable` call, and package installation.
- ProtonVPN module rewrite (`modules/extras/internet/internet.sh`): removed broken `_enable_protonvpn_repo()` that failed due to missing suite; created new `install_protonvpn()` using `stable` suite + `proton-vpn-gtk-app` package with proper validation.
- Java/Minecraft rename across `modules/gaming.sh` and `modules/extras/java.sh`: renamed `_install_gaming_java()` → `install_minecraft_java()`, updated menu title from "Java Runtimes for Gaming" to "Java Runtimes for Minecraft", changed whiptail tag from `"java-jre"` to `"java"`.
- RetroArch + 4 classic cores (`modules/gaming/tools.sh` and `.sh`): added RetroArch entry to gaming menu, new case handler in `gaming.sh`, updated installation command to include `libretro-mgba libretro-snes9x libretro-nestopia libretro-gambatte`, enhanced notice with emojis, core enumeration, DFSG warning, and wiki link.
- OnlyOffice server status (`modules/extras/office/office.sh`): added fallback message for slow or down OnlyOffice servers to improve user experience during installation.
- Full syntax validation: all modified files pass `bash -n` without errors; no residual references to old variables (`i386_active`, `590.48.01`) or functions remain.
- Documentation about Debian and the script is added to supplement important information.
- update README.md
2026-06-20 21:54:59 -05:00

7.0 KiB

Option 6: Debian Backports Kernel Integration

1. Why a Backports Kernel?

The decision to integrate the Debian Backports kernel into debianito.sh is driven by the fundamental architectural conflict between Stability and Hardware Enablement.

Debian Stable (including Debian 13 "Trixie") prioritizes long-term reliability. As a result, its kernel version is frozen at a Long Term Support (LTS) release—in this case, Linux 6.12 LTS. While 6.12 is robust and secure, it represents a snapshot of the upstream kernel from late 2024/early 2025. It does not include the rapid stream of hardware enablement, scheduler refinements, or power management optimizations that occur in subsequent releases (e.g., Linux 7.0+).

For users with modern hardware released between 2025 and 2026, this freeze creates a compatibility gap:

  • New Architectures: CPUs like Intel Arrow Lake/Panther Lake or AMD Zen 5 require specific microcode, scheduler hints (e.g., "slow workload hints"), and CXL support that are absent in the frozen 6.12 LTS branch.
  • Graphics Performance: New GPUs (Intel Battlemage) may lack optimized power states (like D3cold enablement) or improved driver integration found in newer kernels.
  • Filesystem Integrity: Advanced features like XFS self-healing or Btrfs remap-tree improvements are exclusive to newer kernel versions.

The kernel.sh module leverages the Debian Backports repository (trixie-backports) as a "best-effort" bridge. This allows users to opt-in to Kernel 7.0+ without abandoning the Stable base entirely. The script ensures that this upgrade is treated as an exception, providing access to modern enablement while maintaining the safety net of the Stable ecosystem for core system packages.

2. Synchronized Installation Pipeline (Kernel + Headers)

A critical engineering principle in kernel management is Atomicity. Installing a new kernel image without its corresponding headers breaks the build chain for third-party modules (such as NVIDIA DKMS, VirtualBox, or ZFS). The install_kernel_backports function enforces this by ensuring the installation command targets both components.

The Installation Command Logic: The script utilizes apt with a specific target release flag to pull packages from the backports suite:

sudo apt install -y -t ${DEBIAN_CODENAME}-backports linux-image-amd64

While Debian's dependency resolver often pulls headers automatically when installing linux-image, explicit documentation and engineering best practices dictate that the system must be configured to ensure both are present. The pipeline operates as follows:

  1. Target Specification (-t): The flag -t ${DEBIAN_CODENAME}-backports explicitly directs APT to ignore the Stable repository for this specific transaction, ensuring the latest backported version is selected rather than a cached Stable package.
  2. Image Package: linux-image-amd64 contains the bootable kernel binary and associated modules.
  3. Headers Dependency: Although often implicit, the documentation mandates that linux-headers-amd64 must be present for DKMS drivers to recompile successfully after a reboot. If these are missing, external drivers may fail to load until manually rebuilt against the new headers.

This synchronized approach ensures that when the system boots into the new kernel, all dependent modules have access to the correct symbol tables and build environment provided by the matching headers.

3. Safety Mechanisms and Atomic Operation

To prevent boot loops or system instability, kernel.sh implements several safety checks before executing any installation commands:

  • Pre-flight Repository Validation: The function begins with a strict check using is_backports_enabled(). If the backports repository is not active in /etc/apt/sources.list, the script halts and instructs the user to enable it via Option 3. This prevents accidental dependency conflicts or installation failures due to missing sources.

  • Hardware Compatibility Warnings: The script detects if an NVIDIA GPU is present (GPU_TYPE == "nvidia"). In this scenario, a warning is displayed: "WARNING: may break NVIDIA driver.". This alerts the user that proprietary drivers might require DKMS recompilation against the new headers.

  • Bootloader Update (GRUB): Although not explicitly shown in the minimal kernel.sh snippet provided, standard kernel engineering practice dictates that after a successful installation, the bootloader must be updated to register the new entry:

    sudo update-grub
    

    This ensures the new kernel appears in the GRUB menu and can be set as the default.

  • Fallback Preservation: The script does not remove the previous kernel. Debian's package manager retains older kernels, preserving them in /boot. If the new backports kernel fails to boot (e.g., due to a hardware incompatibility), the user can simply select the previous stable version from the GRUB menu during startup. This "Rollback Safety" is inherent to the Debian Stable model and is reinforced by the script's non-destructive installation approach.

4. Critical Interconnection with Other Modules (Script Ecosystem)

The Backports Kernel module does not operate in isolation; it relies on a tightly coupled ecosystem within debianito.sh to ensure full functionality:

  • Option 4: Firmware & Wireless Drivers: New kernels often introduce support for new hardware IDs, but they require corresponding firmware blobs (e.g., firmware-misc-nonfree). If the user installs Kernel 7.0+ without updating their firmware repository, wireless cards or specific storage controllers may remain unfunctional. The script ensures that Option 4 is logically dependent on a compatible kernel state.

  • Option 5: Graphics Drivers (NVIDIA DKMS): For systems with NVIDIA hardware, the installation of a new kernel triggers a dependency chain for nvidia-dkms. If the user has proprietary drivers installed, they must be recompiled against the new headers provided by the backports kernel. The script's detection logic (HAS_NVIDIA) allows it to warn users or trigger DKMS rebuilds automatically if integrated into a larger workflow.

  • Bullseye-Specific Logic: As seen in debianito.sh, the Backports Kernel module is conditionally loaded based on the Debian version:

    if [ "$DEBIAN_VERSION" = "11" ]; then
        _msg "Not Available" ...
    else
        install_kernel_backports || true
    fi
    

    This ensures that legacy systems (Debian 11 Bullseye) do not attempt to use a backports workflow that may not be supported or stable in older architectures, while newer versions (Bookworm/Trixie) utilize the full feature set.

  • Gaming & Extras: The Backports kernel is often recommended for gaming due to improved scheduler performance and low-latency networking features found in Linux 7.0+. By linking Option 6 with gaming.sh, users can ensure their hardware is tuned correctly before launching high-performance applications.