How is Kalpa handling Nvidia drivers

English Install/Boot/Login
1

Hi all,
I am thinking about starting to use Kalpa. I just read it will soon(ish) get the beta status and knowing openSUSE Tumbleweed for its stability that is good enough for me.
I have used Fedora Kinoite for about a year and then moved to Universal Blue (Ublue) Aurora. Both systems are immutable as well and a great pleasure to work with, where Aurora has the advantage of having the Nvidia driver installed in the system where in Kinoite this is done by rpm-ostree which creates an extra software layer.
Because now the Ublue guys want to change Aurora from a KDE distro into a not completely KDE distro where Discover will be replaced by something they created themselves for the Gnome variants of their distros. Earlier on they have made the Gnome terminal program ptyxis the default terminal, instead of Konsole. This can be changed (you can set Konsole as the default terminal again) but the question is for how much longer?

As said, the Nvidia drivers are part of the immutable system and when there is a new driver by the time a new deployment is released you automatically have it and have it working.
My question now is how will Kalpa do this? Is the driver integrated into the system (like with Aurora) or is it installed using rpm-ostree on an extra layer (like with Kinoite)?
I remember from earlier days when I used Tumbleweed that the driver did not always work with the new kernel, or a new driver would not work with the older kernel. (I still don’t know which of the two it was that caused the problem)
I’ve tried to find info about this on the openSUSE website but haven’t found it. Must be my clumsy way of searching, or maybe there is no info available yet.

Who can give some info about this? Thanks in advance.

2

I literally don’t know, as I don’t have hardware to test on.

I need user feedback, but I can say that the only possible supported method I can see, is using the RPM packaged driver provided for tumbleweed, from the Nvidia repo.

Installation method would most likely be:

sudo zypper addrepo https://download.nvidia.com/opensuse/tumbleweed NVIDIA
sudo transactional-update --continue run zypper ref

That will get the keys imported, and then follow:

https://en.opensuse.org/SDB:NVIDIA_drivers#Aeon,_Kalpa_and_MicroOS

And reboot.

3

@sfalken it should detect the hardware and add the appropriate Nvidia repo service… If on supported hardware the open driver install should also occur…

4

I have no idea how it would be doing that, but I don’t have any hardware to test on, to say that it doesn’t

5

This is not possible, due to licensing issues.

There is no such thing as a “layer” on Kalpa, and it doesn’t use rpm-ostree, at all, ever. Kalpa is not an image-based mechanism, like the Fedora Atomics.

6

I also see this https://en.opensuse.org/SDB:NVIDIA_drivers#Via_terminal_on_Aeon,_Kalpa,_Leap_Micro

Just tried a test install… no desktop(?)

 ./pinxi -Gxxz
Graphics:
  Device-1: NVIDIA TU117GLM [Quadro T400 Mobile] driver: nvidia v: 570.169 arch: Turing ports:
    active: none off: DP-1 empty: DP-2,DP-3 bus-ID: 0000:91:00.0 chip-ID: 10de:1fb2
  Display: unspecified server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.8 driver:
    gpu: nvidia,nvidia-nvswitch tty: 169x29
  Monitor-1: DP-1 model: Dell P2018H res: 1600x900 dpi: 94 diag: 494mm (19.4")
  API: EGL v: 1.5 platforms: device: 1 drv: swrast surfaceless: drv: swrast
    inactive: gbm,wayland,x11,device-0
  API: OpenGL v: 4.5 vendor: mesa v: 25.1.5 note: console (EGL sourced) renderer: llvmpipe
    (LLVM 20.1.7 256 bits)
  API: Vulkan v: 1.4.313 surfaces: N/A device: 0 type: cpu driver: mesa llvmpipe
    device-ID: 10005:0000
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor
    gpu: nvidia-smi wl: wayland-info x11: xdpyinfo,xprop

I added;

localhost:~ # pbl --add-option nvidia_drm.modeset=1
localhost:~ # sdbootutil -v add-all-kernels

Rebooted, but sddm not running…

localhost:~ # systemctl status sddm.service 
â—‹ sddm.service - Simple Desktop Display Manager
     Loaded: loaded (/usr/lib/systemd/system/sddm.service; disabled; preset: disabled)
     Active: inactive (dead)
       Docs: man:sddm(1)
             man:sddm.conf(5)
localhost:~ # systemctl start sddm.service 
localhost:~ # systemctl status sddm.service 
â—Ź sddm.service - Simple Desktop Display Manager
     Loaded: loaded (/usr/lib/systemd/system/sddm.service; disabled; preset: disabled)
     Active: active (running) since Sun 2025-07-13 18:03:56 UTC; 1s ago
 Invocation: d64897621aad4bdc823762255ebbecfb
       Docs: man:sddm(1)
             man:sddm.conf(5)
   Main PID: 1832 (sddm)
      Tasks: 2 (limit: 37716)
        CPU: 74ms
     CGroup: /system.slice/sddm.service
             └─1832 /usr/bin/sddm

Jul 13 18:03:56 localhost.localdomain sddm[1832]: Socket server starting...
Jul 13 18:03:56 localhost.localdomain sddm[1832]: Socket server started.
Jul 13 18:03:56 localhost.localdomain sddm[1832]: Loading theme configuration from "/usr/share/sddm/themes/breeze-openSUSE/theme.conf"
Jul 13 18:03:56 localhost.localdomain sddm[1832]: Greeter starting...
Jul 13 18:03:56 localhost.localdomain sddm-helper[1834]: [PAM] Starting...
Jul 13 18:03:56 localhost.localdomain sddm-helper[1834]: [PAM] Authenticating...
Jul 13 18:03:56 localhost.localdomain sddm-helper[1834]: [PAM] returning.
Jul 13 18:03:56 localhost.localdomain sddm-helper[1834]: pam_unix(sddm-greeter:session): session opened for user sddm(uid=469) by sddm(uid=0)
Jul 13 18:03:56 localhost.localdomain sddm[1832]: Greeter session started successfully
Jul 13 18:03:58 localhost.localdomain sddm[1832]: Message received from greeter: Connect

Screenshot_20250713_180600
Screenshot_20250713_1806001599Ă—899 289 KB

System:
  Kernel: 6.15.5-1-default arch: x86_64 bits: 64 compiler: gcc v: 15.1.1
    clocksource: tsc avail: hpet,acpi_pm
    parameters: initrd=\opensuse-microos\6.15.5-1-default\initrd-077ee0d6a1b4f14b18002794c1551bd9c84e56e7
    root=UUID=387a66fb-8173-4d6a-9f53-d543a9bf2385 splash=silent
    swapaccount=1 systemd.show_status=1 mitigations=auto quiet
    security=selinux selinux=1 rd.driver.blacklist=nouveau
    nvidia_drm.modeset=1 rootflags=subvol=@/.snapshots/6/snapshot
    systemd.machine_id=e122b2e647d67910c2db395a6873eb0b
  Desktop: KDE Plasma v: 6.4.2 tk: Qt v: N/A info: frameworks v: 6.15.0
    wm: kwin_wayland vt: 2 dm: SDDM Distro: openSUSE MicroOS
Graphics:
  Device-1: NVIDIA TU117GLM [Quadro T400 Mobile] driver: nvidia v: 570.169
    alternate: nouveau,nvidia_drm non-free: 550-570.xx+ status: current (as of
    2025-05; EOL~2026-12-xx) arch: Turing code: TUxxx process: TSMC 12nm FF
    built: 2018-2022 ports: active: none off: DP-1 empty: DP-2,DP-3
    bus-ID: 0000:91:00.0 chip-ID: 10de:1fb2 class-ID: 0300
  Display: wayland server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.8
    compositor: kwin_wayland driver: gpu: nvidia,nvidia-nvswitch display-ID: 0
  Monitor-1: DP-1 model: Dell P2018H serial: <filter> built: 2018 res:
    mode: 1600x900 hz: 60 scale: 100% (1) dpi: 94 gamma: 1.2
    size: 434x236mm (17.09x9.29") diag: 494mm (19.4") ratio: 16:9 modes:
    max: 1600x900 min: 640x480
  API: EGL v: 1.5 hw: drv: nvidia platforms: device: 0 drv: nvidia device: 2
    drv: swrast gbm: drv: nvidia surfaceless: drv: nvidia wayland: drv: nvidia
    x11: drv: nvidia inactive: device-1
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 570.169
    glx-v: 1.4 direct-render: yes renderer: NVIDIA T400/PCIe/SSE2
    memory: 1.95 GiB display-ID: :0.0
  API: Vulkan v: 1.4.313 layers: 2 device: 0 type: discrete-gpu
    name: NVIDIA T400 driver: nvidia v: 570.169 device-ID: 10de:1fb2
    surfaces: N/A device: 1 type: cpu name: llvmpipe (LLVM 20.1.7 256 bits)
    driver: mesa llvmpipe v: 25.1.5 (LLVM 20.1.7) device-ID: 10005:0000
    surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: nvidia-smi wl: wayland-info
    x11: xdpyinfo,xprop
7

yeah, at present, you need to run systemctl enable --now --force sddm.service to get it working, as it currently conflicts with display-manager-legacy.service there’s a fix on the way

8

The first 3 weeks I can not help you with that because I am on holiday now and I would like to keep my laptop running. After that I can see if I can install Kalpa and try to install the Nvidia driver.

So it means when I install the driver it will be part of the main system, just like in Tumbleweed, and it will be updated through transactional updates, This means, as is the case in Fedora atomics, there will not be a fall back deployment should something go wrong with an update. Will there be any safety mechanism just in case?

That would be perfect, but will take some time I guess.

Thank you both for your answers.

9

Rollback to the prior snapshot. If something goes wrong in an update, the snapshot is discarded and the last known working snapshot will continue to run. Updates never touch your running system.

1 Like
10

If NVIDIA repository is configured, it should be as simple as

zypper install-new-recommends

The problem is, it will install all recommended packages. As MicroOS disables them by default, it will probably be too much.

And NVIDIA drivers depend on the packages from the main repository which are not normally present. So, restricting repository to the NVIDIA will not be possible either.

11

As the transactional systems (Kalpa, Aeon, MicroOS) don’t use zypper directly for installation/update and so on, the above zypper command won’t work on these system. ( Yes transactional-update uses zypper “under the hood”, but that is OT here.)

That is why the Nvidia SDB explains the different commands for the different distribution flavors.

1 Like
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.