Nvidia RTX PRO 2000 Blackwell "No devices were found" on ZimaOS 1.6.1

Insight & Feedback
1

Hi everyone,

I am trying to get my new NVIDIA RTX PRO 2000 (Blackwell Architecture) working under ZimaOS 1.6.1, but I’m stuck in a driver/userspace loop. I want to use it for running LLMs locally via Ollama.

The hardware side seems completely fine. When checking the PCIe bus, the card is correctly detected with its Blackwell hardware ID:

Bash

root@ZimaOS:~# lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2d30 (rev a1)
01:00.1 Audio device: NVIDIA Corporation Device 22eb (rev a1)

Since ZimaOS 1.6.1 doesn’t include the old install-nvidia-kernel-open script anymore, I manually downloaded the latest Blackwell-compatible open-kernel driver from Jerry’s repository into /var/lib/extensions/ and forced the merge:

Bash

wget https://github.com/jerrykuku/staff/releases/download/v0.1.3/nvidia-open-kernel-580.105.08-linux-6.12.25.raw
systemd-sysext refresh --force

After doing this, the kernel modules load successfully without any errors:

Bash

root@ZimaOS:~# modprobe nvidia
root@ZimaOS:~# modprobe nvidia-uvm

(Both commands exit with code 0, meaning the 580.105 kernel part is active).

The Problem: Despite the kernel modules being loaded and the hardware being visible on the PCIe bus, running nvidia-smi results in: No devices were found

It looks like the built-in nvidia-smi and userspace tools in ZimaOS 1.6.1 are tracking an older driver branch (like 550/565) that doesn’t recognize the Blackwell Device ID 2d30 yet, mismatching with the forced 580.105 kernel extension.

Is there a newer .raw system extension available for ZimaOS 1.6.1 that updates both the kernel modules AND the userspace tools/nvidia-container-toolkit to the 580+ branch? Or is there an official workaround to get the RTX 50-series / Blackwell cards initialized properly on this OS version?

Any help or official input from the IceWhale team would be greatly appreciated!

2

Hi mate, I checked against my working ZimaCube setup.

Mine is working on ZimaOS with:

NVIDIA-SMI 580.105.08Driver Version: 580.105.08CUDA Version: 13.0

and my kernel module is also:

NVRM version: NVIDIA UNIX x86_64 Kernel Module 580.105.08

So on a working system, the NVIDIA kernel module and the NVIDIA userspace tools both match at 580.105.08.

The difference is that my card is the RTX 2000 Ada Generation, while yours is the RTX PRO 2000 Blackwell, so it may still need newer device ID support or a newer complete NVIDIA extension.

Can you please post:

cat /proc/driver/nvidia/version

nvidia-smi --version

ls -l /dev/nvidia*

dmesg | grep -iE "nvidia|uvm|gsp|firmware|rm|2d30"

If your kernel module shows 580.105.08 but nvidia-smi is older, then it points to a kernel/userspace mismatch.

If both show 580.105.08 but nvidia-smi still says No devices were found, then the problem is more likely Blackwell initialisation, firmware/GSP, or device ID support inside the current ZimaOS NVIDIA extension.

Either way, the dmesg output should show the real reason.

1 Like
3

Hi again,

I followed your advice and dug deeper into the system. Here is the full breakdown of the results.

Surprisingly, there is no version mismatch between userspace and kernel on ZimaOS 1.6.1 with this extension – both are fully synced at 580.105.08, and the device nodes are created. However, initialization still fails at the hardware level.

Here are the outputs from my tests:

1. Version & Dev Nodes Check (Perfect Match):

Bash

~ ➜ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  580.105.08  Wed Oct 29 23:15:11 UTC 2025

~ ➜ nvidia-smi --version
NVIDIA-SMI version  : 580.105.08
NVML version        : 580.105
DRIVER version      : 580.105.08

~ ➜ ls -l /dev/nvidia*
crw-rw-rw- 1 root root 195,   0 May 29 20:48 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 May 29 20:48 /dev/nvidiactl
crw-rw-rw- 1 root root 195, 254 May 29 20:48 /dev/nvidia-modeset

2. The Hardware Initialization Error (dmesg):

Bash

~ ➜ dmesg | grep -iE "nvidia|uvm|gsp|firmware|rm|2d30"
[33877.821747] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:2d30)
 NVRM: installed in this system requires use of the NVIDIA open kernel modules.
[33877.821800] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x22:0x56:884)
[33877.823339] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

3. Attempted Fix (Enforcing Open RM Parameter): To resolve the requires use of the NVIDIA open kernel modules error, I created /etc/modprobe.d/nvidia.conf and explicitly passed the parameter to force-enable the open resource manager for unsupported/new GPUs:

Bash

options nvidia NVreg_OpenRmEnableUnsupportedGpus=1

I also ensured nvidia and nvidia-uvm are loaded at boot via /etc/modules-load.d/nvidia.conf and performed a clean reboot.

The Result: Unfortunately, even with the NVreg_OpenRmEnableUnsupportedGpus=1 flag active at boot, nvidia-smi still returns: No devices were found

Conclusion: Since the versions match and the device files exist, it looks like the current ZimaOS 1.6.1 kernel base or GSP firmware handling is completely blocking the initialization (RmInitAdapter failed) for the new Blackwell Device ID (2d30).

Is there an updated .raw system extension planned that fully supports Blackwell firmware initialization, or is this a limitation of the immutable base of ZimaOS 1.6.1 itself?

4

Hi mate, thanks for posting the full output.

This changes the diagnosis a lot. Your result shows it is not a userspace/kernel version mismatch.

You have:

NVRM version: NVIDIA UNIX x86_64 Kernel Module 580.105.08

and:

NVIDIA-SMI version  : 580.105.08DRIVER version      : 580.105.08

So both sides match.

The key error is here:

NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:2d30)NVRM: installed in this system requires use of the NVIDIA open kernel modules.NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x22:0x56:884)NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

That means the card is visible, the driver version matches, and the device nodes exist, but the NVIDIA driver is failing during GPU initialisation.

So I would not keep chasing nvidia-smi or container toolkit yet. The issue is happening before Docker/Ollama gets involved.

The next thing to confirm is whether ZimaOS has actually loaded the open NVIDIA kernel module path, not just the normal/proprietary nvidia module.

Can you please post:

modinfo nvidia | grep -iE "filename|version|license"

cat /sys/module/nvidia/parameters/NVreg_OpenRmEnableUnsupportedGpus 2>/dev/null || echo "parameter not found"

ls -l /lib/firmware/nvidia 2>/dev/null || ls -l /usr/lib/firmware/nvidia 2>/dev/null || echo "nvidia firmware path not found"

dmesg | grep -iE "NVRM|GSP|firmware|RmInitAdapter|open kernel"

At this point, this looks like an IceWhale/Jerry-level extension issue rather than a normal user configuration problem.

The main question is:

Does the current ZimaOS 1.6.1 NVIDIA .raw extension actually provide the full open kernel module + GSP firmware path needed by RTX PRO 2000 Blackwell / PCI ID 10de:2d30, or is it still loading the proprietary NVIDIA module path even though the version is 580.105.08?

Your logs are good because they narrow it down properly. It is not PCIe detection, not nvidia-smi version mismatch, and not Docker. It is failing at NVIDIA driver initialisation.

1 Like
5

Hi, here are the outputs from the commands you requested. Your suspicion was spot on!

1. Module License Check (It is the Open module):

Bash

~ ➜ modinfo nvidia | grep -iE "filename|version|license"
filename:       /lib/modules/6.12.25/updates/nvidia.ko
version:        580.105.08
license:        Dual MIT/GPL
srcversion:     E428CF693F50B6FFC6527A3

The module itself is indeed the Open-Kernel version.

2. Module Parameter Check (Failed to apply):

Bash

~ ➜ cat /sys/module/nvidia/parameters/NVreg_OpenRmEnableUnsupportedGpus 2>/dev/null || echo "parameter not found"
parameter not found

It seems ZimaOS completely ignores custom configuration files in /etc/modprobe.d/ due to its immutable/read-only nature, so the parameter to force-enable unsupported/new GPUs never reaches the driver.

3. Firmware Path Check:

Bash

~ ➜ ls -l /lib/firmware/nvidia 2>/dev/null || ls -l /usr/lib/firmware/nvidia 2>/dev/null || echo "nvidia firmware path not found"
total 0
drwxrwxr-x 1 1000 samba 57 Nov 10  2025 580.105.08

The firmware directory exists, but it’s nested inside a version subfolder (580.105.08). The open kernel module might be failing to locate the GSP firmware because it expects it directly in /lib/firmware/nvidia/ or via a specific symlink that ZimaOS’s extension architecture doesn’t map correctly.

4. The Detailed dmesg Log:

Bash

~ ➜ dmesg | grep -iE "NVRM|GSP|firmware|RmInitAdapter|open kernel"
[    4.165945] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  580.105.08  Wed Oct 29 23:15:11 UTC 2025
[    6.622406] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:2d30)
               NVRM: installed in this system requires use of the NVIDIA open kernel modules.
[    6.622422] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x22:0x56:884)
[    6.622942] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

(The initialization loop repeats constantly during boot).

Conclusion: You are completely right—this is a packaging/extension issue on the OS level. The open module is loading, but without the NVreg_OpenRmEnableUnsupportedGpus parameter being accepted and with potential firmware path mapping issues under ZimaOS, the Blackwell card (RTX PRO 2000) just refuses to initialize.

Hopefully, Jerry or the IceWhale team can look into how parameters and firmware paths are handled in the .raw system extensions for ZimaOS 1.6.1 to fully unlock Blackwell support!

6

Thanks mate, that is a really helpful set of outputs.

The good news is we can now rule out a few things. It does not look like a normal nvidia-smi version mismatch, and it does not look like the old proprietary module is being loaded either.

This line is important:

license:        Dual MIT/GPL

That confirms the open NVIDIA kernel module is loaded.

I would just be careful saying ZimaOS is definitely ignoring /etc/modprobe.d, because parameter not found may simply mean this driver build does not expose that parameter under /sys/module/nvidia/parameters/.

Same with the firmware folder. NVIDIA firmware being inside a versioned folder like this may be normal:

/lib/firmware/nvidia/580.105.08

So I would not call the firmware path broken unless the kernel log shows a missing firmware or GSP file error.

What we can say for sure is:

PCI ID: 10de:2d30NVIDIA open module: 580.105.08NVIDIA userspace: 580.105.08device nodes: createdfailure point: RmInitAdapter failed

So I think this is now past normal Docker, Ollama, or user configuration troubleshooting. The card is detected, the open module is loaded, and the versions match, but the driver still fails when trying to initialise the Blackwell GPU.

This part is the key:

NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x22:0x56:884)NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

At this point I think Jerry or IceWhale need to confirm whether the current ZimaOS 1.6.1 NVIDIA .raw extension fully supports the RTX PRO 2000 Blackwell / PCI ID 10de:2d30, including the open-module firmware/GSP side.

I would not recommend more random changes on your side for now. Your logs are clear enough and should give IceWhale something solid to investigate.

1 Like
7

Hi mate,

Thank you so much for the detailed breakdown and for correcting my assumptions about the parameters and firmware paths. That makes total sense!

I will follow your advice and stop tweaking the system for now. As you said, the logs clearly show that everything on the configuration side is correctly set up, and the issue is strictly down to how the driver initializes the Blackwell GPU (10de:2d30) on this specific ZimaOS extension.

I’ll leave this thread here as a solid reference for Jerry and the IceWhale team. Hopefully, they can check if a future update or a patch to the .raw extension can fully bring the RTX PRO 2000 Blackwell to life.

Thanks again for your awesome support!

1 Like
8

The situation looks weird due to two reasons:

  1. According to this link Appendix A. Supported NVIDIA GPU Products this driver (installed in the ZimaOS system) supports RTX PRO 2000 Blackwell with the following PCI IDs including yours:
    NVIDIA RTX PRO 2000 Blackwell 2D30 1028 2054 K
    NVIDIA RTX PRO 2000 Blackwell 2D30 103C 2054 K
    NVIDIA RTX PRO 2000 Blackwell 2D30 10DE 2054 K
    NVIDIA RTX PRO 2000 Blackwell 2D30 17AA 2054 K
    Blackwell is not smth brand new!
  2. New ZimaCube 2 Creator pack comes with the same Nvidia card so it’s supposed to be supported and tested within the system.
9

Yes, I see why you said that. The current ZimaCube 2 Creator Pack listing does say RTX Pro 2000, so in theory this should be a supported and tested path.

The only thing I would still like IceWhale/Jerry to confirm is the exact PCI ID of the GPU used in their tested Creator Pack units, because some older Zima material refers to RTX 2000 Ada / A2000, while this user’s card is RTX PRO 2000 Blackwell with PCI ID 10de:2d30.

So I agree, this should not be treated as random unsupported hardware. It needs confirmation from IceWhale whether this exact Blackwell card and PCI ID have been tested with the current ZimaOS 1.6.1 NVIDIA .raw extension.

10

Thank you both for this discussion. You both make great points.

The fact that the driver officially lists the 2D30 ID means the software support from NVIDIA is there. However, as pointed out, the naming convention between the RTX 2000 Ada and the new RTX PRO 2000 Blackwell can be confusing, and the underlying architecture (especially regarding GSP firmware) is completely different.

Since my system consistently fails at RmInitAdapter failed using the manual .raw extension on ZimaOS 1.6.1, we definitely need IceWhale’s input here.

To help Jerry and the team, here is the exact summary of my hardware and the error state again:

  • GPU: NVIDIA RTX PRO 2000 Blackwell

  • PCI ID: 10de:2d30

  • ZimaOS: 1.6.1 with Nvidia .raw extension (Driver/Userspace matched at 580.105.08)

  • Failure: Open kernel module loads, but initialization fails during boot (RmInitAdapter failed! (0x22:0x56:884)).

@Jerry — Could you please confirm if this exact Blackwell PCI ID (10de:2d30) is fully validated within the current 1.6.1 extension, or if the factory Creator Pack uses a different revision/architecture?

1 Like
11

Just for the information - what is your Nvidia card vendor? Is that PNY? If yes, than this is the most generic card ever and should be supported the same way as the one produced by Nvidia (BTW I have no idea if Nvidia still produces some of their cards)

I can hardly imagine RTX PRO 2000 is not recognized. Though ZimaOS is not generic Linux - it’s appliance-like OS based on buildroot, so magic happens…

12

Yes, it is indeed a PNY card. The exact model is the PNY RTX PRO 2000 Blackwell 16GB (VCNRTXPRO2000-SB).

Since PNY is the primary partner for NVIDIA’s professional workstation lineup, this card is as close to the official reference design as it gets. There shouldn’t be any weird vendor-specific VBIOS tweaks causing this.

And you hit the nail on the head regarding ZimaOS. The way the kernel, the .raw system extension, and the GSP firmware interact is tightly orchestrated, and if one piece of the puzzle isn’t perfectly aligned for the Blackwell architecture, the driver simply chokes during initialization.

The hardware is as standard as it gets—now we just need the ZimaOS “magic” to catch up with it!

13

Hi everyone,

Could the @ZimaOS-Team comment on when the official NVIDIA extension (.raw overlay) will be updated to support the Blackwell architecture?

Is there an updated .raw file currently in development, or perhaps a beta channel we could opt into for testing?

Also, is anyone else in the community trying to run a Blackwell-generation card on ZimaOS? If you have found any temporary workarounds to get the kernel modules to load, please let me know!

Thanks!