### System details

MotherBoard: DS3H V2  & AMD Ryzen 5 56006 (12) @ 4.46 GHz / GeForce RTX 3060 8GB  / 32gb Ram ddr4

### What's wrong?


## What's wrong?

On systems with an **NVIDIA discrete GPU** and a **Realtek NIC using the default `r8169` kernel driver**, both the live ISO and the freshly installed system can fail to boot without manually editing kernel parameters — with no in-installer guidance pointing to either fix. This affects any AMD/Intel + NVIDIA build with an onboard Realtek NIC, not just unusual hardware.

### Symptom 1 — Live ISO hangs on the boot logo and reboots (NVIDIA)

On boot, the GRUB/Limine splash for the live environment shows the Omarchy logo for a few seconds, then the machine reboots on its own before reaching the installer. This happens because the live kernel's `nouveau` driver crashes trying to take over modesetting on the NVIDIA GPU.

**Fix:** add `nomodeset` to the kernel command line in `grub.cfg` (or via the boot menu editor, when the countdown allows it — see note below) lets the live environment boot normally.

### Symptom 2 — Boot hangs further along, past the GPU crash (Realtek)

Even with `nomodeset` applied, some systems still hang later in the boot sequence — visible errors include `RTL_OCP_GPHY_COND` messages and a `Wait Until Kernel Time Synchronized` systemd unit that never completes. This is the default `r8169` driver failing on certain Realtek chips.

**Fix:** adding `modprobe.blacklist=r8169,r8168` to the same kernel command line avoids the hang (network is simply unavailable during install, which the installer already handles fine offline).

### Symptom 3 — Same GPU crash repeats after installation, on the *installed* system

Once installed, the auto-generated Limine entry (via `limine-entry-tool`) does **not** inherit any of the manual kernel parameters used on the live ISO. So the exact same NVIDIA modeset crash reappears the first time the installed system tries to boot, right after entering the disk password — the loading bar hangs around 60-70% and the machine reboots. Since this is a brand-new install, the person has no working system yet to fix it from, and no indication of what to add.

### Extra friction — the boot menu is not always editable in time

On some Limine live-ISO configs, `timeout: 0` + `timeout_style: hidden` means there's no window to press `e` to edit the boot entry before it auto-boots. The only way to add the kernel parameters in that case is to mount the USB stick's FAT32 partition on another machine and hand-edit `grub.cfg` directly (`boot/grub/grub.cfg`), which is not obvious and not documented anywhere in the manual.

## Suggested fix

- Detect an NVIDIA GPU during live-ISO boot (or ship `nomodeset` by default in the live environment, same as some other distro installers do, falling back to accelerated mode after hardware probe) so the live ISO doesn't require a manual edit at all.
- Consider shipping `r8168-dkms` (or blacklisting `r8169` for affected device IDs) as an installer option/prompt when a known-problematic Realtek chip is detected, similar to how NVIDIA DKMS handling is discussed in #4827.
- Have the installer copy over any manual kernel parameters used to boot the live environment into the generated Limine entry for the installed system, so the same NVIDIA crash doesn't reappear on first boot of the fresh install.
- Document the "no menu timeout to press `e`" edge case in the manual, with the fallback of editing `grub.cfg` directly on the USB stick from another machine.

## System details

- NVIDIA discrete GPU (RTX 30-series) + onboard Realtek NIC
- Omarchy 4.0 (Quattro), Limine bootloader, UEFI, Secure Boot disabled
- Reproduced consistently across multiple live-ISO boot attempts, on desktop hardware

Happy to provide more detail (dmesg/journal output, hardware IDs) if useful.