Boot animation never finishes, especially when external monitors (or just more than one) are connected

boot.log could not be attached by the report tool, I added it manualy

I installed 20.04 beta on a usb drive on the same machine, and reinstalled packages to resemble my main install as closely as possible. The bug does not occur when booting from the usb drive.
The most significant difference I can think of is that the main install is on an lvm partition (unencrypted).

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

I'm having the same problem on a Lenovo T430. If I boot the laptop on its own, it boots fine. If it's on the dock, which has two external monitors attached to it, it boots until it gets to the Ubuntu splash screen with the spinning propeller tips and never passes that point. I've left it on overnight and it never completes booting to the desktop.

If I boot it on it's own, sign in to the desktop, and then dock it, both external monitors are recognized and opening/closing the lid toggles the multiple pane layouts as expected.

Like Tim, I can get it to fully boot on the dock with multiple monitors by updating /etc/default/grub to GRUB_CMDLINE_LINUX_DEFAULT="".

I have been investigating other bug reports. I can't find anything that helps my very much, but I did note references to timing. It is very puzzling why I don't have problems when booting from the installation to an external drive. That drive is actually a USB stick (ext4 formatted). My internal ssd uses lvm, the stick not, but the stick is also much slower, just in case that is relevant.

I have been trying to work out how to log a failed session with plymouth debug messages. I finally succeeded, it is attached.
Note that at the end of log file, it goes into suspend. That was me trying to power off the machine, and not holding the button long enough. It actually suspends and resume right back to the stuck plymouth display, but I don't know any way out except to force the machine off.

Thank you for your bug report. Which journal correspond to an hanging boot?
When the boot hang can you press 'escape' on the keyboard? Does it dismiss the splash? is there any useful informaiton on the text buffer?

Hi Sebastien,
my most recent attachment #11 is from a failed boot.
When it gets stuck, I get no keyboard response from Esc, ctrl-C. I don't think it is possible to log in to virtual terminals at this point in the boot, but if I try, I can get to a blank screen, which after a few seconds jumps back to the boot splash (stuck with the spinning ubuntu logo).
There is a burst of CPU fan soon after it gets into this phase, then it stops.
Also, it will suspend and resume quite well (of course, resuming back to the same screen).

I tried a linux kernel parameter to enable a systemd emergency console, but I could not access that either.

PS there is no text at all, the process gets as far as the spinning icon and stops. I don't see the fsck check start.

I'm having the same problem on a Lenovo Thinkpad X1 3rd gen. On its own it boots just fine, with two external monitors it never passes the splash screen. However, the external monitors can be used without any problems after booting the laptop on its own.

I have the same issue afaics (plymouth get's stuck when docked).
plymouth splash can't be dismissed with ESC.

I installed openssh-server and the system is perfectly accessible remote. Didn't have time yet to further debug this, as I only have a smartphone as second device, so debugging via SSH is a bit cumbersome.

Ok, I need to take that back. It also just happened to me when undocked (i.e. no external monitor).
Just appears to happen less often.

Steps to reproduce
This result was consistent after five different installs.

Outcome
I'm having the same issue, after install I shut down remove the usb it will boot the first time to login screen no problem, after a second shut down or restart it hangs at the spinning arrow.

Expected Outcome
Smooth start up with boot splash to login screen.

Workaround
Tap the F8 key before boot splash appears, continue to tap F8 when scrolling text appears, it then continues to login screen.

Temporary Fix
Remove "quiet splash" from /etc/default/grub - GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Result
Scrolling text on startup, however a very quick boot to login screen, no hanging.

System info taken from gnome-initial-setup
{
  "Version": "20.04",
  "BIOS": {
    "Vendor": "American Megatrends Inc.",
    "Version": "KYSKLi70.86A.0037.2016.0603.1032"
  },
  "CPU": {
    "OpMode": "32-bit, 64-bit",
    "CPUs": "8",
    "Threads": "2",
    "Cores": "4",
    "Sockets": "1",
    "Vendor": "GenuineIntel",
    "Family": "6",
    "Model": "94",
    "Stepping": "3",
    "Name": "Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz",
    "Virtualization": "VT-x"
  },
  "Arch": "amd64",
  "GPU": [
    {
      "Vendor": "8086",
      "Model": "193b"
    }
  ],
  "RAM": 32.8,
  "Partitions": [
    230.5,
    0.5
  ],
  "Screens": [
    {
      "Size": "509mmx286mm",
      "Resolution": "1920x1080",
      "Frequency": "60.00"
    },
    {
      "Size": "477mmx268mm",
      "Resolution": "1920x1080",
      "Frequency": "60.00"
    }
  ],
  "Autologin": false,
  "LivePatch": false,
  "Session": {
    "DE": "ubuntu:GNOME",
    "Name": "ubuntu",
    "Type": "x11"
  },
  "Language": "en_AU",
  "Timezone": "Australia/Perth",
  "Install": {
    "Media": "Ubuntu 20.04 LTS \"Focal Fossa\" - Release amd64 (20200423)",
    "Type": "GTK",
    "OEM": false,
    "PartitionMethod": "manual",
    "DownloadUpdates": true,
    "Language": "en",
    "Minimal": false,
    "RestrictedAddons": true,
    "Stages": {
      "0": "language",
      "10": "console_setup",
      "13": "prepare",
      "22": "partman",
      "34": "partman",
      "35": "partman",
      "50": "partman",
      "51": "partman",
      "67": "partman",
      "106": "partman",
      "110": "start_install",
      "124": "timezone",
      "181": "usersetup",
      "204": "user_done",
      "409": "done"
    }
  }
}

root@pluto:~# systemctl list-jobs
JOB UNIT TYPE STATE
126 systemd-update-utmp-runlevel.service start waiting
33 setvtrgb.service start waiting
1 graphical.target start waiting
135 plymouth-quit-wait.service start running
116 system-getty.slice start waiting
2 multi-user.target start waiting

6 jobs listed.
root@pluto:~# systemctl status plymouth-quit-wait.service
● plymouth-quit-wait.service - Hold until boot process finishes up
     Loaded: loaded (/lib/systemd/system/plymouth-quit-wait.service; static; vendor preset: enabled)
     Active: activating (start) since Sun 2020-05-03 18:34:06 CEST; 38min ago
   Main PID: 721 (plymouth)
      Tasks: 1 (limit: 19009)
     Memory: 296.0K
     CGroup: /system.slice/plymouth-quit-wait.service
             └─721 /bin/plymouth --wait

Mai 03 18:34:06 pluto systemd[1]: Starting Hold until boot process finishes up...

Killing the plymouthd process and restarting gdm3 makes the boot complete successfully.

It seems to be the same problem here with ThinkPad X1 Carbon (2017 version with integrated Intel HD Graphics 620).

Booting with external monitor attached to the HDMI port systematically makes the boot hangs atfer grub boot menu.

To get out of this, I have to press the power button for a long time, and then I can boot again with the external cable unplugged. Once the graphical password prompt is shown, I can plug the external monitor again without ayn further problem.

I tested this today, and with HDMI connection, I no longer have the problem.

OK then, this bug can expire after 60 days unless anyone says they still experience it.

Same error here using a Lenovo Yoga X1 3rd with fully updated Ubuntu 20.04 (focal). I can confirm the problem is not fixed yet.

Removing "quiet splash" seems to work and also observed (when I was trying to debug this) that pressing Esc key in early boot stages to avoid splash screen and see the boot logs also workarounds this incredibly annoying bug too.

Still having this issue on a Dell OptiPlex 9020, with 2 monitors connected using DisplayPort > DVI adapters. Not sure if that's contributing to the issue though.

Computer boots fine when 1 screen is connected, hangs on the ubuntu splash screen when a cold boot is performed, however curiously boots fine with both screens connected when performing a warm boot.

Sounds like this is one of those cases where the bug should stay open even though the original reporter no longer has the problem.

Someone experiencing the problem (and for whom removing "splash" works) please report the bug to:

  https://gitlab.freedesktop.org/groups/plymouth/-/issues

and then tell us the new issue ID.

I'm having this problem on lenovo laptop - and more worryingly on a lenovo mini desktop (m93p).

removing quiet splash from grub seems to cure the issue on the desktop at least - have not tried the laptop yet.

Graeme

Someone experiencing the problem (and for whom removing "splash" works) please report the bug to:

  https://gitlab.freedesktop.org/groups/plymouth/-/issues

and then tell us the new issue ID.

Still experiencing the problem. I submitted a report at the plymouth project.

https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/118

- Boot with spask hangs when connected to external monitors (thinkpad t480)

Please tell us if this also works around the problem:

1. Edit /etc/gdm3/custom.conf and uncomment:

   #WaylandEnable=false

   so it is now:

   WaylandEnable=false

2. Reboot.

Symptom persists also with WaylandEnable=false in /etc/gdm3/custom.conf

Hello,
It worked for me!
Thanks
Alberto

On Tue, Jul 28, 2020 at 3:55 AM Daniel van Vugt <email address hidden>
wrote:

> Please tell us if this also works around the problem:
>
> 1. Edit /etc/gdm3/custom.conf and uncomment:
>
> #WaylandEnable=false
>
> so it is now:
>
> WaylandEnable=false
>
> 2. Reboot.
>
>
> ** Also affects: gdm3 (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Also affects: mutter (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Changed in: plymouth (Ubuntu)
> Status: Triaged => Confirmed
>
> ** Changed in: mutter (Ubuntu)
> Importance: Undecided => High
>
> ** Changed in: gdm3 (Ubuntu)
> Importance: Undecided => High
>
> ** Changed in: gdm3 (Ubuntu)
> Status: New => Confirmed
>
> ** Changed in: mutter (Ubuntu)
> Status: New => Confirmed
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1874194).
> https://bugs.launchpad.net/bugs/1872159
>
> Title:
> booting with splash hangs when external monitors are connected
>
> Status in Plymouth:
> Unknown
> Status in gdm3 package in Ubuntu:
> Confirmed
> Status in mutter package in Ubuntu:
> Confirmed
> Status in plymouth package in Ubuntu:
> Confirmed
>
> Bug description:
> I think this is a problem with the splash boot loader. This problem is
> not reproduced if using nosplash.
>
> I have installed 20.04 to this laptop. Thinkpad T480, i7, intel
> graphics.
>
> Clean install of 20.04 beta, not an upgrade.
> When booting from the install, the greeter screen is never reached if
> external monitors are connected at startup.
> I get the spinning ubuntu logo, and nothing more. I can not change to
> virtual terminals. The fsck step does not commence.
>
> In recovery mood, I can log in.
>
> With no external monitors attached, it works.
>
> I am used to having such problems with Nvidia graphics is involved,
> but this is not the case on this laptop. It has been happily running
> 18.04.
>
> External displays are recognised if they are connected after login.
>
> Also, when I edit /etc/default/grub so that it reads
> GRUB_CMDLINE_LINUX_DEFAULT=""
> (that is, splash disabled)
> it works fine with two external monitors attached.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 20.04
> Package: xorg 1:7.7+19ubuntu14
> ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
> Uname: Linux 5.4.0-21-generic x86_64
> ApportVersion: 2.20.11-0ubuntu26
> Architecture: amd64
> BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
> CasperMD5CheckResult: skip
> CompositorRunning: None
> CurrentDesktop: ubuntu:GNOME
> Date: Sat Apr 11 13:58:19 2020
> DistUpgraded: Fresh install
> DistroCodename: focal
> DistroVariant: ubuntu
> DkmsStatus:
> acpi-call, 1.1.0, 5.4.0-21-generic, x86_64: installed
> tp_smapi, 0.43, 5.4.0-21-generic, x86_64: installed
> ExtraDebuggingInterest: Yes, including running git bisection searches
> GraphicsCard:
> Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00
> [VGA controller])
> Subsystem: Lenovo UHD Graphics 620 [17aa:225d]
> Installatio...

Great! But that does probably mean different people are experiencing different bugs here. I would be curious to hear what more people say about comment #31...

Symptom persists also with WaylandEnable=false in /etc/gdm3/custom.conf
Removing "splash" in /etc/default/grub solves the problem (as stated before)

Computer: DELL Notebook Precision 7520

I am seeing this issue and neither of the proposed fixes to /etc/default/grub or /etc/gdm3/custom.conf work. I have only one monitor plugged in to the integrated graphic port of a Dell Precision 3630. Pressing esc while frozen shows that “A start job is running for Hold until boot process finishes up (Xmin Xs / no limit)

^^^
That's bug 1871641

This bug recurred with the last two 20.04 Updater packages, starting mid-September. The initramfs upacking bug 1835660 recurred about the same time. Turning off the Ubuntu splash screen seems to avoid the problem, but when it doesn't (or until you realize that you have to make that change); the spinning logo hang forces a hard power down which seems to cause other problems and affects general stability.

Daniel, could you add this one to your backlog?

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

I filed bug #1888695, is it also a duplicate?

In my experience, the bug occurs when a ThinkPad is in its Ultra Dock and is run, lid closed, using external display, keyboard, and mouse. Bug #1888695 refers to a direct connection of an external monitor to the laptop's own HDMI port. Thus the configuration is not the same. The cause may be related or identical; or they might be separate issues?

Could people having the issue add a comment and debug log on the gitlab upstream report?

Sebastien, I'm new to Ubuntu so I may not be looking in the right place... but I couldn't find much in the logs. There was no crash, no error, just... nothing. Only option was a forced power down. I could find the point where I restarted it in the logs, but nothing else seemed remarkable. And that is all gone now since I subsequently tried to reload Ubuntu last week, which hit the installer bug.n And at the moment, that machine is sidelined...

Right now, I'm using my backup laptop, which has also been running 20.04 for a couple months. I have grub set to quiet nosplash which seems to avoid it. I'm reluctant to try to reproduce this bug because these two machines both are mission critical. Plus: and this may be important... the backup is a ThinkPad T440s: immediately after this happened and forced a hard power down, I started to get ACPI errors every startup. We're not sure whether this event corrupted the ACPI table or whether it brought out a latent bug in the T440s BIOS. I have informed Lenovo.

The other machine, the one that is sidelined, is a T570, dual boot with Win 10, Ubuntu freshly reloaded with much difficulty from the daily update copy due to bug 1871268. After getting past that installer crash issue, I was again confronted with initramfs errors (bug 1835660). Since we're not sure what this boot hang is doing to the BIOS, I turned off the splash screen hoping that I wouldn't see it. But that machine also continues to suspend on login, which seemed to be "the straw that broke the camel's back" and led me to reload Ubuntu in the first place: as it boots, as soon as you put in the login password, it suspends (bug 1897185). This combination of bugs got it unstable which is why I tried to reload Ubuntu late last week. Given all these errors, I can't really get you a "clean" test.

But I can tell you that these four bugs seem to be inter-related. All this started with the second last Ubuntu Updater packet in mid-September, and got really bad with the last update packet which also included an update to the nVidia driver, which affects the T570 (the T440s is Intel graphics only). Both machines have Sierra Wireless WWAN, which does not seem to be involved. So this was all around the update to 20.04.1.

Don't know if this helps but I hope so...

Somehow I missed comment #39 and at the same time wondered why this bug had not received any attention. :)

Yes, I can reproduce this bug on my groovy desktop so I will be happy to look at it.

Ubuntu 20.04 on Lenovo T480s. This problem has appeared only in the last week. I've been running 20.04 since May and had never seen this problem before.

Boot hangs on Ubuntu spinning splash with HDMI directly connected for 2nd monitor. Booting without HDMI connected works fine.

- removing "splash quiet" in /etc/grub/default does NOT avoid problem.
- changing /etc/gdm3/custom.conf as in #31 above does NOT avoid the problem.

- switching from gdm3 to either sddm or lightdm avoids the problem.

Well, that answers something I've wondered: this DOES affect the T480 (full Thunderbolt) chipset. I've seen it on T570; I've seen it reported on T470; and I've also seen it on T440s. Again, this is one of FOUR serious bugs that I've seen pop up since the Ubuntu updates starting around September 12 or 13. (See the other 3 bug numbers in post 45 above.)

Note that the subsequent update (around Sept 22 or 23) included grub updates AND *nvidia driver* updates. These issues seem to be inter-related perhaps....

I really hope that this gets cleaned up soon; it's been about 2 weeks already that I've had a machine down and another seriously affected.

I ran into this problem with a new install of 20.04 on a Dell Optiplex 5060.
This system has integrated Display Ports. Hangs at boot with Ubuntu spinning for hours.
My configuration has a single monitor attached via Display port/HDMI cable and DVI adapter to monitor DVI input.

Two workarounds mentioned here worked for me:
1) boot with monitor cable unplugged and then plug cable in to see login screen
2) remove "splash quiet" in /etc/default/grub, then boot to login screen

Thanks James. My configuration is different: the laptops in question are in mechanical docks. The laptop remains closed (lid down); external display is connected to the dock via HDMI, external keyboard and mouse are also connected to the dock via USB dongle in the dock. So I can't start them and then plug in the monitor very well: the external display has to be primary.

I've also had this spinning logo and the forced powerdown that it forced result in ACPI errors on the subsequent boots and shutdowns. We're not sure whether this bug corrupted the ACPI table, or whether turning off the splash screen exposed a latent bug in the BIOS. This is on a T440s.

I have changed splash quiet to splash noquiet and that -- so far -- avoids this hang with the spinning logo; but then I get the laptop going into suspend as soon as the login password is entered. I'm not sure whether the two bugs are related in terms of cause or not.

At first, I tried to just restart the docked machine to resume out of suspend; but over a period of days Ubuntu became unstable. So I tried to reload Ubuntu, and encountered the bug where the installer now crashes when the third-party driver option is selected. I need that for nvidia and sierra wireless hardware. Result is that machine is now sidelined, with numerous failed reinstallation attempts.

I'm using a backup machine (which does NOT have any nvidia). I have grub changed to nosplash. But I'm still getting the suspend on login problem... so I'm just hoping that the developers get these bugs fixed before the second machine goes down. Again, bug numbers for the other 3 items are in post 45 above.

We've got a T480 also, but it uses an external display connected to the dock via DVI AND the laptop is run open with its own internal display as primary. I'm hoping that I won't see problems there. So far so good with that configuration, knock on wood...

It would probably be useful if those having the issue would create a report upstream on https://gitlab.freedesktop.org/plymouth/plymouth/issues . We have no assigned maintainer for that package and limited capacity for debugging at the moment so upstream is more likely to lead to an active discussion

OK: I created a login at Plymouth and added comments to "bump" their bug:
Booting hangs when external monitors are connected

Also noted the seriousness of this and the question of whether it has corrupted T440s BIOS.

I will keep my comments in the upstream bug for now:

https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/118

I noted this new comment:
"I am used to having such problems with Nvidia graphics is involved,
  but this is not the case on this laptop. It has been happily running
  18.04."

In my case, I'm seeing this on machines that have been running *LTS 20.04* just fine UNTIL the updates to 20.04.1 started to roll out around September 12 or so. That's when the problems started. I started seeing this spinning logo hang in mid-September along with the initramfs errors on startup.

Shortly after, I started seeing bug 1897185 (and other bug numbers as well) where the machine(s) go into suspend as soon as the login password is entered during startup. When I subsequently tried to reinstall Ubuntu, I encountered 1871268 and could not complete the reinstall.

I have since managed to get around the install with third party drivers bug; but still encountered the initramfs problem, the spinning logo splash hangs, and the suspend after login password error... so these problems are pretty severe.

Just thought you'd like to know that my experience with this problem occurred on machines that were running LTS 20.04 just fine until Ubuntu Updates mid-September.

I now know enough to be sure it's a plymouth bug, not gdm:

https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/118#note_668662

Update as posted upstream at Plymouth:

Daniel, THANK YOU! I have applied Ubuntu Updates to the affected machines here, and then turned the splash screen back on. Knock on wood, the issue isn't happening any more.
Also: another bug is gone also, it seems: Ubuntu #1897185 regarding suspend during startup after entering the login password. This was occurring at approximately the same point in startup (anecdotal observation) as the spinning logo. I'm wondering if they were/are related?
Again, thank you!

No update has been released yet. The fix is currently only in future plymouth version:

  0.9.5-0ubuntu3

I've opened https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/130 upstream about the timeout patch now, it doesn't sound like something we should have a distro patch

I've uploaded to H and G serie.

Daniel do you think we should upload to focal now or wait for feedback from those updates first?

ASAP I think. It looks like we have plenty of people who could verify a focal fix quickly.

Hello Tim, or anyone else affected,

Accepted plymouth into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/plymouth/0.9.5-0ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Brian, thanks for the heads up and the links to the docs on how to test... I'll look into this later today then and post back. Thanks.

Brian, my systems pull from focal. I turned on the developer option and looked at what's available: plymouth isn't there. According to dpkg, the system still has the 9.4 version from 20200323 installed. Should 9.5 be available; is it not there yet; or am I looking in the wrong place? Thanks.

The proposed fix is only in groovy-proposed for now.

That's what I was afraid of. Guys: please address this. Isn't the whole point of LTS that stuff like this isn't supposed to happen? All 4 of the bugs I've been fighting for the past 6 weeks or so have hit LTS 20.04.1 *hard*. The initramfs, the spinning logo hang, then the suspend at login password... and when all that compromised stability, I couldn't even reload because of the third party driver crash issue. I'm still trying to work around the initramfs, spinning logo, and suspend at login bugs and these problems are affecting 2 of the 3 Ubuntu machines here -- all LTS. So as soon as you have this fix for focal, I'll be glad to test. I would think that there'd be a scramble to deal with major bugs like this in the LTS distro? LTS 20.04 was truckin' along just fine until the updates starting the middle of September. Thanks.

Any fix has to go first to the development release, the latest release then the LTS release.

All autopkgtests for the newly accepted plymouth (0.9.5-0ubuntu2.1) for groovy have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/246.6-1ubuntu1 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/groovy/update_excuses.html#plymouth

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

^^^
Is that failure reproducible? And if so, would it not be more related to the fix for bug 1880250?

Verified fixed in version 0.9.5-0ubuntu2.1 on groovy.

Before the fix it only took 2 reboots to hang. With the fix I was able to reboot 10 times and it never hung. I stopped trying after that.

So my main LTS 20.04.1 system just provided some Ubuntu Updates, mainly the boot animation plymouth package. But it still shows in dpkg as 0.9.4git20200323 although it incremented to 6.1. Does this address this issue? I'm new to all this, so trying to make sure I don't test the wrong thing.

No, the fix is still neither in focal-proposed nor focal-updates.
We will get a message like comment #61 above when the fix is in focal-proposed.

the autopkgtest failure seems to have resolved on a retry

We have a new client that is stuck on splash after having :

- completed the oem-config welcome
- used the computer
- reboot

But he never had any external monitor connected so sometimes it can happened without.

He could reproduce the problem more than 10 reboots!

Yes this bug can occur with a single monitor. Although nobody had reported that yet, it became apparent it could happen in theory when I found the root cause of the bug.

This bug was fixed in the package plymouth - 0.9.5-0ubuntu3

---------------
plymouth (0.9.5-0ubuntu3) hirsute; urgency=medium

  * debian/patches/git_screens_resolution.patch:
    - don't limit the resolution to the lower screen one
  * debian/patches/git_set_translations.patch:
    - do the setlocale configuration even when there is no initrd, fixes
      the translations not showing up when testing in a session

  [ Daniel van Vugt ]
  * debian/patches/timeout-for-ping.patch: Raise the ping timeout from 2 to
    30 seconds. Two seconds was way too short,
    - causing ping to randomly fail on some busy multi-monitor start-ups,
    - causing gdm to think no plymouthd is running,
    - causing gdm to never call 'plymouth deactivate',
    - causing plymouthd to retain ownership of the graphics hardware,
    - causing gdm's login screen to fail to start. (LP: #1872159)

 -- Sebastien Bacher <email address hidden> Mon, 26 Oct 2020 13:16:03 +0100

Here's the same fix for focal. It's not tested yet because I don't have multi-monitor focal right now but there are plenty of people here who can verify it, when built...

Daniel, with reference to post 76 above, yes: all of my configurations involved with this have one external HDMI display. The laptops run docked, lid down, with the external display as primary. The dock also provides external keyboard and mouse. I've seen it with external displays from less than 1920x1080 up through 3440x1440 when connected via HDMI. So my experience confirms your finding.

I've experienced this on a ThinkPad with single display (the inbuilt one) only, and a Dell desktop with two displays.

Lenovo X1 Carbon - Ubuntu 20.04
While HDMI connected it was stuck for long time. Had to hard restart removing HDMI cable.

This bug was fixed in the package plymouth - 0.9.5-0ubuntu2.1

---------------
plymouth (0.9.5-0ubuntu2.1) groovy; urgency=medium

  * debian/patches/timeout-for-ping.patch: Raise the ping timeout from 2 to
    30 seconds. Two seconds was way too short,
    - causing ping to randomly fail on some busy multi-monitor start-ups,
    - causing gdm to think no plymouthd is running,
    - causing gdm to never call 'plymouth deactivate',
    - causing plymouthd to retain ownership of the graphics hardware,
    - causing gdm's login screen to fail to start. (LP: #1872159)

 -- Daniel van Vugt <email address hidden> Wed, 21 Oct 2020 18:47:21 +0800

The verification of the Stable Release Update for plymouth has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Hello Tim, or anyone else affected,

Accepted plymouth into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/plymouth/0.9.4git20200323-0ubuntu6.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Brian and Daniel,
So far so good.
I applied this to 2 affected systems using the gui and selecting just the plymouth related items from the proposed available modules. There were 5: 2 each in software and base; and a shared library in the software (first) section.
The problem had most reliably exhibited on the T570 with nVidia graphics. I have restarted that system after applying the plymouth update; turned the splash screen back on in grub customizer; and restarted again. Then I've done 3 more shutdown and restart cycles, all in the dock with external HDMI display as primary (laptop is docked, lid down, as before). Knock on wood, no issues...
I'll keep watching and report if any issues occur.
Thanks,
Tim

Just a reminder; anyone verifying the above fix for 20.04, please also mention the exact version of plymouth you have installed. It should be the same as the version mentioned in comment #84.

Sorry; I thought my post #85 was obvious in being a response to post #84. But to verify: the plymouth package pulled from proposed was
0.9.4git20200323-0ubuntu6.2
and still so far so good.
All "normal" Ubuntu 20.04.1 Updates were up-to-date prior to pulling this from proposed.
Thanks,
Tim

I can confirm that after applying the update I do not get stuck any more on the splash screen with an external monitor attached and GRUB_CMDLINE_LINUX_DEFAULT="quiet splash".

Ubuntu 20.04.1 LTS
plymouth: 0.9.4git20200323-0ubuntu6.2

Hello , what is next to have 0.9.4git20200323-0ubuntu6.2 in -updates ?

Several clients ( without external monitors) called for this problem

BTW : it should be easier to jump to Grub without failing on Grub shell ....

Because an update to a long term release potentially affects millions of users, it needs to be done slowly and carefully...

> Packages in -proposed can be moved to -updates once they are
> approved by someone from sru-verification, and have passed the
> minimum aging period of 7 days.

[https://wiki.ubuntu.com/StableReleaseUpdates]

So it should qualify for -updates in the next 1 or 2 days.

This bug was fixed in the package plymouth - 0.9.4git20200323-0ubuntu6.2

---------------
plymouth (0.9.4git20200323-0ubuntu6.2) focal; urgency=medium

  * debian/patches/timeout-for-ping.patch: Raise the ping timeout from 2 to
    30 seconds. Two seconds was way too short,
    - causing ping to randomly fail on some busy multi-monitor start-ups,
    - causing gdm to think no plymouthd is running,
    - causing gdm to never call 'plymouth deactivate',
    - causing plymouthd to retain ownership of the graphics hardware,
    - causing gdm's login screen to fail to start. (LP: #1872159)

 -- Daniel van Vugt <email address hidden> Mon, 02 Nov 2020 18:02:17 +0800

 Hello,
The bug is also solve for me on plymouth (0.9.5-0ubuntu2.1) groovy.
Circular animation is now displayed only in one direction before starting.

Thanks.
 Dominique

Ubuntu 20.10 with plymouth newest version (0.9.5-0ubuntu2.1) has installed on an DEXP Atlas H158 ( Core i7 6700HQ, Nvidia GeForce 940M + Intel HD 530). Removing "quiet splash" does not help me. My notebook stay with black screen forever with connected HDMI cable. Have to remove HDMI cable before every boot.

This bug is now closed so please open new bugs for any remaining issues, by running:

  ubuntu-bug plymouth

in a Terminal window.