Created attachment 2109338 [details]
Complete technical analysis with source code evidence, exact file locations, line numbers, and proposed fix

## Summary

Anaconda installer does not add `root=` boot parameter to `/etc/default/grub` when installing on MD RAID root devices (RAID0, RAID1, etc.), causing new kernel installations to generate broken boot entries that fail to boot.

## Severity

High - System fails to boot after kernel upgrades, requires emergency console recovery

## Affected Configurations

- RAID Levels: RAID0, RAID1, RAID4, RAID5, RAID6, RAID10 (any MD RAID used as root)
- Distribution: Fedora 42, Nobara 42 (likely affects all recent Fedora/RHEL derivatives)
- Bootloader: GRUB2 with BLS (Boot Loader Specification)

## Steps to Reproduce

1. Install Fedora/Nobara with MD RAID (mdadm) as root filesystem
   - Example: 4x NVMe drives in RAID0 array (md0) mounted as `/`
2. Complete installation successfully
3. Boot system normally (initial boot works)
4. Install/upgrade kernel via DNF: `dnf upgrade kernel`
5. Reboot and select new kernel from GRUB menu
6. Result: System fails to boot, drops to emergency console

## Root Cause - THE SMOKING GUN

Found in source code at three locations:

### 1. blivet/devices/md.py (line 688-689)
```python
def dracut_setup_args(self):
    return set(["rd.md.uuid=%s" % self.mdadm_format_uuid])
```

This method ONLY returns RAID UUID. It does NOT return root=UUID= or ro.

### 2. pyanaconda/modules/storage/bootloader/base.py (line 826-881)
Calls dracut_setup_args() for RAID device, which only returns rd.md.uuid.
NEVER explicitly adds root=UUID= for the root filesystem.

### 3. pyanaconda/modules/storage/bootloader/grub2.py (line 269)
```python
defaults.write("GRUB_CMDLINE_LINUX=\"%s\"\n" % self.boot_args)
```
Writes boot_args to /etc/default/grub, missing root= parameter.

## Proposed Fix

In pyanaconda/modules/storage/bootloader/base.py, method _set_storage_boot_args(), after line 826:

```python
if storage.root_device:
    root_spec = storage.root_device.fstab_spec
    if root_spec:
        self.boot_args.add("root=%s" % root_spec)
        self.boot_args.add("ro")
```

This is a 10-line fix that works for all storage configurations.

## Evidence from Production System

- Distribution: Nobara 42 (Fedora 42-based)
- Root Device: /dev/md0 (RAID0, 4x NVMe drives)
- Root UUID: 957d9b7f-c9b1-42f7-b4a4-b1b050d622a5
- RAID UUID: ecf1873b:08dfd5d7:7110c8fd:bdb2786e

Generated boot entry (broken):
```
options rd.auto=1 rd.md=1 rd.md.uuid=ecf1873b:08dfd5d7:7110c8fd:bdb2786e ...
```
Missing: root=UUID=957d9b7f... ro

Result: Kernel panic - VFS: Unable to mount root fs

## Why This Matters

1. RAID1 is recommended for production servers (redundancy)
2. RAID0 is used for high-performance workstations (speed)
3. RAID5/6 common for NAS and storage servers
4. These are legitimate, supported configurations, not edge cases

## Not the GRUB2 Probing Bug (BZ #1443144)

This is DISTINCT from the known GRUB2 mdraid probing issue:
- Initial installation succeeds, first kernel boots
- New kernels fail after DNF upgrade
- Fixing /etc/default/grub resolves the issue

Full technical analysis available on request.