Hello,
Requirements:
I have searched the forum for my issue and found nothing related or helpful
I did find this old post which seems slightly related, but different:
title: boot-hangs-after-initiating-ramdisk-when-installed
topic: #6599
It is different because my situation happens even without attempting to install nvidia drivers.
I have checked the Resources category
I have reviewed the wiki for relevant information
I have read the the Release Notes and Errata
OpenMandriva Lx version:
OpenMandriva Lx release 25.06 (ROME) Rolling for x86_64
Desktop environment (KDE, LXQT…):
KDE
Description of the issue (screenshots if relevant):
My OM computer was starting to show lots of issues, since first installing in June of 2025. The biggest unsolvable issue was that sometimes the system would just randomly cut to a black screen. Sometimes I could get to TTY from that blackscreen and use A.I. to troubleshoot and reboot. Other times, I had to reinstall OM from scratch.
With the help of A.I., we narrowed down the issue to the official Nvidia driver crashing.
At the time this was happening, the forum had that email sign-up glitch, so I couldn’t get an account and post here.
With the help of A.I., I got the nouveau driver installed and my nvidia driver has otherwise not been able to do anything other than display graphics.
The problem went away from awhile, then the nouveau driver started acting funny.
When I would open up a Dolphin window, the whole computer would hang for about a minute. I could wait it out and the system would kind of recover, but if I mouse hovered over any file or tried to open a folder, the system would hang for another minute.
With the help of Claude, we determined that the nouveau driver was the issue.
There was a new official Nvidia 580 driver release on Jan 13, 2026 that is supposed to support my 980 Ti gpu.
I attempted to install, both via the Welcome Center and via terminal.
Both paths yielded a bizarre bug. When rebooting, the screen would hang at “Loading Initial Ramdisk.”
After troubleshooting for a long time with the help of Claude, I decided to do a complete reinstall, and to switch to ROME (previously, I was using ROCK).
This is where things became very weird. I have asked Claude AI to summarize. I hope you don’t mind the A.I. content. It seems thorough and gets to the point. A lot of this area of computing is outside my area of expertise.
OpenMandriva Rome 25.06 - Critical dracut/initrd Bug Report
Summary
Fresh installations of OpenMandriva Rome 25.06 create initrd images with ZERO kernel modules due to a path format mismatch in modules.dep. The system boots anyway by loading modules after mounting the root filesystem, but this causes complete boot failure when NVIDIA proprietary drivers are installed (system freezes at “Loading initial ramdisk”).
The Bug
The modules.dep file in /lib/modules/$(uname -r)/modules.dep contains relative paths:
kernel/drivers/gpu/drm/nouveau/nouveau.ko.zst
kernel/arch/x86/events/amd/power.ko.zst
kernel/arch/x86/crypto/twofish-x86_64.ko.zst: kernel/crypto/twofish_common.ko.zst
These are relative paths starting with kernel/ rather than absolute paths like:
/lib/modules/6.14.2-desktop-3omv2590/kernel/drivers/gpu/drm/nouveau/nouveau.ko.zst
When dracut builds the initrd, it appears unable to find modules using these relative paths, resulting in an initrd containing no kernel modules whatsoever.
Why The System Still Boots (For Now)
Despite having an empty initrd, the system boots successfully with nouveau (open source) drivers because:
- Initrd boots using basic framebuffer/VESA mode
- Kernel successfully mounts root filesystem from
/dev/sdc2 - systemd/udev loads modules directly from
/lib/modules/after boot - Graphics initialize late but work fine
Evidence - modules are loaded and working:
$ lsmod | grep nouveau
nouveau 3203072 62
drm_gpuvm 45056 1 nouveau
[... many more DRM modules ...]
$ lspci -k | grep -A 3 VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 980]
Kernel driver in use: nouveau
Why NVIDIA Driver Installation Causes Boot Failure
When NVIDIA proprietary drivers are installed:
- Installation blacklists nouveau driver
- dracut rebuilds initrd (still with 0 modules due to modules.dep bug)
- System reboots
- Initrd tries to initialize NVIDIA driver early in boot
- NVIDIA modules aren’t in the initrd (because of the bug)
- System freezes at “Loading initial ramdisk”
- Complete reinstallation required
How to Verify You’re Affected
Check modules.dep format:
head -20 /lib/modules/$(uname -r)/modules.dep
If paths start with kernel/ (relative) instead of /lib/modules/... (absolute), you’re affected.
Check if your initrd contains ANY kernel modules:
sudo lsinitrd /boot/initrd-$(uname -r).img | grep "\.ko" | wc -l
If this returns 0, your initrd has no kernel modules.
Check what’s actually loaded in your running system:
lsmod | wc -l
If this shows many modules (should be 100+), they’re being loaded post-boot, not from initrd.
Reproduction Steps
- Fresh install OpenMandriva Rome 25.06
- Verify
modules.dephas relative paths and initrd has 0 modules - System boots fine with nouveau
- Install NVIDIA drivers:
sudo dnf install dkms-nvidia - Reboot
- System freezes at “Loading initial ramdisk”
System Info
- Distribution: OpenMandriva Lx 25.06 (ROME)
- Kernel: 6.14.2-desktop-3omv2590
- GPU: NVIDIA GTX 980 Ti
- Installation: Fresh install from 6.14 ROCK live USB, then switched to Rome
- Filesystem: ext4 on
/dev/sdc2(root),/dev/sdc3(home)
Questions for Developers
- Which package generates
modules.depwith relative paths? (kmod? depmod?) - Should dracut be patched to handle relative paths, or should modules.dep generation be fixed to use absolute paths?
- Is this affecting all Rome 25.06 installations?
- Why does the current boot process work without modules in initrd, and is this intentional?
- Are there other scenarios besides NVIDIA driver installation that could trigger boot failure?
Impact
- All fresh Rome 25.06 installations appear to have empty initrd images
- System works with open source drivers (nouveau, radeon, etc.) because modules load post-boot
- Installing proprietary NVIDIA drivers causes unrecoverable boot failure
- Potentially affects other scenarios requiring early module loading
Relevant informations (hardware involved, software version, logs or output…):
$ inxi -Fxz
System:
Kernel: 6.14.2-desktop-3omv2590 arch: x86_64 bits: 64 compiler: clang
v: 19.1.7
Desktop: KDE Plasma v: 6.3.4 Distro: OpenMandriva Lx 25.06 ROME
Machine:
Type: Desktop Mobo: ASUSTeK model: H170 PRO GAMING v: Rev X.0x
serial: <superuser required> UEFI: American Megatrends v: 3805
date: 05/16/2018
CPU:
Info: quad core model: Intel Core i5-6600 bits: 64 type: MCP arch: Skylake-S
rev: 3 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB
Speed (MHz): avg: 3692 min/max: 800/3900 cores: 1: 3692 2: 3692 3: 3692
4: 3692 bogomips: 26399
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: NVIDIA GM204 [GeForce GTX 980] vendor: eVga.com. driver: nouveau
v: kernel arch: Maxwell bus-ID: 01:00.0 temp: 47.0 C
Display: x11 server: X.org v: 1.21.1.18 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: nouveau gpu: nouveau resolution: 1920x1080~60Hz
API: EGL v: 1.5 drivers: nouveau,swrast platforms:
active: gbm,x11,surfaceless,device inactive: wayland
API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 25.0.7 glx-v: 1.4
direct-render: yes renderer: NV124
API: Vulkan v: 1.4.312 drivers: N/A surfaces: xcb,xlib devices: 1
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console
x11: xdpyinfo, xprop, xrandr
Audio:
Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASUSTeK
driver: snd_hda_intel v: kernel bus-ID: 00:1f.3
Device-2: NVIDIA GM204 High Definition Audio vendor: eVga.com.
driver: snd_hda_intel v: kernel bus-ID: 01:00.1
API: ALSA v: k6.14.2-desktop-3omv2590 status: kernel-api
Server-1: PipeWire v: 1.4.4 status: active
Network:
Device-1: Intel Ethernet I219-V vendor: ASUSTeK driver: e1000e v: kernel
port: N/A bus-ID: 00:1f.6
IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: <filter>
Device-2: Broadcom BCM4360 802.11ac Dual Band Wireless Network Adapter
vendor: ASUSTeK driver: bcma-pci-bridge v: N/A bus-ID: 02:00.0
Drives:
Local Storage: total: 5.92 TiB used: 63.5 GiB (1.0%)
ID-1: /dev/nvme0n1 vendor: Crucial model: CT4000P3PSSD8 size: 3.64 TiB
temp: 34.9 C
ID-2: /dev/sda vendor: Samsung model: SSD 850 EVO 1TB size: 931.51 GiB
ID-3: /dev/sdb vendor: Samsung model: SSD 840 EVO 1TB size: 931.51 GiB
ID-4: /dev/sdc vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB
ID-5: /dev/sdd vendor: Kingston model: DataTraveler 3.0 size: 7.2 GiB
type: USB
Partition:
ID-1: / size: 287.31 GiB used: 6.16 GiB (2.1%) fs: ext4 dev: /dev/sdc2
ID-2: /boot/efi size: 299.4 MiB used: 2 MiB (0.7%) fs: vfat dev: /dev/sdc1
ID-3: /home size: 161.04 GiB used: 57.33 GiB (35.6%) fs: ext4
dev: /dev/sdc3
Swap:
ID-1: swap-1 type: zram size: 7.79 GiB used: 123.3 MiB (1.5%)
dev: /dev/zram0
ID-2: swap-2 type: partition size: 7.81 GiB used: 0 KiB (0.0%)
dev: /dev/sdc4
Sensors:
System Temperatures: cpu: 31.0 C mobo: N/A gpu: nouveau temp: 47.0 C
Fan Speeds (rpm): N/A gpu: nouveau fan: 0
Info:
Memory: total: 16 GiB available: 15.57 GiB used: 3.43 GiB (22.0%)
Processes: 242 Uptime: 1h 9m Init: systemd target: graphical (5)
Packages: N/A note: see --rpm Compilers: N/A Shell: Bash v: 5.2.37
inxi: 3.3.37