Tuxedo OS (Ubuntu-based) with KDE/Wayland - waking from Sleep freezes the computer. Help?
Tuxedo OS (Ubuntu-based) with KDE/Wayland - waking from Sleep freezes the computer. Help?
Hi all!
I recently installed Tuxedo OS with KDE and Wayland. I'm fairly new to Linux and, so far, the distro is great. With one caveat.
As far as power options go, everything works fine EXCEPT for Sleep. I can put the PC to sleep, but when I wake it up, I land on the login screen wallpaper with the login/password fields barely visible, as if frozen around the second frame of a fade-in animation.
Nothing works. The mouse cursor doesn't move, the keyboard doesn't do anything. The only way out of this state is to hold the power button until the PC shuts down and then turn it back on again.
I did some digging, but couldn't find a solution. Some threads mentioned modifying something in systemd, but those were from years ago, so I didn't want to risk that.
One fairly recent thread had a proposed solution of adding "mem_sleep_default=deep" to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.
That didn't work for me, though.
I'd love to fix this, but I'm out of ideas. Any help welcome!
EDIT
Forgot it might be a driver issue, people were complaining about Nvidia gear!
I currently don't have a dedicated GPU. I only have Ryzen 7 7800X3D running on MSI B650 Gaming Plus WIFI ATX AM5 MoBo.
Not really related to the issue. If I understand correctly, your device isn't bricked, but freezes. A bricked device doesn't boot anymore, a frozen device is unresponsive. Or am I misunderstanding this?
Came here to say the same thing. Using the term "bricking" in the title had me very confused. It would be catastrophic if this was actually bricking computers.
Yep, not bricked. Just frozen.
There are two forms of bricked:
- hard bricked. This is when a software change (eg, installing a custom firmware) caused the system to fail to boot, and there is no possible way to ever get it to run again.
- soft bricked. Where a software change caused the failure to boot but there is a way (eg, reflashing using UART) to recover back to an older version that does boot.
Both are terms from the Phone modding community (ie, a phone has become as useful as a brick after this update) it's quite hard to actually brick a modern PC.
What's your hardware? And did you regenerate grub's config after editing the file you mentioned?
Sorry, forgot to mention hardware! Added in an edit now!
I have a Ryzen 7 7800X3D and no dedicated GPU (yet).
I ran
sudo update-grubafter making the changes. That and rebooting a bunch of times since.
It might be due to https://github.com/systemd/systemd/issues/33083.
Try disabling user session freezing when sleeping:
sudo systemctl edit systemd-suspend.serviceAdd the following to the file:
[Service] Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"Reload systemd:
sudo systemctl daemon-reloadAfter that, try sleeping and waking again.
I would try:
- see if you can get logs of the resume process
- suspend from a text VT and see if that changes the behaviour
- boot into single user mode and try suspend from there
- boot an older LTS or a newer test kernel and see if it has the same problem
Sorry, mate, I'm a Linux noob.
I have no clue where to find the logs for this.
No idea what a VT is.
Don't know how to boot into single user mode....
Fair enough, most of that isn't something a user should have to worry about.
VT is just Virtual Terminals. You always have one of them active, and in most distros you can switch to others by Ctrl-Alt-F1 through F12. In some distos it's just Alt-F1.
So if you press Ctrl-Alt-F2 you should be brought to a text login. For crazy historical reasons you may have to either press Ctrl-Alt-F1 or Ctrl-Alt-F7 to get back to your usual graphical session.
Arch docs for example: https://wiki.archlinux.org/title/Linux_console
logs are mostly at 2 places.
kernel logs are read with the
dmesgcommand. use the--followparameter if you want it to keep printing new messages.
dmesg does not save logs to disk.broader system logs are read with
journalctl. use-ffor it to keep printing. the journal records kernel messages, but it only shows them when you specifically request it. you can find the param for that inman journalctl.
the journalctl (journald actually) saves logs to disk. but if you don't/can't shut down the system properly, the last few messages will not be there.some system programs log to files in /var/log/, but that's not relevant for now.
if you switch to a VT as the other user described, you should see a terminal prompt on aback background. log in and run
dmesg --follow > some_file, some_file should not be something important that already exists in the current directory. switch to another VT, log in, and runsleep. try to wake up. see if you could have waken up, and if not check the logs you piped to the file, maybe post it here for others to see.also, what did you do after setting the deep sleep kernel param? did you rebuild the grub config, and reboot before trying to sleep with it? that change only gets applied if you do those in that order.
there's an easier way to test different sleep modes temporarily, let me know if it would be useful
First, update your computer's BIOS/firmware. If that doesn't fix it, then try Arch, or Fedora beta. If the problem exists there too, then it's a kernel issue in general, and it might get fixed in the future. OR, if the computer BIOS is buggy, Linus has been clear that they won't do workarounds for buggy firmwares. In which case, you'd need a new computer that's actually compatible with Linux.
Most of the computers out there have buggy firmwares that go around for Windows, but Linus has been adamant that he wouldn't do workarounds because they bloat the kernel.
Well, I updated the BIOS - no change so far. I guess I'm stuck without Sleep. :/
You are not alone. There are many laptops that don't work with sleep on Linux. I used to have one of them, a Dell 3150. I simply disabled sleep in bios, and be done with it. I now buy laptops that I know they work 100% with Linux. It's impossible for Linux to support every hardware in the world, when these are specifically are made for Windows.
I'm curious, did you dig around the BIOS/UEFI to see if there are any ACPI power states that can be disabled?
I had a very similar issue and turning off S3 worked around it. Of course, that meant higher power usage during sleep but it was a compromise over buying new hardware.
Having the same issue on Intel + AMD GPU.
Arch Linux with newest KDE.
That's interesting! Might be KDE bug then.
Could you try going to System Settings → Screen Locking and de-select "Lock after waking from sleep"? I wonder if you'll get the same result as I'm getting.
Before I updated the BIOS to the latest version, once I woke it up, I'd see the desktop exactly frozen as it was the moment I pressed the "Sleep" button.
Now, after the update, that freeze happens BEFORE the PC goes to sleep - the monitors stay on.
Did you contact TUXEDO Support Centre?
Haven't had the time yet, but it's on my to-do list. Just not sure if they will support this as I'm running it on my own hardware, not their laptop.
Give it a try. Perhaps they may give you at least a hint.
This is not a solution at all and just what I usually resort to, I always disable sleep on every OS and computer I use. I've always had strange issues after waking up from sleep that persist until reboot and I can't even remember what they are now because it's been so long since I've used it.
Is your root partition encrypted?
Give the output of
lsblkif you could.alaknar@HostName:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 4K 1 loop /snap/bare/5 loop1 7:1 0 104,2M 1 loop /snap/core/17200 loop2 7:2 0 55,4M 1 loop /snap/core18/2855 loop3 7:3 0 63,7M 1 loop /snap/core20/2496 loop4 7:4 0 73,9M 1 loop /snap/core22/1802 loop5 7:5 0 164,8M 1 loop /snap/gnome-3-28-1804/198 loop6 7:6 0 516M 1 loop /snap/gnome-42-2204/202 loop7 7:7 0 91,7M 1 loop /snap/gtk-common-themes/1535 loop8 7:8 0 10,8M 1 loop /snap/snap-store/1248 loop9 7:9 0 44,4M 1 loop /snap/snapd/23771 nvme1n1 259:0 0 931,5G 0 disk ├─nvme1n1p1 259:1 0 300M 0 part /boot/efi └─nvme1n1p2 259:2 0 931,2G 0 part / nvme0n1 259:3 0 1,8T 0 disk └─nvme0n1p1 259:4 0 1,8T 0 part /media/alaknar/BigStorageI'm not seeing any swap space, so that could be it. Check this post out.
It could also be that your BIOS settings for suspend/resume aren't set to something compatible with your existing config as well though, if the above doesn't work, or you're not comfortable with that level of interaction, check your BIOS first, then try the above maybe.
That exact issue is why I stopped using KDE. I never did figure it out.
Specs for computer havibg the issue ans how long ago did this happen? Seems like a bug that neexs to be reported and more data for devs the better.
Tried it November of 2024, ended up switching to Mint with Cinnamon, zero issues since.
Dell XPS 8930
i7 9700 (no K)
32GB ram
NVidia RTX 2060
240gb ssd
2tb hdd
You could try a tool like LACT and setting your gpu power profile to always highest. Another thing you could check is your BIOS settings, https://www.tomshardware.com/reviews/bios-beginners,1126-8.html or checking if the latest bios is installed https://red.artemislena.eu/r/gigabyte/comments/1b3bffy/gigabye_b650_aorus_elite_ax_rev_10_sleeppower/
Hmm... Wouldn't I also have sleep problems on Windows if this was a BIOS issue?
What kernel version? I had similar issues on similar hardware. These have gone away in more recent kernels though.
6.11.0-109019-tuxedo.
Not the latest, right? I guess I'll wait for an update.
No, but I don't believe I saw the issue until the 6.13.x kernels either