r/openSUSE

Hello,

About a year ago I migrated from lifelong Windows experience to the Penguin ecosystem. After multiple failed attempts (and possibly my own idiocy) landed of Fedora and... was quite happy about it to be fair. - It was seemingly only Distro that KDE worked well with ootb.

But I am now kind of idea of trying out something else and this time maybe more advanced.

I like arch based distributions, having used Endeavors and Cachy for couple weeks - yet in both cases something broke and I never got to fixing it.

So for the summer I though of a challenge - Instead of endlessly asking AI and blindly copying commands - Learn how my os works, preferably from scratch (or as close to it as practical)

And of course the most advocated system when someone says that is Arch.
YET, I don't know if I am going to spend more time fixing the thing than using it.

Also the more I look into arch, the more I hear about people talking of Tumbleweed, so this is why I am here.

How is your system? What can I expect from going tumbleweed?
Unironically, I don't hear much about this distro in the wild.

I must note, that when installing apps, I of course mostly saw install guides for debian , arch and quite often fedora, but having ready binaries for Tumbleweed are often not present...

Of course many apps I can get from Flathub, but what if that isn't an option? - That is an actual question as I haven't experienced that issue so far.
If there is one thing I can't live without, it must be Davinci Resolve.

So is this even for me?

i am unsure why this is happening, i cannot even login since i set root shell to nologin. i could probably chroot into it and enable root but would that even help? shpuld i just try disabling selinux with a chroot?

i set the grub configuration from apparmor to selinux

Hi everyone!
I’m looking for some advice from the community. I’ve been a long-time Linux user, and over the years, I’ve hopped around a fair bit—I've spent time on Kubuntu, Debian, Linux Mint, Manjaro, and I am currently running Fedora with GNOME.
In about a month, I’ll be moving into a new apartment, and I’m planning to use this fresh start to completely wipe my desktop, get rid of both Fedora and Windows 10, and commit to a single Linux distribution.
Since I won't have a dual-boot setup anymore, gaming performance is quite important to me. For reference, here are my current desktop specs:
* **CPU:** Intel Core i5-6500
* **GPU:** NVIDIA GTX 1060 (6GB)
* **RAM:** 16 GB
* **Storage:** 256GB SSD (dedicated to the OS)
I’ve been heavily eyeing openSUSE Tumbleweed. I really want a rolling release that delivers great performance, but I also need a solid layer of stability. I looked into options like CachyOS, but Tumbleweed seems to strike a much better balance between being cutting-edge and dependable.
On top of that, after spending a lot of time on GNOME recently, I really want to give KDE Plasma another honest chance, and I’ve always heard that openSUSE offers one of the absolute best, most polished KDE experiences in the Linux world.
Given my hardware (especially the older NVIDIA card) and my desire to use it for gaming and daily tasks, do you think Tumbleweed would be a good fit for me? Are there any specific quirks or potential hurdles I should be aware of with this setup?
I’d love to hear your thoughts and experiences. Thanks in advance for your time and help!

I've been on Manjaro for about a year, still had Windows dual-boot for half a year, deleted Windows six months ago. But today is my first real day on Tumbleweed. Second attempt actually, I tried installing it a few weeks ago, something broke, I abandoned it. But today I came back with a purpose.

Here's the context: I want to convert high schools to Linux. Not a joke, a genuine project idea. Which means I need a distro I can actually recommend, one that's stable enough and manageable enough to deploy at scale. And one that has native btrfs snapshotting with bootable snapshots built into the boot menu. Manjaro doesn't have that. Tumbleweed does. CachyOS does too, but after some digging I picked Tumbleweed because it seems suitable for mass deployment/management where CachyOS instead focuses on gamers at home. Not corporate environments. Does it even support FDE? (I'd need to check, so much left to do)

So today I installed it fresh. Full-disk encryption, because in any real corporate environment you need BitLocker equivalent. And I knew that FDE was going to be a potential pain point, the kind of thing that could make someone go "see, this is why Windows still exists." So before I committed to making this my home system, I wanted to test it. Can I actually fix real problems on this distro, or do I hit a wall and get frustrated?

The first real problem was NumLock. At LUKS prompt: off. At SDDM login: off. At KDE: finally on. The LED was flickering through my entire boot sequence. Tiny issue, objectively. But I knew the second I talk to anyone about switching from Windows, someone will use exactly this against me. "Oh, NumLock doesn't work? See, Linux isn't ready." I needed to know if I could fix it before those conversations happened.

What I discovered while fixing it is that NumLock on Linux isn't one setting. It's five separate settings at five separate handoff stages: UEFI, systemd-boot, kernel, dracut/initrd, SDDM, KDE, none of which talk to each other. Each one independently decides whether NumLock is on. The LED physically flickers at every transition. It's a microcosm of what people complain about with Linux: fragmentation. No single authority. Every layer doing its own thing.

The fix required writing a custom dracut module, understanding hook stage ordering, knowing that openSUSE's existing numlock module runs at the wrong stage for FDE users, discovering that SDDM-Wayland has an upstream bug where it silently ignores its own config file, learning that KDE uses a counterintuitive tristate where 0 means "on," and then synthesizing all of that into something that actually works.

I did all of that by pasting terminal output into an LLM and pasting back its suggestions for about two hours. At one point it caught a silent failure I'd missed. At another I corrected it. The collaboration worked.

And here's what hit me: there is no human version of me from five years ago who solves this. Not in two hours. Probably not at all. I'd have hit the fragmentation, seen five different systems each doing NumLock their own way, with no common reference, and given up. And then I'd have concluded "see, this is why Windows exists" and used that as ammunition against the distro.

But I didn't give up, because the LLM could read all the fragments. All the dracut hooks, all the SDDM issues, all the KDE configs, all the kernel docs. It synthesized them. And suddenly the fragmentation wasn't a wall, it was just... complexity that made sense once you saw the whole picture.

That is the actual magic of local LLMs paired with open source. Linux is fragmented by design. Each layer is independent. And that's usually terrible from a user perspective, you have to learn five different systems. But when you pair it with something that can read all five systems at once and help you navigate them, the fragmentation becomes solvable. It stops being a dealbreaker and becomes just "okay, this is how this works."

Which is why the open-source community's gatekeeping against AI tools is so baffling to me. We built a decentralized, fragmented, deliberately-independent stack. And then someone invented a tool that synthesizes across decentralized, fragmented, independent information. And instead of embracing it, we're telling people to "just read the man pages" like we didn't just create a system that requires synthesizing across a hundred man pages.

On Manjaro I never hit this, but I also didn't even check or bother with Bitlocker/FDE. So the fragmentation never showed beyond SDDM clearly operating separate from the rest of KDE. But now that I'm on Tumbleweed evaluating it for something real, I'm seeing why the fragmentation matters, and why LLMs matter, and why they're not enemies, they're made for each other.

I don't know if Tumbleweed is what I'll use for the education thing yet. That's still being decided. But I know now that if a problem comes up, I can fix it. Not because I'm an expert. But because I have access to a tool that can read all the expertise, all the documentation, all the disparate pieces, and help me make sense of them.

That feels like the actual future of Linux adoption. Not "make everything simpler" but "make the tools for navigating complexity better." Because the fragmentation isn't going away. It's a feature, not a bug. And LLMs are finally the tool that makes it one.

And NumLock stays on now, hours work for what's literally not even a second extra work if left as is. But the point wasn't time-efficiency. I saw it as a modern test, can I fix it if I throw all I have at it? And the complexity I encountered during baffled me initially.

I have never been so frustrated with a single led blinking on & off. But finally, I control the led at all stages. And while she goes off during the hand offs, I can now reliably turn her back on at every single stage all the way until I make it into my already beloved & trusted KDE where Linux stops fighting me and supports me all the way.

Thank you for coming to my TED talk :)

I started using Nobara and then due to technical problems I had to migrate to Pop OS.

I have a rather special laptop, an Asus Artbook H5600 that has an AMD iGPU and an RTX GPU (hybrid graphics) with a whole graphics production ecosystem (video, audio and 3d graphics editing):

Artbook 24 screen
Wacom Cintiq 16
Elgato streamdeck
Elgato wave XLR
Elgato facempro 4K
Elgato promise DV

For all these peripherals I work with Wyland, x11 you can’t do it with so many peripherals.

To Pop! _OS has worked well but Cosmic DE is impossible with Wacom. Install Gnome and now that they are going to go to 26lts I probably have update problems so I am considering migrating to another system. I left Nobara because although I detected everything when editing with Davinci Resolve it did not detect the CUDA cores. It sucks that every time I update a new version in POP I have to reinstall everything from scratch. So the AI recommended Tumbleweed to me as a semi rolling release distribution that I can have in the medium term the improvements without suffering problems of a rolling release.

Do you recommend it for my laptop? With Nobara I had a Kernell panic when I tried to save energy from the GPU (pass to a semi-rest) I did not have an option to change from economic to performance without having to restart. (I forgot to restart and it went to corruption).

Before trying anything I would prefer to ask you about compatibility with my laptop.

I thought of Ubuntu Studio or normal Ubuntu but the snaps always takes away one’s desire in the face of so much criticism.

KDE is great for a standalone (home) desktop and really makes for a pleasant and simple environment for new Linux users (or Windows converts) and users who do not want to learn the complexities of a CLI or *.conf file buried somewhere is /etc...

At my company, we recently replaced hundreds of viable desktops with newer machines just because of Microsoft's requirement for TPM 2 for Windows 11 support. I would love to advocate for the re-provisioning of these "older" systems to Linux (OpenSuse. Fedora, etc).

The majority of our users have limited need for thick client Windows apps ( Microsofts' E1 license is adequate) and most could just use Chrome and connect to the corporate web based tools.

Outside of these web based corporate apps, I think the major requirements for a Linux based system to be fully integrated is the use of Print and File services - especially where access is tied to your corporate OU.

Another requirement for my environment was the use of Enterprise WiFi authentication support and our corporate NAC security solutions based on AD an integration.

I would really like to see some form of a KDE admin tool to ease the setup of enterprise AD integration as well as print/file (client) services on Linux. Having admin tools that allow for easy/mass user provisioning/deployment as well as a kiosk or lockdown mode to restrict access to a limited set of features or tools for provisioned users would also be helpful.

Maybe this can be done via a cockpit module since it would give the ability to remotely configure/push settings to the endpoints?

There is a world of opportunity for KDE in the corporate space, unfortunate unless you are willing to setup SSSD and the needed PAM modules, it is locked behind complexity and geekspeak and hence not approachable to most windows admins at the moment.

Has anyone successfully integrated Linux/KDE into an Enterprise Windows environment ?

I'm using the offline image, i made sure to :

• choose the server option
• deselect icewm when it's auto-selected following xorg
• choose the terminal launch/login over the desktop one and yet i find icewm installed once i'm done. I would like to get the basic functional x subsystem and then install i3 on top. Help please

i saw in the Linux_gaming Reddit that cachyos have paclages that you can install but i don't know about openSUSE

**PSA: Kernel 7.0.6 + NVIDIA 580.159.03 (open G06 signed KMP) is unstable on Tumbleweed — at least on RTX 4090. Canary, rollback notes inside.**

Posting in case anyone else is sitting on this `zypper dup` with their finger hovering over the keyboard. I'd hold off, or at minimum treat it as a canary, not a routine update.

**What I ran into**

This morning I took a planned maintenance window to move from `kernel-default 6.19.12-1` to `7.0.6-1` on Tumbleweed. The NVIDIA candidate alongside it was `580.159.03`, and the signed open G06 KMP was built for `k7.0.5_1` (one patch level behind the kernel). Normally that's fine — openSUSE's weak-updates / kABI compatibility is designed for exactly this case, and the module did load cleanly on boot via weak-updates.

The boot itself succeeded. KDE/X11 session came up, `nvidia-smi` worked, `glxinfo` reported `NVIDIA GeForce RTX 4090/PCIe/SSE2` and `4.6.0 NVIDIA 580.159.03` — not llvmpipe, not nouveau. By every static check, it looked green.

Then I checked the journal.

**The actual failure**

From the moment the session started, sustained at roughly one event every few seconds:

```

NVRM: RC watchdog: GPU is probably locked

NVRM: Xid (PCI:0000:01:00): 8, pid=..., name=kwin_x11

NVRM: Xid (PCI:0000:01:00): 8, pid=..., name=Xorg.bin

kwin_x11: A graphics reset attributable to the current GL context occurred

```

This ran continuously for the entire ~6 minutes I left it up. The desktop was technically usable but KWin was clearly fighting the driver the whole time. For a trading workstation that needs to be boring, this was a hard no-go.

**Things I want to be clear about**

- Hardware: i9-14900K / RTX 4090 / dual NVMe Btrfs RAID1. The card is not flaky — it ran 6.19.12 + 580.126.18 cleanly before and after the canary.

- The KMP trailing the kernel by one patch level was **not** the problem. Weak-updates did its job; `modinfo nvidia` confirmed the module loaded and the version matched 580.159.03.

- This was not a packaging/repo incoherence either. Userspace, KMP, common, meta, gl, video, compute — all coherent on the 580.159.03 branch.

- Btrfs was clean. SELinux was Enforcing. Initramfs hygiene was clean. No nouveau, no llvmpipe fallback.

- This was a runtime stability problem in the kernel 7.0.6 / NVIDIA 580.159.03 combination itself, on this hardware, in this driver branch.

**Rollback**

Snapper rollback to the pre-`dup` zypp transaction snapshot, reboot, done. Back on `6.19.12-1-default` + `580.126.18`, zero NVRM/Xid events in the journal, GPU idling at 48°C/33W like normal. The parachute worked exactly as designed — this is genuinely one of the things openSUSE gets right.

I then added relational locks (`>= 7` on kernel-default and `>= 580.159` on the NVIDIA stack) to block the failed combo from coming back on the next `dup` without freezing me on today's exact builds. When a newer NVIDIA branch lands or 7.1+ ships, I'll re-canary.

**Questions for anyone who's been here**

1. Has anyone successfully run kernel 7.0.x with NVIDIA 580.159.03 on Ada-generation cards (4090/4080/4070)? I'm curious whether this is RTX 4090-specific, Ada-wide, or broader.

2. Anyone hit Xid 8 specifically with this combo, or different Xid codes?

3. Anyone tried the proprietary G06 driver path instead of the open signed KMP on kernel 7?

Not a bug report — I haven't filed one yet, want to see if this is a known pattern or a Tungsten-specific thing first. If others confirm, I'll write it up properly.

Moral of the story: even when every static gate is green and the module loads, the runtime can still bite you. Canary your kernel transitions, especially when NVIDIA branches change at the same time. The fact that I could be back on a working system in under ten minutes is the entire reason I trust Tumbleweed for a workstation that has to be available Monday morning.

I can't update my Tumblweed installation since about a month.

The first try broke KDE Plasma. Thought it could be a Nvidia issue, rolled back and tried again a week later.

Then the binutils were broken as well, needed manual fixing. But rebooted in the same issue as before.

Waited for another 2 weeks, both issues from above still exist and it now also breaks the network manager.

What is going on? Are Tumbleweed's updates working for you?

I’m on Tumbleweed and learned that the best way to avoid problems is to uninstall PackageKit and lock it so the system can’t install it again.

After this you will not get system or rpm updates in Discover, no accidental system updates through Discover.

The downside might be that you don’t see any rpm packages in Discover but you can install them with Zypper.

I hope this helps someone else.

Hi guys! I have an older HP laptop with a 3250U and 12gb of 2400mhz ram. I'm kind of debating between tumbleweed and an atomic Fedora distro. I'm newish to Linux but I like exploring and learning about it. It's there any real benefit to using a rolling distro like tumbleweed on an older laptop like that? Thanks!

i have a problem on my Hp laptop with tumbleweed. My headset sound stutters when connected to it. When this happened before i rolled back with snapper but that didn't work. Like, the audio keeps cutting and coming back. How can i solve this? Everything is up to date and it happens with other devices too.

I'm on a Tumbleweed system (about 2 weeks old installation), and I noticed that even some non-codecs packages (such as Mesa driver) was pulled by packman repo, maybe during the post-installation opi codecs process.

ale@tumblele:~$ zypper se -ir packman
Caricamento dati del repository in corso...
Lettura dei pacchetti installati in corso...

S  | Name                            | Summary                                                          | Type
---+---------------------------------+------------------------------------------------------------------+----------
i+ | gstreamer-plugins-bad-codecs    | Codecs/plugins for gstreamer-plugins-bad                         | pacchetto
i+ | gstreamer-plugins-ugly-codecs   | Codecs/plugins for gstreamer-plugins-ugly                        | pacchetto
i  | libde265-0                      | Open H.265 video codec implementation - libraries                | pacchetto
i  | libfaac0                        | Shared library part of faac                                      | pacchetto
i  | libfdk-aac2                     | A standalone library of the Fraunhofer FDK AAC code from Android | pacchetto
i  | libfdk-aac2-32bit               | A standalone library of the Fraunhofer FDK AAC code from Android | pacchetto
i  | libgbm1                         | Generic buffer management API                                    | pacchetto
i  | libgbm1-32bit                   | Generic buffer management API                                    | pacchetto
i  | libopenaptx0                    | An implementation of Audio Processing Technology codec (aptX)    | pacchetto
i  | libquicktime0                   | Library for Reading and Writing Quicktime Movie Files            | pacchetto
i  | librtmp1                        | RTMP Stream Dumper Library                                       | pacchetto
i  | libvlc5                         | Shared code for the VLC media player program                     | pacchetto
i  | libvlccore9                     | Shared code for the VLC media player program                     | pacchetto
i  | libvulkan_intel                 | Mesa vulkan driver for Intel GPU                                 | pacchetto
i  | libvulkan_intel-32bit           | Mesa vulkan driver for Intel GPU                                 | pacchetto
i  | libvulkan_lvp                   | Mesa vulkan driver for LVP                                       | pacchetto
i  | libx264-165                     | A free h264/avc encoder                                          | pacchetto
i  | libx264-165-32bit               | A free h264/avc encoder                                          | pacchetto
i  | libx265-215                     | A free H265/HEVC encoder - encoder binary                        | pacchetto
i  | libx265-215-32bit               | A free H265/HEVC encoder - encoder binary                        | pacchetto
i  | Mesa                            | System for rendering 3-D graphics                                | pacchetto
i  | Mesa-32bit                      | System for rendering 3-D graphics                                | pacchetto
i  | Mesa-dri                        | DRI plug-ins for 3D acceleration                                 | pacchetto
i  | Mesa-dri-32bit                  | DRI plug-ins for 3D acceleration                                 | pacchetto
i  | Mesa-libEGL1                    | EGL API implementation                                           | pacchetto
i  | Mesa-libGL1                     | The GL/GLX runtime of the Mesa 3D graphics library               | pacchetto
i  | Mesa-libGL1-32bit               | The GL/GLX runtime of the Mesa 3D graphics library               | pacchetto
i  | Mesa-libva                      | Mesa VA-API implementation                                       | pacchetto
i  | Mesa-vulkan-device-select       | Vulkan layer to select Vulkan devices provided by Mesa           | pacchetto
i  | Mesa-vulkan-device-select-32bit | Vulkan layer to select Vulkan devices provided by Mesa           | pacchetto
i+ | pipewire-aptx                   | PipeWire Bluetooth aptX codec plugin                             | pacchetto
i  | vlc                             | Graphical media player                                           | pacchetto
i  | vlc-codec-gstreamer             | GStreamer integration for the VLC media player                   | pacchetto
i+ | vlc-codecs                      | Additional codecs for the VLC media player                       | pacchetto
i  | vlc-lang                        | Translations for package vlc                                     | pacchetto
i  | vlc-noX                         | VLC without X dependencies                                       | pacchetto
i  | vlc-qt                          | Qt interface for the VLC media player                            | pacchetto



ale@tumblele:~$ sudo zypper repos -p
#  | Alias                            | Name                                      | Enabled | GPG Check | Refresh | Priority
---+----------------------------------+-------------------------------------------+---------+-----------+---------+---------
1 | dotnet                           | Microsoft .NET                            | Sì      | (r ) Sì   | Sì      |   99
2 | download.opensuse.org-non-oss    | Repository principale (NON-OSS)           | Sì      | (r ) Sì   | Sì      |   99
3 | download.opensuse.org-oss        | Repository principale (OSS)               | Sì      | (r ) Sì   | Sì      |   99
4 | download.opensuse.org-tumbleweed | Repository principale degli aggiornamenti | Sì      | (r ) Sì   | Sì      |   99
5 | packman                          | Packman                                   | Sì      | (r ) Sì   | Sì      |   70
6 | repo-debug                       | openSUSE-Tumbleweed-Debug                 | No      | ----      | ----    |   99
7 | repo-openh264                    | Open H.264 Codec (openSUSE Tumbleweed)    | Sì      | (r ) Sì   | Sì      |   99
8 | repo-source                      | openSUSE-Tumbleweed-Source                | No      | ----      | ----    |   99
9 | unityhub                         | Unity Hub                                 | Sì      | (r ) Sì   | Sì      |   99
10 | vscode                           | vscode                                    | Sì      | (r ) Sì   | Sì      |   99
ale@tumblele:~$

I noticed, also, that the priority of Packman is higher and this explains why other packages have been pulled from it.

As the title says, should I migrate to OSS by lowering packman priority and upgrading distribution with vendor change or should I stick with it?