Under Linux (Debian sid with kernel 6.0.0-4) my framework can’t resume from deep sleep. It seems to enter the sleep state fine, but on resume it completely loses access to the SSD. No commands except shell builtins work and a bunch of filesystem errors scroll by until I hard reboot. Does this ring a bell for anybody?
This is with an Intel i7 Gen 11, 16 GB RAM, and a 2 TB Sabrent Rocket SSD. I originally set up Debian following this helpful guide. Hibernate works, thankfully. Looking for related topics here, this comment from last year caught my eye because of the similar problem and similar hardware:
For some reason, when I try to wake from deep sleep, my entire filesystem gets unmounted. Not sure if its because I have the same Sabrent Rocket 4.0 that someone else had problems with, or something with my kernel.
…but I can’t find anything else about that anywhere.
I tried to simplify things by going to runlevel 3 and manually switching state as root, like:
systemctl isolate multi-user
echo mem > /sys/power/state
…but the behavior is the same as choosing sleep from a GUI option. I’d like to troubleshoot more but it’s tricky what with no commands available Thanks for any tips!
Sorry to hear about this, but Debian is not a distro I’ve had time to drill down on lately. The kernel (generally speaking) is considered older and unsupported, I recommend 6.0.7, or 6.0.9 myself if it;s available.
Baring that, you can try combing through your journalctl to see if anything is helpful there. You can also narrow down the search with sudo journalctl | grep suspend and sudo journalctl | grep resume
Distros that have been doing well in our tests include Fedora 37, Ubuntu (22.04 and 22.10), Manjaro, Arch. Also worth verifying you’re fully up to date.
@Matt_Hartley thanks for your reply! Wait, 6.0.0 is too old? That just came out last month, didn’t it? Though I’ve been long out of the linux-on-desktop world so I might just not be appreciating how fast things are moving. I’m fully up to date with my Debian install as of yesterday but the latest kernel package available is (still) their latest build of 6.0.0. In any case I can try whatever kernel and/or distro for troubleshooting. Though, I only see up through 6.0.0 for Ubuntu too… should I be building my own?
No luck with journalctl. Maybe stands to reason since it can’t write anything once it resumes? For example here’s yesterday, when nothing got logged after the kernel put the system to sleep until I did a hard reboot:
Nov 29 14:57:13 lilboxy sddm[742]: Message received from greeter: Suspend
Nov 29 14:57:13 lilboxy systemd-logind[631]: The system will suspend now!
Nov 29 14:57:13 lilboxy ModemManager[670]: <info> [sleep-monitor-systemd] system is about to suspend
Nov 29 14:57:13 lilboxy NetworkManager[648]: <info> [1669751833.6752] manager: sleep: sleep requested (sleeping: no enabled: yes)
Nov 29 14:57:13 lilboxy NetworkManager[648]: <info> [1669751833.6753] device (wlp170s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Nov 29 14:57:13 lilboxy NetworkManager[648]: <info> [1669751833.7188] device (wlp170s0): set-hw-addr: reset MAC address to BC:09:1B:F4:20:D6 (unmanage)
Nov 29 14:57:13 lilboxy NetworkManager[648]: <info> [1669751833.7303] device (p2p-dev-wlp170s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Nov 29 14:57:13 lilboxy NetworkManager[648]: <info> [1669751833.7304] manager: NetworkManager state is now ASLEEP
Nov 29 14:57:13 lilboxy systemd[1]: Reached target Sleep.
Nov 29 14:57:13 lilboxy systemd[1]: Starting System Suspend...
Nov 29 14:57:13 lilboxy systemd-sleep[917]: Entering sleep state 'suspend'...
Nov 29 14:57:13 lilboxy kernel: PM: suspend entry (deep)
-- Boot 8ab07bbe9e3b4f78a361e011b21acc85 --
Nov 29 14:59:03 lilboxy kernel: Linux version 6.0.0-5-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC Debian 6.0.10-1 (2022-11-26)
I also realized I have a spare M.2 drive I might be able to use for testing. Between that and the other distro options you’ve suggested I have some things to work with and hopefully I can narrow it down some more. Thanks for your help.
Emphasis on older (as in previous generation to current), not old. Sorry if that wasn’t as clear as it should have been.
Ubuntu has 5.15 which is also previous to current (older), but not old as in dated.
It would be interesting to try the other drive for testing. Any peripherals attached to your Framework Laptop? I’d test by unattaching anything connected.
Then if still acting up, try the other drive.
If it’s still causing issues, I’d test another distro entirely. To rule out hardware completely.
Thank you both for your replies. I get what you mean about the kernels, thanks. And no peripherals attached, just three USB-C expansion cards and one USB-A. I don’t think I’ve seen any keyboard trouble with this but I’ll check that out in more detail.
I tried the second drive, which was already in an enclosure with a USB-C connector, by installing an OS and booting straight from that USB connection. I thought I was being clever just going with USB as an easy test, but in the process I somehow emptied out my EFI boot info for the existing drive. I did notice the one time I tried deep sleep from the second drive it had trouble resuming with more filesystem complaints, but that was still just on Debian to start with, so I haven’t narrowed this down much. (I should have just swapped the drives for the test! Or made sure to understand EFI better I suppose.) For the moment I’ve booted my existing OS via GRUB command line off a USB stick and I’m going to try to fully fix that before I get back to tinkering with this sleep thing. I’ll report back whatever I find.
I put the laptop into deep sleep (via a desktop manager, or /sys/power/state, same deal)
Power button LED is gently pulsing, all seems well
I press the power button once
It seems to wake up normally for about 1 second, but then (when it realizes it can’t access the root filesystem?) I get a ton of filesystem-related errors on the screen and the whole thing locks up
Unfortunately nothing gets logged anywhere since it can’t write any files
I was able to fully fix grub just now from my previous screw-up, so I should be able to actually test with that second drive and/or other distros shortly.
Some news! I tried a few different combinations of things, but I think the key bits are:
an equivalent Debian install on that extra drive connected over USB can deep sleep and resume OK but /dev/nvme* (the Sabrent Rocket drive still connected internally) disappears on resume.
a Fedora 37 live USB stick can deep sleep and resume and can see /dev/nvme* on resume.
So @Matt_Hartley, good suggestion about the other distros. I’m betting it’s between the different kernels like you said.
Edit: also, looks like I was just confused about Debian package and kernel naming conventions before; turns out I already am running a pretty recent kernel on the Debian side.
I haven’t used Debian in ages. Just not my focus. That said grep likely has the most accurate information.
Delighted to hear it sounds like you are making progress on this front.
It’s been my experience (well over a decade) that what fails with one distro, often works with another. Kernels, different versions of libraries, there are numerous factors.
I use Ubuntu 22.04 and 22.10, Fedora 37 and POP OS 22.04, everything just works on my 12th and 11th gen Framework laptops. And most recently, Linux Mint’s latest beta also works great, guide updated.
I think I’ll just make some room for a second Linux distro and see how it goes, maybe with Fedora this time. It’s been a number of years since I’ve dealt with Linux a desktop/laptop anyway so I may as well get re-acquainted with my options. Thanks!
@Carlos_Fernandez_San wait, so you run into this SSD problem with s2idle but not deep sleep? Funny, it’s the other way around for me, so I’ve just been using s2idle lately. (And actually, Fedora does have the same problem for me when running off of the Sabrent NVMe drive directly, just not when running separately over USB. I’m stumped on what’s going on though.)
Interesting, not seeing this with either state. Are these drives provided by Framework and if so, which drives/model are they? Also please reiterate which distro this was being experienced with?
Not in my case-- mine is a 2 TB Sabrent Rocket SSD that was installed in a DIY edition by the previous owner. I’m seeing this on Debian Sid (unstable) and also Fedora 37.
Since I got sleep working with s2idle I put my issue on the back burner for a while. From the behavior with different distros and drives I still suspect something odd to do with the specific SSD, but I’m not certain (so I’m curious to hear about this other person’s situation). I’d like to try things more under Fedora anyway because of various kinds of flakiness with the Debian install (the unstable version is, go figure, proving unstable) and Fedora did feel more polished and stable from just a brief try recently.
Thanks for your persistence in these forum threads!
Nope, same exactly behavior on both distros when both plugged in or unplugged (tested a bunch of times since it’s been so slippery to diagnose). And yeah I’d seen at least one post here about this drive so I was thinking it could be something weird about it and the kernel (edit: or UEFI firmware I wonder? but I’m getting well outside of my area here) not getting along, but haven’t made any headway figuring it out. Thanks!
Thanks for any tips!