System reboots instead of suspending on Nvidia desktop due to fw-fanctrl-suspend script failure

[Xerdunits]

Describe the bug

When attempting to suspend the system (either through the desktop environment menu or systemctl suspend), the system does not enter sleep mode. Instead, it appears to initiate the suspend process but then immediately reboots. This issue occurs on a standard desktop PC running the latest Bazzite Nvidia image.

What did you expect to happen?

The system should successfully enter the suspend (S3 sleep) state.

Session Logs

Nov 03 18:16:52 bazzite systemd[1]: nvidia-suspend.service: Consumed 1.420s CPU time, 2.2G memory peak.
Nov 03 18:16:52 bazzite systemd[1]: Starting systemd-suspend.service - System Suspend...
Nov 03 18:16:52 bazzite systemd[1]: user@1000.service: Unit now frozen-by-parent.
Nov 03 18:16:52 bazzite systemd[1]: session-2.scope: Unit now frozen-by-parent.
Nov 03 18:16:52 bazzite systemd[1]: user.slice: Unit now frozen.
Nov 03 18:16:52 bazzite systemd[1]: user-0.slice: Unit now frozen-by-parent.
Nov 03 18:16:52 bazzite systemd[1]: user@0.service: Unit now frozen-by-parent.
Nov 03 18:16:52 bazzite systemd[1]: user-1000.slice: Unit now frozen-by-parent.
Nov 03 18:16:52 bazzite systemd-sleep[12141]: Successfully froze unit 'user.slice'.
Nov 03 18:16:52 bazzite systemd-sleep[12145]: [Error] > An error occurred: [Errno 2] No such file or directory
Nov 03 18:16:52 bazzite (sd-exec-strv)[12142]: /usr/lib/systemd/system-sleep/fw-fanctrl-suspend failed with ex>
Nov 03 18:16:52 bazzite systemd-sleep[12141]: Performing sleep operation 'suspend'...
Nov 03 18:16:52 bazzite kernel: PM: suspend entry (deep)
Nov 03 18:16:52 bazzite kernel: Filesystems sync: 0.035 seconds
Nov 03 18:16:53 bazzite kernel: Freezing user space processes
Nov 03 18:16:53 bazzite kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Nov 03 18:16:53 bazzite kernel: OOM killer disabled.
Nov 03 18:16:53 bazzite kernel: Freezing remaining freezable tasks
Nov 03 18:16:53 bazzite kernel: Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
Nov 03 18:16:53 bazzite kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 03 18:16:53 bazzite kernel: sd 3:0:0:0: [sdb] Synchronizing SCSI cache
Nov 03 18:16:53 bazzite kernel: sd 2:0:0:0: [sda] Synchronizing SCSI cache
Nov 03 18:16:53 bazzite kernel: PM: Some devices failed to suspend, or early wake event detected
Nov 03 18:16:53 bazzite kernel: nvme nvme0: 32/0/0 default/read/poll queues
lines 999-1022/1022 (END)

Hardware

Operating System: Bazzite 43
KDE Plasma Version: 6.5.1
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.7-ba01.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 9950X3D 16-Core Processor
Memory: 96 GiB of RAM (93.9 GiB usable)
Graphics Processor: NVIDIA GeForce RTX 5090
Manufacturer: ASRock
Product Name: X870E Taichi

Extra information or context

The fw-fanctrl-suspend script seems to be designed for specific hardware and fails on desktop systems because it cannot find an expected file or directory. This script failure appears to abort the entire suspend process.

[Xerdunits]

I've just checked the tool's help output (fw-fanctrl --help), and it explicitly states it's for 'Framework's laptop'. Judging by this, the fw-fanctrl.service isn't supposed to be active on non-Framework systems like my desktop PC, right? This seems to be the root cause of the crash during suspend.

usage: fw-fanctrl [-h] [--socket-controller {unix}] [--output-format {NATURAL,JSON}]
                  {run,use,reset,reload,pause,resume,print,set_config} ...

control Framework's laptop fan(s) with a speed curve

positional arguments:
  {run,use,reset,reload,pause,resume,print,set_config}

options:
  -h, --help            show this help message and exit
  --socket-controller, --sc {unix}
                        the socket controller to use for communication between the cli and the service
  --output-format {NATURAL,JSON}
                        the output format to use for the command result

obtain more help about a command or subcommand using `fw-fanctrl <command> [subcommand...] -h/--help`

[Xerdunits]

Just my 2 cents, but I think this script should either be rewritten with the appropriate error handling, or it should be bundled with the corresponding ujust recipe (ujust enable-framework-fan-control)