Thanks for tackling this problem! Apparently, I just experienced the same issue (though I did not measure the time it took for the re-login to be prompted) and now seems to be fixed.
In my case this began with an update including this changes. After rebooting and checking everything was in order, I erased my snapper-snapshots and performed a balance (following this guidelines as I usually do before creating a manual snapshot). Everything seemed to go smoothly and I shutdown the system, just to come later to a disaster:
The bootloader (grub) was fine, but the system would not load with either zen or lts kernels.
I had to garuda-chroot into the system to fix it (along the lines )ā¦ apparently my system partition got messed up so that its superblock was not being found. I tried some suggestions from this post of and this post: in my case btrfs check /dev/nvme... gave no errors, and the scrub+balance+defrag and reinstall of all my kernels did not solve it.
By following this steps I was able to log into the systemā¦ just to find the problem this post addresses.
Regarding this: I followed your suggested steps, but did not add the zram entry to fstab. Instead, I added the suggested vm.stuff configuration from the arch wiki and rebooted to a working system. I think the problem was the missing .confā¦ but how did that happen?
I have a similar user profile as yours: not much of a tweaker when it comes to system configuration and trust most of it to Garuda devs. Would love to know about how all this came to beā¦ but currently I have no time to look into. So thanks again!
Thatās more of a side note.
You solved it yourself, but I donāt think the cause of its behavior in your case was identified and your solution seems to me like a workaround.
Iām not sure, but I think the entry in fstab searches /etc/systemd/zram-generator.conf. Garuda seems to do something different than the Arch Linux standard.
Under Garuda, zram-generator.conf is located in /usr/lib/systemd, not in /etc/systemd. There is also no entry in fstab by default. Nevertheless, the service runs, and zram works as desired.
āāāā¼ systemctl status systemd-zram-setup@zram0.service
ā systemd-zram-setup@zram0.service - Create swap on /dev/zram0
Loaded: loaded (/usr/lib/systemd/system/systemd-zram-setup@.service; static)
Drop-In: /run/systemd/generator/systemd-zram-setup@zram0.service.d
āābindings.conf
Active: active (exited) since Thu 2025-07-31 08:22:46 CEST; 22min ago
Invocation: 0b34bfdf2b844f90bd3898f09de6e758
Docs: man:zram-generator(8)
man:zram-generator.conf(5)
Process: 752 ExecStart=/usr/lib/systemd/system-generators/zram-generator --setup-device zram0 (code=exited>
Main PID: 752 (code=exited, status=0/SUCCESS)
Mem peak: 3.2M
CPU: 27ms
Now that itās running, it doesnāt matter. I just wanted to mention it because I find it strange that the Garuda standard was broken on your system. For whatever reason.
Of course ā wrong location and default this file does not exist in /etc/systemd/
Sorry, this is not the intended location for this file.
Default you donāt need the file in /etc/systemd/zram-generator.conf only if you change the settings.
Thatās rightā¦ just confirmed garudaās zram-generator configuration file is found at /usr/lib/systemd/ (owned by garuda-common-settings) in my system.
Sadly, I booted today to find this problem again . The strange thing is that after chrooting just to look for the configuration file and rebooting, everything seems to be fine. Something quirky is going onā¦
For other people that come across this: As my zram seems to be working appropiately, the culprit might be the compositor as @shayaknyc suggested and I suspect it is triggered by the screen turning off by KDEās power management (but wonāt be testing it now as I have urgent work to get done). Iām making a full upgrade again and check/remove orphaned packages; if I find this behavior again, Iām thinking of doing a garuda-update remote fullfix.
If the thing persist, Iāll open a new thread as @OopsAllProblems is fixed already.
Sorry, i mean no
Take a look in the journal whatās going on with zram. If you read āerrorsā
Reinstall zram ā reboot. To be safe: If you not find the log entry for zram, your swap file is not created during boot. Control the service and settings for zram.
systemctl status systemd-zram-setup@zram0.service cat /sys/block/zram0/disksize cat /sys/block/zram0/comp_algorithm zramctl
Thanks for the notes, but as I said, my zram seems to be working appropriately: configuration in place, systemctl ... reports OK, no erros in journalctl for swap or zramā¦
The problem specified in this thread has not appeared again so far (it just went away). What I do have is some inconsistent graphic glitches (they come and go), for example: my webcam (external) is currently not functioning (either on wayland and x11), after login sometimes a random colored pixel screen blinks for a second (other times is the same log message I saw just before my last shutdown), sometimes have system lags, and other time the compositor is not reloading after coming back from a tty or from sleepā¦
Iāll just keep doing house-keeping and do some research later onā¦ create a post if things get nastier.
. The strange thing is that after chrooting just to look for the configuration file and rebooting, everything seems to be fine. Something quirky is going onā¦