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

1. 1. 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.

1. 1. Severity

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

1. 1. 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)

1. 1. 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

1. 1. Root Cause - THE SMOKING GUN

Found in source code at three locations:

1. 1. 1. 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.

1. 1. 1. 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.

1. 1. 1. 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.

1. 1. 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.

1. 1. 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

1. 1. 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

1. 1. 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.