Going to sleep instead of logging in while lid closed & external display

[Alexander Bischoff]

I have the above described problem, which seems to be very similar to bug #1716160

- laptop is in docking station and 2 monitors are connected (HDMI, DVI)

- If the lid is closed and I boot the laptop I can input my credentials in the login screen and after hitting ENTER the laptop goes to sleep

- If I then press the power button of the docking station the laptop wakes up and goes straight to the ubuntu environment w/o any user identification

The device is a Lenovo T420 with classic docking station. Ubuntu 18.04.3 LTS. Internal graphics Intel integrated grafics and dedicated Nvidia Quadro NVS 4200M with propriety driver 390.116. Behavior independent of the graphics used.

I do not know what to do now since the latest state of bug #1716160 is "fix released" and so I guess it should be part of the ubuntu version I use?

Thank you very much.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gnome-shell 3.28.4-0ubuntu18.04.1
ProcVersionSignature: Ubuntu 5.0.0-25.26~18.04.1-generic 5.0.18
Uname: Linux 5.0.0-25-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Aug 28 20:10:15 2019
DisplayManager: gdm3
GsettingsChanges:
 b'org.gnome.shell' b'app-picker-view' b'uint32 1'
 b'org.gnome.shell' b'favorite-apps' redacted by apport
 b'org.gnome.desktop.interface' b'gtk-im-module' b"'gtk-im-context-simple'"
 b'org.gnome.desktop.interface' b'show-battery-percentage' b'true'
 b'org.gnome.desktop.interface' b'clock-show-date' b'true'
InstallationDate: Installed on 2019-08-13 (14 days ago)
InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

[Daniel van Vugt (vanvugt)]

I think the problem here is that gnome-shell detects the lid is closed already and treats that like you just closed the lid immediately on login.

I have heard about this kind of problem before and am not sure if it's already been fixed in later versions.

[Alexander Bischoff (omipo)]

That might be but that doesn't explain why the system goes to the "desktop" straight after pressing the power-button w/o identification.

I disabled "energy mode if laptop-lid is closed" in "Tweak" (for gnome), no improvement.

If I let open the lid for 2...3 cm it workes, but then the login-screen is always in the built-in laptop-screen.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tim Wetzel (twetzel21)]

A few things that may help with this, these were noted under bug 1897185. In looking at logs when this occurred (observed on ThinkPads including T440s, T570, T480 all docked and running lid-down with external display, keyboard, etc); this behavior occurred when:
-using a third-party nVidia driver for discrete graphics card; or
-when a Logitech USB dongle for a Logitech wireless mouse was plugged in to the dock and the mouse turned on during power up; or
-when the Dropbox app was installed and automatically loaded during startup.
The behavior could be avoided by:
-using the Ubuntu xorg driver for the discrete graphics card;
-turning off the Logitech mouse during startup;
-turning off Dropbox synching and closing that app prior to shutdown so that it would not load automatically at startup.
Sharing this in hopes that it may help with debugging, and to make reproducing the issue easier?
Thanks.

[Tim Wetzel (twetzel21)]

Three additional points:
-This occurs with ONE external HDMI monitor connected to the dock and running as the primary display. Need not be multi-monitor. All cases I've seen involve one external monitor.
-I put log information in the notes for 1897185 to show the events that preceded the suspend.
-I never saw this on LTS 20.04 until after the mid-September 2020 Ubuntu updates (including, as I recall, an upstream fix for a security vulnerability; updates to 20.04.1; and an nVidia driver update all of which occurred within roughly 2 weeks).
Thanks.

[Johan Larsson (jolars)]

I have this problem as well on ubuntu 20.10 on a Thinkpad T14 with integrated Geforce MX330 graphics. My laptop is closed and docked via a thunderbolt 3 dock to a single external monitor.

I have tried the fix proposed here: https://askubuntu.com/questions/1083720/ubuntu-goes-suspended-after-login-if-lid-is-closed/1239573#1239573 to no avail.

[Tim Wetzel (twetzel21)]

Johan, is the external monitor connected to the dock with an HDMI cable?

[iMac (imac-netstatz)]

In my case, XPS 13 9380, 20.10, both external monitors via TB3/USB-C -> 2 x HDMI @ 1440p, internal Intel UHD 620

- no nVidia
- two external monitors, lid closed at boot
- no Dropbox

I do use a logitech USB keyboard and mouse (wireless USB dongle) at the workstation where this occurs, in a different USB-C port than the port replicator to which my monitors are connected. I will test logging in with the mouse off, but I am skeptical on the relationship between the timing of the enumerated mouse input and this bug.

[Johan Larsson (jolars)]

No, Tim, it's connected via display port. I don't have any logitech gear and disabling autostart for Dropbox does not help.

[Tim Wetzel (twetzel21)]

Johan and also iMac, thank you...
I was trying to see whether this issue correlated with the type of cable between the dock and the external display; but obviously not since we're seeing it with both HDMI and DP.

I'm not suggesting that a particular item such as the Dropbox app, Logitech USB driver, etc is the cause; but I'm hoping that these observations may help those of you who are trying to reproduce the issue to do so. My background is application programming, not system; so I can offer anecdotal observations and check logs but am not able to dive into the code.

I do urge those of you who can to do so. This is once again progressing. This morning (and after having allowed the kernel update to 5.8.0.36.40 just a couple days ago), the system *froze* rather than going to sleep. First I lost the external display. So I opened the laptop lid (docked) and had a bizarre set of 3 or 4 error messages. Those cleared to solid black before I could get a pic. I couldn't get any response after that so had to do a hard power down. Not good! I brought the machine up standalone, let it idle a few minutes, shut it down, and put it back into the dock. Then it was back to this bug's suspend after login.

This again is Ubuntu 20.04.1, now the kernel just noted, on a T570 in the classic UltraDock using an external HDMI display, external Lenovo USB keyboard, and Logitech *bluetooth* mouse. Lid closed so external display is primary. Note that the Lenovo USB mouse has developed serious scroll wheel issues: I'm not yet sure whether that is Ubuntu or hardware. My overriding concern is that Ubuntu remains unstable at best since the mid September updates.

[iMac (imac-netstatz)]

Here are a few more observations on this login sleep issue ('it') :
- not 100% of the time, does this occur
- I experimented with the input devices (logitech) enumerated before / after login and saw no change/impact on it from that activity
- I have seen it on a reboot, without any state change on the closed lid
- I have seen it when starting up with the lid open (once in a while I power it up and don't immediately close the lid, ending up with 3 displays including the panel), after closing the lid to return to 2 display mode, and logging in, it has occurred again
- I have seen it after powering up, leaving the computer idle for 15min at loging screen, and then login only to have it occur
- The dead giveaway for me visually, is that my wifi icon is missing or immediately disaappears as I login, a signal to me the sleep process has started.

[Stefan Kose (mrk1982)]

Hi there. I'm quite new to launchpad and don't know if my behavior is the right way now. I experience this same problem on actually five Lenovo P15s with Ubuntu 20.04 running on kernel 5.8.0-44-generic. My problem is, that I can't hand out those systems to our developers in their remote-offices until this is solved or worked around in any way and also that one of those laptops is my own one :-/
The "login to nirvana" occurs on every boot now, as far as the notebook is connected to its tb-dock and the lid is closed. What really concerns me is, that there is no way to "wake up" the system from the power down state. I tried a lot, but I have to hard-power-down them, otherwise they don't come up anymore.
Has anyone found a workaround for this, until the problem is solved by the developers?

[iMac (imac-netstatz)]

Most days, when this occurs, I just open up my lid and/or tap the power button and it wakes up, and I close the lid again once it is awake.

In my particular case, when I wake up my laptop, my CableMatters 201055-BLK thunderbolt port replicator sends my dual display 1440p monitors into 1080p briefly as my 2160p laptop panel comes to life; I close the lid and everything is back to normal on my dual 1440p panels.

All to say, I can wake up my system by opening the lid and/or hitting the power button.

If I had to bet, I'd say the thunderbolt port replicator implementation is part of the problem, as I see quirks with the various gadget drivers running across it regularily that, thankfully, do not impact me as they are not in my usual use case:

a) Using PD via the replicator sometimes requires re-plug before laptop detects power and I don't think the charging is quite as fast, possibly not ramping up the the Max Dell power rates for the port
b) Moving my Logitech keyboard/mouse dongle to the replicator from a local port results in sometimes getting keyboard timeouts (even though the mouse is fine over same dongle)
c) Opening the lid, the displays do not always switch modes correctly to the 3 screens (2 x 1440p and 1 x 2160p panel) and sometimes as bad as what appears to be a useless 800x600 section of the actual desktop shown on one of the external displays, closing the lid always returns to proper dual 1440p

These are the devices that enumerate on my replicator, with 04b4:f649 being the main one driving the Displays and thunderbolt and the FE and USB devices attached.

Bus 001 Device 011: ID 0bda:8152 Realtek Semiconductor Corp. RTL8152 Fast Ethernet Adapter
Bus 001 Device 010: ID 04b4:f649 Cypress Semiconductor Corp.
Bus 001 Device 009: ID 1a40:0101 Terminus Technology Inc. Hub

[iMac (imac-netstatz)]

And the SDK for my Cypress replicator is documented here:

https://www.cypress.com/file/333231/download

Notably: Integrated bootloader to support firmware update over I2C

Maybe I can flash this thing to better support power/display modes, assuming that is the nature of the issue

[iMac (imac-netstatz)]

And sure enough, there is a firmware update:

https://www.cablematters.com/download/201055_201046/201055_201046_Firmware.zip

https://www.cablematters.com/cs-Downloads.aspx

Will report back...

[Tim Wetzel (twetzel21)]

On our systems, T480 and T570's, this issue continues to occur EVERY STARTUP when the machine is run in the UltraDock, lid down using and external HDMI display as primary. Sometimes it is possible to bump the dock power again to restart it (and then it goes to the desktop WITHOUT any password prompt even though it should prompt for password when coming out of suspend); other times recovery is not possible and a hard power down is required. PLEASE fix this! This started, to reiterate, with the disastrous mid-September 2020 Ubuntu 20.04 updates. Thank you.

[iMac (imac-netstatz)]

Firmware update to my CableMatters thunderbolt/USB-C/PD dock seems to have fixed my issues (no occurances since).

I suppose I have to assume that improved driver support in the newer kernel may have exposed some issues in the hardware that were fixed with the update.

Notably I can run dual 1440p with full 4k panel on the laptop open as well, so one of those 3 display quirks I mentioned also disappeared.

[EAB (adair-boder)]

My work setup doesn't change. Same laptop (Thinkpad P14s), Ultradock, peripherals, screens etc ... and yet the behavior is very erratic. Just locking the screen will set the laptop into this useless zombie state. Most of the time the laptop has then got to be removed from the dock, woken out of sleep, lid closed again, and re-docked, before it's useful again on the dock.

I cannot believe how badly broken this is! And in an LTS no less ...

[Tim Wetzel (twetzel21)]

Agree that this is a serious issue. Like EAB, each of our setups remains constant: same laptop, dock, display, etc. This issue continues to recur probably 11 out of 12 startups when docked lid down. Notably, I have almost never seen it when the laptop is running standalone (out of the dock).

Note that I do NOT try to hot dock or undock; these are all full shutdown/cold starts or manual suspend/later resume. And I rarely attempt the suspend/resume. That is only if I've been using the machine stand alone and suspended it, expecting to resume again standalone but instead wind up at my desk in the office.

On the rare occasions when it's docked and doesn't suspend at the login prompt, it will then often throw an error like unable to lock due to application when it would (abnormally) suspend; and then when it reaches the desktop the wifi won't work or the dock's usb mouse won't work or something. Also, on the next restart after that, after suspending and my pressing the dock power again, I will often get a timing error instead of video on the external display. I have to then open the laptop lid in the dock and sometimes can take control to shut down. Other times I have to force power down at that point. Once that happens, I have to take the laptop out of the dock, start it stand alone, shut it fully down, dock it, and try again....

PLEASE fix this. Again: this was NOT an issue until the September 2020 Ubuntu updates to 20.04.1 which I believe also included a kernel update to address a security vulnerability? In any case, this started shortly after that. And yes: this should not be happening in an LTS version.

[EAB (adair-boder)]

I guess this won't get fixed before the next LTS. Importance is still "undecided" and it hasn't been assigned to anyone ... :/

[iMac (imac-netstatz)]

I would try and figure out what chip is used in the Ultradock; It might
have been like the Cypress based one I had, which also worked fine before
Ubuntu upgrade, broke, and then worked fine with current Ubuntu after a
firmware update to the chip.

If the Ultradock uses a thunderbolt connection, then getting another
thunderbolt dock via USB-C adapter, like perhaps maybe the $50 one I was
able to upgrade into working state, and testing it, to isolate the software
issue to the platform or the dock may be helpful.

One outcome would be to say to the Ultradock folks to say that other
thunderbolt docks are working, but the Ultradock is not. i.e. Fix the
dock to work with modern drivers
Another outcome would be that you have 2 thunderbolt docks that behave the
same way to add to the issue. i.e. Hey Ubuntu neither of these docks (one
of which works on other platforms) is working with my platform

Finding a maintainer and sending a generic non-functional dock (or your
more expensive entire setup if you are an enterprise that wants this
solved) might be a third option, as there is probably a quirk that could be
added to the kernel to make it behave like it used to for broken chips,
another common practice when the hardware vendors don't come up for air on
these issues. Marvell PCI disk controllers with VT-d enabled comes to mind
:)

On Mon, May 3, 2021 at 12:55 PM Tim Wetzel <email address hidden>
wrote:

> Agree that this is a serious issue. Like EAB, each of our setups remains
> constant: same laptop, dock, display, etc. This issue continues to recur
> probably 11 out of 12 startups when docked lid down. Notably, I have
> almost never seen it when the laptop is running standalone (out of the
> dock).
>
> Note that I do NOT try to hot dock or undock; these are all full
> shutdown/cold starts or manual suspend/later resume. And I rarely
> attempt the suspend/resume. That is only if I've been using the machine
> stand alone and suspended it, expecting to resume again standalone but
> instead wind up at my desk in the office.
>
> On the rare occasions when it's docked and doesn't suspend at the login
> prompt, it will then often throw an error like unable to lock due to
> application when it would (abnormally) suspend; and then when it reaches
> the desktop the wifi won't work or the dock's usb mouse won't work or
> something. Also, on the next restart after that, after suspending and my
> pressing the dock power again, I will often get a timing error instead
> of video on the external display. I have to then open the laptop lid in
> the dock and sometimes can take control to shut down. Other times I have
> to force power down at that point. Once that happens, I have to take the
> laptop out of the dock, start it stand alone, shut it fully down, dock
> it, and try again....
>
> PLEASE fix this. Again: this was NOT an issue until the September 2020
> Ubuntu updates to 20.04.1 which I believe also included a kernel update
> to address a security vulnerability? In any case, this started shortly
> after that. And yes: this should not be happening in an LTS version.
>
> --
> You received this bug notification because you are subscribed to a
> dup...

[EAB (adair-boder)]

I can confirm that the same behavior occurs with the Thinkpad USB-C Dock Gen2 (FRU PN: 03X7609 Type: 40AS).

[george holmes (atlz06)]

Lenovo 4338 Mini-Dock with Nvidia K1000M running Dual external monitors. Ubuntu 20.04 suspends after login as mentioned. This seemed to start after loading the Nvidia 390 driver since the Nouveau driver did not work correctly. The video is fine now and everything works fine except I login, the suspend occurs, I press the dock power button and the machine runs normally.
My first assumption is its the video driver and I searched for suggested fixes or alternative drivers. Not sure which way to go seems like a few Lenovo users here are in the same place.

[Tim Wetzel (twetzel21)]

See comment #5 above. Yes, the nVidia driver may appear to be a common denominator BUT... I've seen the issue trigger apparently due to other things loading as opposed to nVidia's third party driver, so it may not be anything in the nVidia driver per se. The occurrences due to other utilities (like Dropbox or Logitech drivers) make me suspect a timing issue??? That something in the load sequence after logging in is timing out due to additional drivers and/or the timing "overhead" of a dock being present. And I say that because the same configuration on the same machine loads fine (no suspend at login) when used standalone out of the dock; but the issue recurs as soon as the machine is started back in the dock.

And yes, this is both consistent and frustrating!

[EAB (adair-boder)]

@Tim Wetzel,

Or maybe it's not just a matter of it being docked, but rather to do with the laptop lid being closed while being logged into!? I never tried this, but maybe if an external monitor, mouse and keyboard is connected without the laptop being docked, and the laptop is booted and before the laptop even starts booting the OS the lid is closed - so mimicking the way that the laptop boots while docked, but without it being docked. Would be interesting to see if the same problem occurs. If it did this would point to the problem stemming from the laptop lid being closed during login - regardless of whether or not the laptop is docked.
I cannot recall the problem occurring while the laptop is docked with the lid open.

[iMac (imac-netstatz)]

Well, in the case of a Lenovo 4338, a quick google shows it is based on the SMSC2517, (https://joes-tech-blog.blogspot.com/2017/09/whats-inside-lenovo-docking-station-for.html) and well, another quick google show SMSC was aquired by Microchip, and after a third Google, I can tell you the USB controller chip and see that it even has published suspend-related errata that they do not plan on fixing that was discovered in Windows 8 days.

Some excerpts below:

Module 1:
End of User Impacts:
Port might fail to go into SUSPEND.

Solution:
This will not be addressed in a future version of the device.

Module 2:
End of User Impacts:
Device might not enumerate.

Solution:
Use external power on reset circuit (for example, reset circuit with MAX809S(V2.9V) voltage supervisor)

https://ww1.microchip.com/downloads/en/DeviceDoc/80000628A.pdf

Likely these quirks are not being backported into the drivers, to workaround in software for certain scenarios, and so are being stumbled upon with more advanced multi-device scenarios now supported in newer Ubuntu versions.

I would isolate the dock showing that the scenario works with a different port replicator/chip, and then either

a) use the other port replicator
b) reach out to the maintainer of the driver, see if you can give him some hardware, a reproducable scenario, you might be able to get a fix
c) find a developer for hire, do the same, upstream a patch

[george holmes (atlz06)]

So far this only occurs on the initial login after boot-up. Subsequent suspends do not cause an issue. If I remove the laptop from the dock no issue, but now I only have the laptop screen. The machine I'm using is a W530. For me this appears to be an initial boot-up only issue, of course I still would like to fix this. I can see where if used in lab environments it can be a serious issue, especially if your remote.
I've seen Windows Sleep issues years ago, I haven't seen that many lately in Windows. Certain code can cause sleep issues for this laptop, power managers for one.

[Tim Wetzel (twetzel21)]

Just want to remind us that this was NOT AN ISSUE UNTIL after the September 2020 Ubuntu 20.04 updates that included the updates to 20.04.1. Therefore I have trouble with dismissing it as a known, unaddressed hardware issue. If so, why did it work fine prior to those updates? No: there were several old bugs (things that were fixed in Ubuntu in months even years past) that came back after those September updates. For example, the initramfs issues (and I just saw a number of initramfs-related updates in the most recent 20.04.1 updates) that have had to be fixed again.

Going by the old adage of what changed last: this sure looks and feels like software rather than hardware...

And George: yes this is on "initial" startup in the dock. I typically let the system run and just use screen blanking when it's docked; then do a shutdown when I'm leaving the office. I don't typically use suspend when it's docked; but when I have (to test) it has resumed normally: I press the spacebar to get the login prompt; enter the login; and the desktop reappears. I also don't hot dock or undock. That's part of the reason I don't suspend in the dock: if using suspend that way, then most likely the laptop will be undocked and re-docked while in suspend. So it will resume in a different configuration. Yes that should work, but I try not to "invite" trouble(!)

[george holmes (atlz06)]

It finally crashed, no video on suspend. I likely never reached 2 hrs. before I shut down. So everything's similar to others it seems. I'll try some things and see. If I can do anything I'll update. If it isn't avoidable at least I understand it and won't waste too much time until I see something posted.

[Eric Jackson (euangeleo)]

I believe I have the same behavior with different hardware, and no docking station: I have a Dell Latitude 7480 which I typically use with an external monitor (via HDMI), USB mouse, and USB keyboard, while the laptop sits behind a desk with its lid closed.

Up until April 2021, I was running Ubuntu 16.04 on this machine with the (standard for 16.04) Unity desktop, with the same physical configuration--that is, while working at home, I kept the laptop itself closed behind my desk, and used it via the external mouse, keyboard, and display. Prior to upgrading, I was able to log in without any problems associated with the lid being closed.

On April 22, 2021, since 16.04 would no longer be getting updates, I finally upgraded through 18.04 to 20.04, still using the Unity desktop. Now, from a cold start, I get the user log-in screen, and immediately after entering my password, the system suspends. If I open the lid a few centimeters, the system resumes without prompting for a password.

If my problem is really the same problem that @twetzel21 is seeing--and in terms of the behavior he describes, it appears that it is--this suggests to me that it's neither related to a dock, nor to anything with Nvidia drivers (since I have only Intel integrated graphics and do not have any Nvidia drivers installed), nor related to a hardware issue. Although I use my laptop with an external screen, mouse, and keyboard, they're not connected through any dock, but just using the normal ports on the machine. Moreover, this behavior didn't happen for me with the same hardware in 16.04, but began only when I moved through 18.04 to 20.04.

Moreover, when I upgraded to 20.04, I installed gnome-tweak-tool, and under General I have "Suspend when laptop lid is closed" *un*checked. Moreover, in the system settings > Power options, the dropdowns are set to "Do nothing" when the laptop lid is closed, both on battery or on outlet power.

I *do* have the Dropbox client installed and set to start up on login, which I see was one issue that was raised as potentially related. I know that, since my system doesn't represent a clean install of 20.04, it's going to have a bit more cruft than normal, but I'm happy to make any system information or syslog portions available.

[EAB (adair-boder)]

@Erik Jackson, it seems you confirmed my suspicions (see comment #26).

[fchen (fchen0000)]

I also have this problem.
Ubuntu 21.10, Dell 7520 with Nvidia, single monitor HDMI connection.
ps: I do have a logitech mouse with dongle and I did not test if it matters. I noticed this behavior about 1-2 days ago. Previous it did not seem to be an issue. Not sure if it's due to an update or a new package.

[Tim Wetzel (twetzel21)]

Yes, this is still a problem. Please see post #5 above and /bugs/1897185 where I posted earlier information. As noted by fchen, this started with Ubuntu updates and has been a problem ever since, though I started seeing it months ago.
PLEASE fix this.
Thanks.

[Tim Wetzel (twetzel21)]

New wrinkle: today on startup (from full shutdown), in dock, lid down with HDMI monitor and external keyboard and mouse, got to the Ubuntu login and put in the password. Was waiting for this suspend bug to appear. Instead: got a Linux error as follows at the point where this bug typically exhibits:
>>
setparms 'Ubuntu"
recordfail
load_video
gfxmode $linus_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ] insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root 7c8ac294-9840-4cea-81dd-e9507641f946
else
   search --no-floppy --fs-uuid --set=root 7c8ac294-9840-4cea-81dd-e9507641f946
fi
linux /boot/vmlinuz-5.13.0-30-generic root=UUID=7c8ac294-9840-4cea-81dd-e9507641f946 ro quiet splash $vt_handoff
initrd /boot/initrd.img-5.13.0.30-generic
>>
I pressed ESC to discard edits and return to the GRUB menu. Then tried the same thing again. This time it took the password and then displayed this suspend bug as expected...
Once at the desktop, I got a message from Software Updater that there are pending updates including the following; not sure whether this is related to recent nVidia and kernel updates interacting with this bug???
   Daemon and tooling that enable snap packages
   NVIDIA X Server Settings
Note that this is on a Thinkpad T570 set up with dual boot. The most recent updates were:
   2/7/22: nVidia update from 470.86~20.04.2 to 470.103.1~20.04.1
   2/17/22: Kernel update from 5.13.0.28.31~20.04.15 to -.30.33~-.17
   and yesterday some (what appeared to be) minor updates.
The machine is running poorly, which is unusual.
PLEASE!!!!! FIX THIS BUG; see post #5 above and prior bug report number 1897185 where more details were reported.

[Tim Wetzel (twetzel21)]

New wrinkle: over the weekend on startup (from full shutdown), in dock, lid down with HDMI monitor and external keyboard and mouse, got to the Ubuntu login and put in the password. Was waiting for this suspend bug to appear. Instead: got a Linux error as follows at the point where this bug typically exhibits:
>>
setparms 'Ubuntu"
recordfail
load_video
gfxmode $linus_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ] insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root 7c8ac294-9840-4cea-81dd-e9507641f946
else
   search --no-floppy --fs-uuid --set=root 7c8ac294-9840-4cea-81dd-e9507641f946
fi
linux /boot/vmlinuz-5.13.0-30-generic root=UUID=7c8ac294-9840-4cea-81dd-e9507641f946 ro quiet splash $vt_handoff
initrd /boot/initrd.img-5.13.0.30-generic
>>
I pressed ESC to discard edits and return to the GRUB menu. Then tried the same thing again. This time it took the password and then displayed this suspend bug as expected...
Once at the desktop, I got a message from Software Updater that there are pending updates including the following; not sure whether this is related to recent nVidia and kernel updates interacting with this bug???
   Daemon and tooling that enable snap packages
   NVIDIA X Server Settings
Note that this is on a Thinkpad T570 set up with dual boot. The most recent updates were:
   2/7/22: nVidia update from 470.86~20.04.2 to 470.103.1~20.04.1
   2/17/22: Kernel update from 5.13.0.28.31~20.04.15 to -.30.33~-.17
   and yesterday some (what appeared to be) minor updates.
The machine is running poorly, which is unusual.
PLEASE!!!!! FIX THIS BUG; see post #5 above and prior bug report number 1897185 where more details were reported.

[Shadrin Ilya (ishadrin)]

This might be FIXED by setting HandleLidSwitchDocked=ignore in

/etc/systemd/logind.conf

Although i would still appreciate if this use case will be better implemented on OS level (performance wise)

[Tim Wetzel (twetzel21)]

Shadrin, I tried that... removed the # from the start of that line so it was set to ignore. It had no effect.
I notice that there is another parameter LidSwitchIgnoreInhibited. That is set to yes.
What is the function of that parameter, do you know?
Thanks...
AND I CONCUR: Please correct this bug...

[Shadrin Ilya (ishadrin)]

The problem is that laptop go to suspend during boot because lid is closed. The behavior is actually highly depends on the hardware you use. It works for me with Lenovo Thinkpad P52 + Lenovo Thinkpad Thunderbolt 3 Gen2 dock station.

Here is my full logind.conf:

#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192

Here is the ways i found to deal with that:

1) Play with logind.conf params (https://www.freedesktop.org/software/systemd/man/logind.conf.html - manual for configuration)

2) Use gnome-tweaks to disable suspend on lid closed (it actually creates ~/.config/autostart/ignore-lid-switch-tweak.desktop to achieve this) - does nothing for me

3) There is an option (which i use in combination with logind.conf) in Lenovo BIOS to use external docked monitor as main screen during boot - check if there is similar option in your BIOS.

Please, let us know if you will find a solution for your hardware

[Tim Wetzel (twetzel21)]

Two points
-Have not been able to find a combination of logind parameters that avoids this issue.
-Have also found that this problem is not limited to HDMI connection. It has also now appeared on a T480 in UltraDock using DP++ connection to external display. Again, the external display is the primary (only) monitor in use: laptop is docked, lid down, and uses external wireless Lenovo keyboard and mouse. On power up, after entering Ubuntu password, the system suspends....

Please fix this!!! This has been an issue ever since the Ubuntu 20.04 updates September 2020!!!