Sddm no longer loads after gamescope Update

(this is an inxi from the live usb so the kernel and plasma version are not the same as my install, I tried to get an inxi from the chroot but it came back all garbled)

Kernel: 6.5.9-zen2-1-zen arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
clocksource: tsc available: hpet,acpi_pm
parameters: BOOT_IMAGE=/boot/vmlinuz-x86_64 lang=en_US keytable=us tz=UTC
misobasedir=garuda root=miso:LABEL=GARUDA_DR460NIZEDGAMING_RAPTOR quiet
systemd.show_status=1 ibt=off driver=free nouveau.modeset=1
i915.modeset=1 radeon.modeset=1
Desktop: KDE Plasma v: 5.27.9 tk: Qt v: 5.15.11 wm: kwin_x11 vt: 2
dm: SDDM Distro: Garuda Linux base: Arch Linux
Type: Desktop Mobo: ASRock model: X470 Taichi serial: <superuser required>
UEFI: American Megatrends v: P5.10 date: 10/20/2022
Device-1: hidpp_battery_0 model: Logitech Wireless Mouse MX Master 3
serial: <filter> charge: 100% (should be ignored) rechargeable: yes
status: discharging
Info: model: AMD Ryzen 5 5600X bits: 64 type: MT MCP arch: Zen 3+ gen: 4
level: v3 note: check built: 2022 process: TSMC n6 (7nm) family: 0x19 (25)
model-id: 0x21 (33) stepping: 2 microcode: 0xA20120A
Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache:
L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 3 MiB desc: 6x512 KiB
L3: 32 MiB desc: 1x32 MiB
Speed (MHz): avg: 3673 high: 3700 min/max: 2200/4686 boost: enabled
scaling: driver: acpi-cpufreq governor: performance cores: 1: 3700 2: 3577
3: 3700 4: 3700 5: 3700 6: 3700 7: 3700 8: 3599 9: 3700 10: 3600 11: 3700
12: 3700 bogomips: 88803
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Vulnerabilities: <filter>
Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
vendor: Gigabyte driver: amdgpu v: kernel arch: RDNA-2 code: Navi-2x
process: TSMC n7 (7nm) built: 2020-22 pcie: gen: 4 speed: 16 GT/s
lanes: 16 ports: active: DP-1,HDMI-A-2 off: DP-2 empty: HDMI-A-1
bus-ID: 10:00.0 chip-ID: 1002:73df class-ID: 0300
Display: x11 server: X.Org v: 21.1.9 with: Xwayland v: 23.2.2
compositor: kwin_x11 driver: X: loaded: amdgpu unloaded: modesetting,radeon
alternate: fbdev,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
Screen-1: 0 s-res: 4480x1080 s-dpi: 96 s-size: 1184x285mm (46.61x11.22")
s-diag: 1218mm (47.95")
Monitor-1: DP-1 mapped: DisplayPort-0 pos: primary,left
model: LG (GoldStar) HDR WFHD serial: <filter> built: 2021 res: 2560x1080
hz: 60 dpi: 81 gamma: 1.2 size: 798x334mm (31.42x13.15")
diag: 869mm (34.2") modes: max: 2560x1080 min: 640x480
Monitor-2: DP-2 mapped: DisplayPort-1 note: disabled
model: LG (GoldStar) TV SSCR2 serial: <filter> built: 2022 res: 2560x1080
dpi: 61 gamma: 1.2 size: 1600x900mm (62.99x35.43") diag: 1836mm (72.3")
ratio: 16:9 modes: max: 3840x2160 min: 720x400
Monitor-3: HDMI-A-2 mapped: HDMI-A-1 pos: right
model: LG (GoldStar) FULL HD serial: <filter> built: 2023 res: 1920x1080
hz: 75 dpi: 102 gamma: 1.2 size: 480x270mm (18.9x10.63")
diag: 551mm (21.7") ratio: 16:9 modes: max: 1920x1080 min: 720x400
API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
device: 1 drv: swrast surfaceless: drv: radeonsi x11: drv: radeonsi
inactive: gbm,wayland
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 23.2.1-arch1.2
glx-v: 1.4 direct-render: yes renderer: AMD Radeon RX 6700 XT (navi22 LLVM
16.0.6 DRM 3.54 6.5.9-zen2-1-zen) device-ID: 1002:73df memory: 11.72 GiB
unified: no
API: Vulkan v: 1.3.269 layers: 9 device: 0 type: discrete-gpu name: AMD
Radeon RX 6700 XT (RADV NAVI22) driver: mesa radv v: 23.2.1-arch1.2
device-ID: 1002:73df surfaces: xcb,xlib device: 1 type: cpu name: llvmpipe
(LLVM 16.0.6 256 bits) driver: mesa llvmpipe v: 23.2.1-arch1.2 (LLVM
16.0.6) device-ID: 10005:0000 surfaces: xcb,xlib
Device-1: AMD Navi 21/23 HDMI/DP Audio driver: snd_hda_intel v: kernel pcie:
gen: 4 speed: 16 GT/s lanes: 16 bus-ID: 10:00.1 chip-ID: 1002:ab28
class-ID: 0403
Device-2: Sony [] driver: cdc_acm,hid-generic,snd-usb-audio,usbhid
type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 5-2:3
chip-ID: 054c:0e53 class-ID: 0a00
API: ALSA v: k6.5.9-zen2-1-zen status: kernel-api with: aoss
type: oss-emulator tools: N/A
Server-1: PipeWire v: 0.3.83 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Device-1: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi
v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 bus-ID: 08:00.0
chip-ID: 8086:24fb class-ID: 0280
IF: wlp8s0 state: down mac: <filter>
Device-2: Intel I211 Gigabit Network vendor: ASRock driver: igb v: kernel
pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: d000 bus-ID: 0a:00.0
chip-ID: 8086:1539 class-ID: 0200
IF: enp10s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Device-1: Edimax [] driver: btusb v: 0.8 type: USB rev: 1.1 speed: 12 Mb/s
lanes: 1 mode: 1.1 bus-ID: 1-1.4.2:8 chip-ID: 7392:c611 class-ID: e001
serial: <filter>
Report: btmgmt ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 5.1
lmp-v: 10 status: discoverable: no pairing: no class-ID: 7c0104
Local Storage: total: 3.7 TiB used: 755.44 GiB (20.0%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital
model: WD BLACK SN770 1TB size: 931.51 GiB block-size: physical: 512 B
logical: 512 B speed: 63.2 Gb/s lanes: 4 tech: SSD serial: <filter>
fw-rev: 731120WD temp: 36.9 C scheme: GPT
ID-2: /dev/nvme1n1 maj-min: 259:3 vendor: Samsung model: SSD 980 1TB
size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
lanes: 4 tech: SSD serial: <filter> fw-rev: 3B4QFXO7 temp: 35.9 C
scheme: GPT
ID-3: /dev/sda maj-min: 8:0 vendor: Seagate model: ST2000DX002-2DV164
size: 1.82 TiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
tech: HDD rpm: 7200 serial: <filter> fw-rev: CC41 scheme: GPT
ID-4: /dev/sdb maj-min: 8:16 vendor: PNY model: USB 3.1 FD size: 57.77 GiB
block-size: physical: 512 B logical: 512 B type: USB rev: 3.2 spd: 5 Gb/s
lanes: 1 mode: 3.2 gen-1x1 tech: N/A serial: <filter> fw-rev: PMAP
scheme: MBR
SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Message: No partition data found.
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
ID-1: swap-1 type: zram size: 31.26 GiB used: 0 KiB (0.0%) priority: 100
comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 12 dev: /dev/zram0
System Temperatures: cpu: 48.5 C mobo: 26.6 C gpu: amdgpu temp: 40.0 C
mem: 38.0 C
Fan Speeds (rpm): cpu: 1299 fan-3: 1313 fan-4: 1479 fan-5: 1234
gpu: amdgpu fan: 0
Processes: 313 Uptime: 14m wakeups: 2 Memory: total: 32 GiB
available: 31.26 GiB used: 3.6 GiB (11.5%) Init: systemd v: 254
default: graphical tool: systemctl Compilers: gcc: 13.2.1 Packages:
pm: pacman pkgs: 1812 libs: 524 tools: octopi,paru Shell: fish v: 3.6.1
running-in: konsole inxi: 3.3.30
warning: database file for 'garuda' does not exist (use '-Sy' to download)
warning: database file for 'core' does not exist (use '-Sy' to download)
warning: database file for 'extra' does not exist (use '-Sy' to download)
warning: database file for 'community' does not exist (use '-Sy' to download)
warning: database file for 'multilib' does not exist (use '-Sy' to download)
warning: database file for 'chaotic-aur' does not exist (use '-Sy' to download)
Garuda (2.6.17-1):
System install date:     2024-03-13
Last full system update: 2024-03-13 ↻
Is partially upgraded:   No
Relevant software:       snapper NetworkManager dracut
Windows dual boot:       <superuser required>
Failed units:            snapper-cleanup.service

after updating plasma my system no longer boots. It seems to start the kernel and everything fine (as I see the boot up messages) but then the screen goes blank (it usually does with it gets to loading sddm) and just stays there. I can’t switch to a diffrent tty or do anything. at this point I use the REISUB keys to reboot my system.

I to see if I could boot a snapshot but the snapshot menu seems to now be missing under grub.

I tried also chrooting from a live usb but when I went to inspect the systemd jorunal I got this

root@garuda-dr460nized-gaming /# journalctl
No journal files were found.

one intresting thing I noticed is if I disable the sddm systemd unit like this
systemctl disable sddm.service
I can succsesfully boot into a tty after rebooting. manually starting sddm with systemctl enable sddm.service gets me into the same broken blank screen as before so it seems its a problem with sddm

I tried the restore snapshot in the live usb but it refuses to restore my snapshot saying it “failed to make a backup of target subvolume”

Thank you for that, it is THE way to go when you get stuck, as long as the command works.

Which SDDM Theme you had in there before the reboot that caused you blank page?


I believe I had Dr460nized (not sugar candy) Thats what I have right now

I got the snapshot menu back by running the garuda boot repair (just a thought I had lol) and was then able to boot into the snapshot before the update.

Strangely I tried updating again, and it worked this time… Something must of gone wrong on the first update (I was building/ installing gamescope from git to test some issues I was having and that was done after the snapshot I restored to, but that shouldn’t cause problems with sddm…)

So apparently it was gamescope breaking sddm (no idea how) broke my system again trying to install it. Even worse something seems to have happened to my home partition as it is now read only. So while 8 can boot to a previously working snapshot plasma doesn’t work because it complains that my home directory is read only

I’m going to interject here and say the kernel update could have waited. I noticed it during the Plasma updates. IMO kernel updates which Garuda does control should never be done with something like full Plasma system updates.

Garuda Linux does not package, maintain, or otherwise control any kernels. The suggestion that Garuda can hold back a user’s kernel update is incorrect.

Even if it were possible, my guess is the team would be unanimously opposed to holding back kernel updates because this is not Manjaro.


Fixed my read only hoome partition by booting an even older snapshot . I restored that snapshot, rebooted and then updated and now everything is fine … as long as I don’t touch gamescope. Uninstalling my currently installed gamescope package(along with any packages that require gamescope in my case arch-gaming-meta gamescope-session-git gamescope-session-steam-git) brings me back to the broken sddm from the OP. Same if I try to install arch’s gamescope or manually build and install my own.

Somehow gamescope-git is intrinsically tied to sddm and removing it or replacing it breaks it.

this reminds me of Gamescope-git blocking KDE Plasma 6 install, afterwards cannot be installed again and Gamescope-git conflicting files, but not sure if that can explain sddm breaking…

here is my gamescope package

pacman -Qi gamescope-git
Name            : gamescope-git
Version         : 3.14.2.r15.ge48bfc8-1
Description     : gamescope: the micro-compositor formerly known as steamcompmgr
Architecture    : x86_64
URL             :
Licenses        : BSD 2-Clause "Simplified" License
Groups          : None
Provides        : gamescope=3.14.2.r15.ge48bfc8
Depends On      : wayland  opengl-driver  xorg-server-xwayland  pipewire  libdrm  libinput  libavif  libxkbcommon  libxcomposite  libxmu  libcap  libxcb  libpng  glslang  libxrender  libxtst  libxres
                  vulkan-icd-loader  sdl2  xcb-util-renderutil  xcb-util-wm  seatd  benchmark
Optional Deps   : None
Required By     : arch-gaming-meta  gamescope-session-git  gamescope-session-steam-git
Optional For    : an-anime-game-launcher-bin  mangohud  steamtinkerlaunch-git  the-honkers-railway-launcher-bin
Conflicts With  : gamescope
Replaces        : None
Installed Size  : 2.74 MiB
Packager        : UFSCar HPC Builder <[email protected]>
Build Date      : Mon 04 Mar 2024 07:06:35 PM EST
Install Date    : Sun 10 Mar 2024 10:49:48 AM EDT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

It’s Garuda’s OS and you guys do know what’s coming down the pike and do have the ability to block updates til others are done. I stand by what I said that a kernel update should never be done with a desktop update.

Technically we can put them on the ignore list, but honestly controlling kernel updates seems a bit too invasive to me (unless its a kernel version known to ABSOUTELY break systems, which is not the case here). Is there any proof that this actually made a difference here?


Honestly this sound more like some old superstitious belief like “don’t open an umbrella inside” than any kind of practical system administration advice.

For the benefit of those following along in this thread, I will double down as well: holding back random packages just because your system needs to have a lot of updates at once is a bad idea which is more likely to break things and introduce complex obstacles for troubleshooting than just taking the update.

As already stated, you should be reviewing your own packages before updating. If you want to hold back this package or that one because you have a strange update routine then knock yourself out, but please don’t advise other people to do the same.

I don’t think there is a clean way to do this, because:

  • Not all users are running the same kernel. There must be like twenty different kernels our users can choose from, with all the custom ones available in the Chaotic repo and such. Not to mention folks who add their own repos for even more options.
  • Not all users are running KDE. So we would have to either:
    • Hold back twenty kernels or whatever for all users, even the ones that aren’t even updating these packages, or
    • Figure out some way to apply the package hold to only KDE users so everyone else can update normally, and then have a userbase which is all techically “up to date” but are all running completely different kernel versions with different modules and driver stacks, etc.

I think Manjaro is able to do it because they keep their repo on the top in pacman.conf and have a lot more packages in it, like the kernels and such. The Garuda repo doesn’t have any kernels in it, nor any of the KDE packages and so on so we would have to come up with something hacky.

If something were super broken upstream and there were no other choice but to intervene to spare everyone from winding up with a busted system, fine: maybe we should consider the intervention. But holding back the kernel updates because some user anecdotally thinks it will be better to not update this group of packages with that one is insane.


Plasma or gamescope, maybe change the topic title.

1 Like

Nowhere in my post did I advice anyone to do anything. That’s taking my post out of context. I said I don’t believe a kernel update should be done along with major system updates.

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