It will after you update to linux614-nvidia-open 570.144-9. 
EDIT: Corrected pkgrel
update ok for
Maxwell - RTX 970 - closed source 570.144 ( nvidia-utils & setting 570.144-3 , nvidia-driver-assistant 0.21.51.03-1)
- linux 6.14.5-1 headers 6.14.5-1 linux-nvidia 570.144-9 boot ok
- linux 6.12. headers 6.12 linux-nvidia 570.144-5 boot ok
- linux 6.6 headers 6.6 linux-nvidia-570.144-4 boot ok
It didn’t work for me either Wednesday night, so I installed nvidia-open-dkms which worked. I think I’m going to keep using it rather than switch back and potentially having this issue again.
There was a delay with compiled modules due to GCC 15 changes.
Don’t forget, this is the “unstable” branch. While most of the time there is no actual instability, there could be delays with compiled kernel modules and such.
2 Likes
Oh I know, been here for many years. If using the dkms reduces the risk of an interruption then that’s the option I’ll take.
Does the 6.14 kernel work for you?
After booting I have the following messages
Mai 03 00:15:45 kernel: list_add double add: new=ffffffffc1f76460, prev=ffffffffb7ff9f60, next=ffffffffc1f76460.
Mai 03 00:15:45 kernel: WARNING: CPU: 0 PID: 636 at lib/list_debug.c:35 __list_add_valid_or_report+0xaf/0xc0
Mai 03 00:15:45 kernel: Modules linked in: asus_nb_wmi(+) snd_hda_codec_hdmi(+) asus_armoury irqbypass snd_compress ac97_bus polyval_clmulni snd_pcm_dmaengine polyval_generic snd_usb_audio(+) snd_hda_intel ghash_clmulni_intel sha512_ssse3 snd_intel_dspcfg sha256_ssse3 snd_usbmidi_lib btusb snd_intel_sdw_acpi sha1_ssse3 btrtl snd_ump eeepc_wmi(+) firmware_attributes_class aesni_intel snd_hda_codec btintel asus_wmi btbcm snd_rawmidi crypto_simd platform_profile iTCO_wdt snd_hda_core btmtk hid_generic(+) i8042 cryptd snd_seq_device snd_hwdep sparse_keymap rapl intel_pmc_bxt bluetooth mc usbhid igc(+) cdc_acm tps6598x snd_pcm mei_hdcp spd5118 mei_pxp iTCO_vendor_support intel_cstate serio nvidia_uvm(OE+) rfkill snd_timer wmi_bmof spi_nor i2c_i801 thunderbolt intel_uncore ptp mei_me mtd snd i2c_smbus ucsi_acpi intel_lpss_pci pps_core i2c_mux pcspkr typec_ucsi mei soundcore intel_lpss idma64 typec intel_pmc_core roles serial_multi_instantiate pmt_telemetry pmt_class acpi_tad pinctrl_alderlake acpi_pad intel_vsec mac_hid nvidia_drm(OE+)
Mai 03 00:15:45 kernel: nvidia_modeset(OE) drm_ttm_helper ttm video wmi nvidia(OE) i2c_dev crypto_user dm_mod loop nfnetlink ip_tables x_tables nvme spi_intel_pci nvme_core spi_intel nvme_auth
Mai 03 00:15:45 kernel: CPU: 0 UID: 0 PID: 636 Comm: (udev-worker) Tainted: G OE 6.14.5-1-MANJARO #1 78703eb07504bd80ad10bf407b5a47e51d2e07d2
Mai 03 00:15:45 kernel: Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Mai 03 00:15:45 kernel: Hardware name: ASUS System Product Name/ROG MAXIMUS Z790 HERO, BIOS 2801 11/29/2024
or is it because of my PC
For who? For me? Yes.
Does it work for you?
…are not the full log. It’s hard to help.
I suggest creating a new Support or Deutsch (if you prefer) topic for further troubleshooting.
After many tests, I am pretty sure that my CPU is defective. If I throttle the CPU very low the kernel works.
check the temperatures. probably time to renew the thermal-paste and clean the dust.
yes, kernel 6.14 has a lot of payload to the cpu.
Yes, it is.
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +38.0°C (high = +80.0°C, crit = +100.0°C)
Core 0: +32.0°C (high = +80.0°C, crit = +100.0°C)
Core 4: +38.0°C (high = +80.0°C, crit = +100.0°C)
Core 8: +31.0°C (high = +80.0°C, crit = +100.0°C)
Core 12: +32.0°C (high = +80.0°C, crit = +100.0°C)
Core 16: +32.0°C (high = +80.0°C, crit = +100.0°C)
Core 20: +31.0°C (high = +80.0°C, crit = +100.0°C)
Core 24: +32.0°C (high = +80.0°C, crit = +100.0°C)
Core 28: +30.0°C (high = +80.0°C, crit = +100.0°C)
Core 32: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 33: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 34: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 35: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 36: +35.0°C (high = +80.0°C, crit = +100.0°C)
Core 37: +35.0°C (high = +80.0°C, crit = +100.0°C)
Core 38: +35.0°C (high = +80.0°C, crit = +100.0°C)
Core 39: +35.0°C (high = +80.0°C, crit = +100.0°C)
Core 40: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 41: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 42: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 43: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 44: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 45: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 46: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 47: +34.0°C (high = +80.0°C, crit = +100.0°C)
That’s not the reason
1 Like
3 posts were split to a new topic: Waiting for GCC 15.1
Just FYI, the pacnews with the filesystem 2025.05.03-1 update can be safely removed–as long as you were already caught up with previous changes.
You can see the changes (that didn’t actually change anything this time) on GitLab as per usual:
My log after updating via topgrade. Notice I viewed the diffs just to double-check, then removed them:
── 18:59:05 - Configuration update ─────────────────────────────────────────────
==> pacnew file found for /etc/hosts
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] v
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] r
removed '/etc/hosts.pacnew'
==> pacnew file found for /etc/passwd
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] v
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] r
removed '/etc/passwd.pacnew'
==> pacnew file found for /etc/shells
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] v
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] r
removed '/etc/shells.pacnew'
5 Likes
I imagined as much. The .pacnew files seemed too bare-bones for my system.
Looking at my command history, I’ve been to this rodeo before 
Since the latest update, i always get the following dialog when my Wireguard VPN tries to autoconnect after startup:
No idea which password Wireguard asks for, it’s not my normal login password.
Anybody experiences the same?
Edit: Actually, when I enter my user password into this box, it overwrites the private key in the Wireguard settings.
Even worse, I cannot change the value of the private key back to what it should be, becuse no matter what field I change, the apply button (“Anwenden” - bottom right) is disabled:
Edit #2: Found a workaround (it survived at least one log out–log in cylce, not sure if it permanentely fixes the problem tho.)
You can edit the private key of your Wireguard connection in the NetworkManager GUI.
When connecting again, the same password dialog appeared again.
Even tho i entered the private key this time, the connection wasn’t established.
I found the following in the journal:
15.05.25 14:15 NetworkManager <warn> [1747311343.6110] device (test): Activation: failed for connection 'test'
15.05.25 14:20 NetworkManager <warn> [1747311631.8890] device (test): wireguard.peers.xxx=.preshared-key: Passwort nicht gefunden ("Password not found")
And indeed, NetworkManager showed an empty field for the preshared key.
I am sure that it must have been present before, because I was using this VPN connection for years already.
It must have been accidentally deleted somehow with the update.
After I entered the correct preshared key again, the connection was finally established.
Your screenshots look like KDE but your profile says you’re using Gnome?
I’m assuming this is on KDE though. There have been quite a few changes to kwallet and friends with the recent Frameworks 6.14 update.
Perhaps saving the password “for all users” instead of just for your user (select just below the password input) works (if it’s acceptable security wise).
Yeah, I am using KDE on my Desktop machine.
The kwallet thing might be the explanation, shouldn’t happen of course.
After I have corrected the settings again, the dialog did not appear again.
IMO it’s just badly designed, because it doesn’t tell you, what kind of password is actually missing (not to speak of the preshared key, which is really deeply hidden in the settings).
For reference: I created a bug report at KDE’s bugtracker, just in case anyone experiences the same: 504358 – Kwallet looses Wireguard private/ preshared keys after update to 6.14
The issue with Kwallet should be fixed with 6.14.0-2.