Ubuntu Desktop 24.04 LTS is Not Resuming Properly

Hello Friends

For a ASUS laptop (2016) with 16GB Ram was installed Ubuntu Desktop 24.04.4 LTS.
It works very fast

For other machines in the LAN with Ubuntu when the systemctl suspend command is executed as expected the OS goes suspended until is pressed any key and the login screen appears again

But only in this Asus: the command works but is impossible “resume” … the screen remains in black showing some messages (is not possible read it easily due the font size). Indicate me where I can see that data in the logs to share here for more details Therefore is mandatory press the poweroff button until shutdown the laptop and restart again

Note just in case it is a fresh install and exists a nvidia card (After to did do a research I read it would be a possible issue) without any driver installed because is not required explicit use of the video card itself (video games, graphic design)

Thanks in advance

2 Likes

The file to check is /etc/logind.conf, or /etc/systemd/logind.conf
Compare the parameters there with those in a machine that works.

3 Likes

Hello Neville

In my case is the latter (/etc/systemd/logind.conf)

The original file’s content is

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/logind.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/logind.conf' to display the full config.
#
# See logind.conf(5) for details.

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#UserStopDelaySec=10
#HandlePowerKey=poweroff
#HandlePowerKeyLongPress=ignore
#HandleRebootKey=reboot
#HandleRebootKeyLongPress=poweroff
#HandleSuspendKey=suspend
#HandleSuspendKeyLongPress=hibernate
#HandleHibernateKey=hibernate
#HandleHibernateKeyLongPress=ignore
#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#RebootKeyIgnoreInhibited=no
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RuntimeDirectoryInodesMax=
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192
#StopIdleSessionSec=infinity

Note: For LAN purposes the laptop’s lid event when it is closed is ignored, it with the purpose to keep the OS running. Therefore in some machines is done the following edition (even in Debian) as follows:

  • From: #HandleLidSwitch=suspend
  • To: HandleLidSwitch=ignore

And then is executed the sudo systemctl restart systemd-logind command and do a simple login.

Therefore when the laptop’s lid is closed

  1. The laptop’s screen goes black
  2. The OS is still running

Well it did not work in a MacBook Pro as posted as follows:

Why this history about the /etc/systemd/logind.conf file?

The problem with this Asus (about the /etc/systemd/logind.conf file) is that “1” does not happen. In other words:

  1. The laptop’s screen does not go black

It was confirmed by doing the following approach:

  • The brightness was put in max and when the laptop’s lid is closed is possible see the light of the screen (in the night mostly) through the “slit separation” (if the term is correct) between the lid and keyboard

Well the original configuration for the /etc/systemd/logind.conf file was reestablished and executed the mentioned sudo systemctl restart systemd-logind command.

And even when the OS is reboot the “3” event happens. In other words:

  1. The laptop’s screen does not go black

And

  1. The OS is still running (strange behavior, it should be suspended)

So neville

In the original /etc/systemd/logind.conf file

  • What setting do you suggest to apply?

Really wondered why it is happening for this Asus. I thought it is related with the nvidia card, but I have other laptop (HP Pavilion) with Debian having a nvidia card (none driver installed by my side) and all work as expected (The lid approach and suspend and resume events).

Let me know your thoughts because exists the assumption that the /etc/systemd/logind.conf file must be edited to have the systemctl suspend command working correctly (and resume too)

2 Likes

Maybe uncomment or change one of these

#HandleSuspendKey=suspend
#SuspendKeyIgnoreInhibited=no

I suppose the defaults in logind.conf are the commented lines. … in which case uncommenting does nothing?
The resume issue may be a systemd problem, in which case we can not fix it in the logind.conf file.

I read this
" There are two primary types of suspension in Linux:

Suspend to RAM (S3):
    Keeps the RAM powered while shutting down most other components.
    Allows for quick resumption of work without a full reboot.

Suspend to Disk (S4):
    Saves the system state to disk and powers off completely.
    Requires a longer resume time compared to suspend to RAM."

So which type of suspend is your Asus doing, when you do systemctl suspend?
Are the other laptops the same?
I think S4 may be the same as hibernate.?

It is possible that some hardware or hardware drivers in the Asus may not handle suspend properly. Has this always happened or is it new? If it is new, try winding back the kernel.

Sorry , I have no magic solution. More investigation needed.

2 Likes

Hello Neville

Thanks for the reply

I read this
" There are two primary types of suspension in Linux:

Suspend to RAM (S3):
    Keeps the RAM powered while shutting down most other components.
    Allows for quick resumption of work without a full reboot.

Suspend to Disk (S4):
    Saves the system state to disk and powers off completely.
    Requires a longer resume time compared to suspend to RAM."

Where is the source of that info? (URL)

So which type of suspend is your Asus doing, when you do systemctl suspend?

Excellent question,

Question

  • Is there a command which indicates the “target” location? (If is RAM or SSD?)

Are the other laptops the same?

Have a lot of sense do that comparison. So far this Asus is the only one with this behavior

I think S4 may be the same as hibernate.?

Has a lot of sense because according with my understanding all about the RAM go to the SSD (and even perhaps the machine is shutdown by itself)

It is possible that some hardware or hardware drivers in the Asus may not handle suspend properly.

Or even the BIOS

Has this always happened or is it new? If it is new, try winding back the kernel.

New and from the beginning, Ubuntu was installed just April 21

More investigation needed.

Agree, step by step

1 Like

Sorry, it was an AI summary within DDG browser.

OK, you have some options then.
Find a way to try another kernel … within Ubuntu or use a live USB.
That will test some different driver modules.

We have no diagnosis. You have to try things.

1 Like

OK, you have some options then.
Find a way to try another kernel … within Ubuntu or use a live USB.
That will test some different driver modules.

Do you have some specific tutorial(s) of your own trust to learn how to accomplish that goal?

We have no diagnosis. You have to try things.

Correct, but first I must learn what to do and why I am doing something.

Either copy and paste a command or edit a file “just to be done” is not prudent

1 Like

Do you not know how to install another kernel in Ubuntu?
There may already be one there… look in /boot, or look in the grub menu under Advanced Options.
If there is only one kernel present, look in the repo… there may be others you can install.
If all that fails, try another distro.

1 Like