What do you mean all user programs ? Is budgie killed too ? Or only programs you started like firefox, nautilus and Steam ?

In T7836#148660, @Tzigamm wrote:

What do you mean all user programs ? Is budgie killed too ? Or only programs you started like firefox, nautilus and Steam ?

What I mean is this:

• I start a bunch of programs, Firefox, Thunderbird, Gnome Calendar, what have you.
• I do

systemctl hibernate

or use the "hibernate" option from the powe settings in my Solus Budgie; then

monitor shuts down, laptop seems to go into hibernate state. However:

• I press the power button once to wake up the laptop
• laptop goes to 'login/open session' state
• I login -- all the aforementioned programs are closed.

I would like to know how to diagnose the issue and possibly fix it. As far as I know it could very well be a problem in the way my system is setup, rather than a problem which in general affects Solus Budgie.

So basically, the state of the computer is exactly the same as when you power off and then power on the PC, right ?

In T7836#148670, @Tzigamm wrote:

So basically, the state of the computer is exactly the same as when you power off and then power on the PC, right ?

Exactly. I just wanted to stress the fact that my session was not restored, but I wanted to express myself in a neutral way, without conveying the presupposition that my system indeed rebooted (I don't know exactly what my system did -- perhaps rebooted, perhaps came back from hibernation without saving the session).

Can you hear/see the PC rebooting? What does uptime returns before and after hibernating?

In T7836#148672, @Tzigamm wrote:

Can you hear/see the PC rebooting? What does uptime returns before and after hibernating?

It's a very silent laptop with SSD so I wouldn't trust sounds that much.

uptime

returns the time at which I 'wake up', i.e most probably reboot the PC.

Generally speaking, I would need a procedure to get fresh logs so that I can put my finger on what prevents hibernate from working. Then you could tell me if the culprit is on my end or if it's a bug proper. A nice complementary measure would be a simple step-by-step guide on how to double-check swap partitions in view of using them for hibernation on Solus Budgie.
Sorry, I am very new to the Linux world.

Well systemctl's logs are readable through journalctl, I think you can see kernel errors using dmesg but you'll need to see this link and try to see where are the logs from the previous boot (if it rebooted as I think it did)

Pending my checking out the logs, here is what I did so far:

• Reformatted the swap partition with

mkswap

• Added

UUID=9c9bf9fe-a705-43bf-a19b-e45f864d434b	none	swap	defaults			0 0

to /etc/fstab.

• And by the way:

swapon -s

returns

Path				Type		Size	              User	 Priority
/dev/sda4                              	partition	17407996	0	-2

and

swapon /dev/sda4

returns "Device busy' as to be expected from a correctly installed swap partition.
That's where I am lost...

Is the swap recognized by the system ? You can use the free command to check

You'll have to change the "resume" kernel parameter if you reformatted your swap, you can do it by editing /etc/kernel/cmdline.d/10_resume.conf and changing the existing UUID by the one you added in fstab, then you'll have to do a clr-boot-manager update to apply the changes

/etc/kernel/cmdline.d/10_resume.conf

is not a valid path on my rig. Also,

sudo find / -type f -name "10_resume"

returns

find: ‘/run/user/1000/gvfs’: Permission denied

:(

I think the permission error is normal, don't worry about that

What does sudo tree /etc/kernel/ returns ?

In order to get the hibernation working you'll need to add the kernel parameter as I told you in my other message, I guess just creating the folders will do the trick if they don't already exist!

Okay, did as you suggested, my

/etc/kernel/cmdline.d/10_resume.conf

now reads:

resume=UUID=9c9bf9fe-a705-43bf-a19b-e45f864d434b

Correct? By the way, just to be sure, I did

dmesg --level=err

and got:

[ 1843.243014] nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 1, busy: 1)
[ 1843.243752] nouveau 0000:01:00.0: fifo: runlist 4 update timeout
[ 1843.244373] nouveau 0000:01:00.0: fifo: runlist 0 update timeout
[ 1843.245296] nouveau 0000:01:00.0: fifo: runlist 0 update timeout
[ 1843.245912] nouveau 0000:01:00.0: fifo: runlist 4 update timeout
[ 1858.244998] nouveau 0000:01:00.0: DRM: failed to idle channel 1 [DRM]
[ 1858.245027] pci_pm_freeze(): nouveau_pmops_freeze+0x0/0x20 [nouveau] returns -16
[ 1858.245029] dpm_run_callback(): pci_pm_freeze+0x0/0xc0 returns -16
[ 1858.245031] PM: Device 0000:01:00.0 failed to freeze async: error -16
[ 1859.736326] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[ 1859.736328] pcieport 0000:00:1c.0:   device [8086:a112] error status/mask=00000001/00000000
[ 1859.736331] pcieport 0000:00:1c.0:    [ 0] RxErr                 
[ 1859.815737] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[ 1859.815739] pcieport 0000:00:1c.0:   device [8086:a112] error status/mask=00000001/00000000
[ 1859.815740] pcieport 0000:00:1c.0:    [ 0] RxErr                 
[ 1880.841976] nouveau 0000:01:00.0: DRM: failed to idle channel 1 [DRM]

So apparently, unrelated to the specification of the partition to resume from, there is a nouveau driver standing between my system and hibernate. As it happens, my laptop as 2 GPUs (Intel and Nvdia) but I am only using the Intel one on Linux since I don't need powerful graphic rendering. Indeed:

sudo glxinfo | grep renderer

returns:

GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, 
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)

That's some narrowing down on to the culprite, isn't it?

I think so, don't forget to do a sudo clr-boot-manager update before rebooting and you should be able to test it!

You may get a warning about lvmetad, you can ignore it safely!

Sorry, read again, I edited :)
(the dmesg logs were taken after I did

sudo clr-boot-manager update

)

It could very well be nouveau's fault, you can try to use the proprietary drivers but if you don't want to use the nvidia card I guess you could blacklist the nouveau module!

Holly molly, that worked!
added

nouveau.modeset=0

to /etc/kernel/cmdline

Huge thanks for your patience and perseverance to track the culprit! Have a beautiful week!

Praise the GNU!

Enjoy Solus, I swear it usually is easier than this ! Have a great week too !

In T7836#148723, @Tzigamm wrote:

Is the swap recognized by the system ? You can use the free command to check

You'll have to change the "resume" kernel parameter if you reformatted your swap, you can do it by editing /etc/kernel/cmdline.d/10_resume.conf and changing the existing UUID by the one you added in fstab, then you'll have to do a clr-boot-manager update to apply the changes

Since installing Solus a few days ago for work, I really like it and I've been at fixing hibernation for days, because hibernate kept shutting down and discarding my sessions. But your solution worked for me instantly and my system hibernates now.

I registered just now to say THANKS! @Tzigamm