Tumbleweed Install Issues (Wi-Fi/Plasma/Snapper) - Qualcomm QCA9377

Hi all,

Just wanted to leave some feedback on my recent attempt to install Tumbleweed (DVD/ISO Snapshot 20251127) on my Samsung laptop. Coming from Debian, I really wanted to try TW, but I ran into three showstoppers that forced me to rollback:

  1. Wi-Fi: Couldn’t connect during install or inside Plasma (Qualcomm Atheros QCA9377). It worked fine on an XFCE Live ISO I tested earlier, so I suspect the default Wicked setup on the DVD/ISO installer might be the culprit here.

  2. Graphics: On second boot, Plasma menus wouldn’t render/load properly (Intel UHD 620).

  3. Snapper: I tried to boot a Read-Only snapshot to fix the config, but it crashed to a terminal with a flashing red “Failed” message.

Hardware specs:

  • GPU: Intel UHD 620 [8086:5917] (i915)

  • Wi-Fi: Qualcomm Atheros QCA9377 [168c:0042] (ath10k_pci)

I’ve already wiped the partition and went back to Debian, so I can’t provide journalctl logs right now. However, if this looks like a critical regression and you really need logs to debug, let me know — I can try to reproduce it on a Live ISO or reinstall if necessary.

Thanks.

Hi, welcome

I think so. But I haven’t used wicked for ages.

That should work fine. It’s exactly what I have in my Tuxedo laptop

Hard to tell without logs. If I want to boot into another snapshot, I do that from the system with snapper list and snapper rollback <snapshotnumber>

AFAIK you should be able to choose NetworkManager during install. No idea actually why it picked wicked,

snapper rollback does something entirely different than “booting into another snapshot”. Do not confuse “booting into a snapshot” with “rolling back to this snapshot”.

I know that.

Greetings from Brazil. Thank you for your reply.

I followed your suggestion and tested the KDE Live ISO (Snapshot 20251127) to rule out any “Wicked vs NetworkManager” configuration issues from the DVD installer.

Unfortunately, the terminal outputs below confirm a deeper issue with this Snapshot/Kernel on my hardware (Samsung Laptop, Brazilian market model) .

Here are the results from the Live session:

1. Wi-Fi (Atheros QCA9377)
Confirmed that NetworkManager is active, but the connection hangs on “connecting” indefinitely after entering the password, eventually timing out.

linux@localhost:~> readlink -f /etc/systemd/system/network.service
/usr/lib/systemd/system/NetworkManager.service

linux@localhost:~> nmcli general status
STATE       CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN     METERED
connecting  none          enabled  enabled  missing  enabled  unknown

2. Graphics (Intel UHD 620)
This explains the broken Plasma menus. On Debian, lspci -k shows Kernel driver in use: i915. On this Tumbleweed Live ISO, that line is missing , indicating the driver failed to load.

linux@localhost:~> lspci -k | grep -A 2 VGA
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
        DeviceName:  Onboard IGD
        Subsystem: Samsung Electronics Co Ltd Device c804

Conclusion:

It appears this Snapshot has regressions for both the ath10k_pci (network) and i915 (graphics) drivers on this specific laptop model. Since I cannot get online to fetch updates or fix drivers due to issue #1, and the GUI is compromised due to issue #2, I am unable to proceed with the installation at this moment.

Thanks again for your help.

Update: Comparative Analysis (KDE vs XFCE Live ISO)

Following the discussion, I performed a direct comparison between the KDE Live ISO and the XFCE Live ISO (both Snapshot 20251127) on this hardware.

The results strongly suggest the issue lies within the KDE ISO environment , specifically regarding the graphics stack, which likely cascades into the network timeout issues.

Here are the findings:

1. Kernel Version
Both ISOs are running the exact same kernel, ruling out a kernel regression.

  • 6.17.9-1-default

2. Graphics (Root Cause Candidate)

  • XFCE ISO: lspci -k correctly shows Kernel driver in use: i915. The desktop is responsive.

  • KDE ISO: The line Kernel driver in use: i915 is MISSING .

  • Observation: The KDE environment fails to bind the Intel driver (UHD 620). This forces a software rendering fallback, resulting in significant UI lag and system instability.

3. Wi-Fi (Atheros QCA9377)

  • XFCE ISO: Connects immediately.

  • KDE ISO: Endless loop / Timeout on handshake.

  • Logs: Interestingly, dmesg shows the firmware loads successfully on both environments (showing similar PCIe Bus Errors common to this chipset). However, on KDE, the connection never completes. It is highly probable that the system instability caused by the graphics failure is interfering with the NetworkManager handshake process.

Conclusion:
The hardware is fully compatible with Tumbleweed (as proven by the XFCE session). The problem is specific to the KDE Live ISO (and likely the DVD installer defaults) failing to load the i915 driver on this specific Samsung laptop model (i5-8250u).

Hope this data helps pinpoint the regression in the KDE images. Thanks again for your time and assistance!

Thanks for pointing that out. I am aware of the Live ISO limitations.

However, to clarify:

  1. My initial report (and the reason for this thread) was based on a full installation using the Offline DVD Installer . The Wi-Fi and Graphics issues were identical on the installed system.

  2. I only resorted to the Live ISOs later to gather logs/diagnostics, since the installed system was unusable.

  3. Since the XFCE Live ISO (same snapshot) loaded the drivers and connected to Wi-Fi perfectly, it proves the necessary drivers are present on the media.

The issue seems to be that the KDE environment (likely due to Wayland defaults or specific config) fails to load/bind these existing drivers on this hardware, whereas the XFCE environment handles them correctly.

Detailed Findings: Plasma GUI fails to create NEW connections (CLI workaround works)

Update:

After extensive testing, I have isolated the exact issue. The hardware is fully compatible, but the KDE Plasma GUI is buggy on this snapshot.

Here is the breakdown:

1. Graphics (Intel UHD 620):
lspci -k confirms i915 is loaded and working on the KDE Live ISO. My previous check failed likely due to a temporary glitch or user error.

2. Wi-Fi (Atheros QCA9377) - The Specific Bug:
The issue is purely within the Plasma Network Applet 's ability to establish new connections .

  • Test A (GUI): Click on a new network → Enter Password → Result: Infinite loop / Timeout. Fails to connect.

  • Test B (CLI): Run nmcli dev wifi connect “SSID” password “PASS” → Result: Connects instantly.

  • Test C (GUI after CLI): If I disconnect and click the same network created in Test B via the GUI, it connects perfectly.

  • Test D (New Network via GUI): If I try a different SSID via GUI, it fails again.

Conclusion:
The underlying drivers and NetworkManager are fine. The bug is that the Plasma Applet fails to initiate/handshake NEW connections (possibly a KWallet/Secret interaction issue on this snapshot). The workaround is to use nmcli for the initial connection of any new network; after that, the GUI works for resuming it.

I hope this helps devs fix the applet logic.

Thanks for the help!


This is the user forum. Decelopers don’t read here. If you have a reproducible way to show the issue, you need to create a bugreport.

Thanks for the heads-up regarding the bug reporting process. Since I have already migrated back to Debian (and solved my hardware issues there), I cannot provide the persistent system logs required for a formal Bugzilla report.

However, I want to leave my final findings here for the community record , as I have isolated the root cause. This might help other users with Samsung/Intel UHD 620 laptops facing the same “Wi-Fi timeout” issue on this Snapshot.

The Root Cause: Graphics Driver Failure
I compared openSUSE Tumbleweed vs. KDE Neon User Edition (both running Plasma 6.5.3) on this machine.

  1. KDE Neon: Loads the Intel® UHD Graphics 620 driver correctly. Wi-Fi connects instantly via GUI.

  2. Tumbleweed (Snapshot 20251127): Fails to load the i915 driver and falls back to llvmpipe (Software Rendering) .

The Conclusion:
The system running on llvmpipe creates significant CPU overhead and latency. This system-wide lag causes the Plasma Network Applet / KWallet handshake to time out when creating a new connection.

  • Workaround found: Using nmcli (CLI) bypasses the laggy GUI interaction and connects successfully.

  • Fix needed: The regression seems to be in the Tumbleweed Kernel/Mesa stack for this specific hardware, preventing the Intel driver from loading.

I am marking this thread as closed/solved with this information. Thanks to everyone who helped!

Just a final note for future readers.

I searched the openSUSE Bugzilla and found a report that matches my findings perfectly:
Bug 1248172 - kernel 6.16.1 breaks Intel GLX video acceleration

The report describes a regression starting in Kernel 6.16 where Intel graphics fail to initialize properly, falling back to software rendering (llvmpipe). Since my tests were on Kernel 6.17 and confirmed the llvmpipe fallback (which caused the system lag and consequent network timeouts), this is almost certainly the root cause.

It is a known regression currently marked as In Progress.

The Real Culprit is KWallet behavior (Canceling creation = Infinite Loop)

First, I must apologize for the previous confusion regarding graphics drivers and Kernel regressions. While the llvmpipe fallback is real on this hardware, it was NOT the cause of the network failure.

After extensive testing comparing openSUSE Tumbleweed with other distributions, I have finally isolated the true root cause : It is the KDE Wallet interaction workflow .

The Scenario:

  1. I attempt to connect to a new Wi-Fi network via the GUI.

  2. The system prompts me to create a new KWallet (GPG vs Blowfish).

  3. The Trigger: I click “Cancel” (expecting to connect without setting up a secure wallet at that moment, which works on other distros like Neon/Debian).

The Result:
Instead of falling back to storing the password locally or prompting again, openSUSE enters an infinite loop of “Connecting…” → Timeout .

The Solution/Workaround:
If I go to System Settings → KDE Wallet and uncheck “Enable the KDE wallet subsystem” , the Wi-Fi connects instantly and works perfectly via the GUI.

Conclusion/Feedback for Devs:
The issue is a UX failure. If a user clicks “Cancel” on the Wallet creation wizard, the system should either:
A) Connect using standard NetworkManager storage.
B) Fail with a clear error message (“Password storage required”).

Currently, it silently fails into an infinite loop, leading users to believe it’s a driver/hardware issue.

Problem solved!


You were already told that it is not the right place to provide such feedback. Besides, what you describe is upstream behavior and needs to be handled upstream.

Hello Andrei,

My name is Rafael, and this is my first interaction with the openSUSE community. I’m Brazilian, but the Portuguese forum has been quite empty, so I decided to come here to share my first experience with openSUSE. I believe the community is welcoming to new users, and that this is the best place to make mistakes like this — sorry again!

However, from what I noticed while using other distributions with the same KDE version, the problem I mentioned does not occur there. That’s why it didn’t seem useful to report it in other distro forums, since they wouldn’t be seeing the same issue.

I admit that I was very persistent with this problem, because if I hadn’t found a solution, I wouldn’t be able to start my migration from Debian to openSUSE.I’m a physics simulation programmer and a professor, and I hold both a bachelor’s and a doctorate in physics/science. I mention this in relation to my academic background, because with this profile I value stability and compatibility with scientific .deb packages, so I strongly identify with Debian. Still, I wanted to give openSUSE a chance because I like the idea of having everything in the latest versions without relying on Flatpaks for: Blender, Gimp, Inkscape… and others.

I use VS Code a lot, I program with Babylon.js, and I create simulations for my website, Física Games, in addition to teaching 3D graphics and animation with Blender, which is updated quite frequently.

I hope that, since this is a user-friendly space, I can express myself in a more human and less technical way (as I’m doing now). Thank you for your attention, and I’ll be more careful next time.

Best regards