Leap 15 Spash Screen - What's it doing?

Hi,

During logon on my system (Leap 15, KDE 5.13.6, Kernel 4.12.14…), I get to the bouncing logo after about 5 seconds.
I then have to wait for about 180 seconds while the (white) diamond bounces above the chevron.
Eventually, it stops bouncing turns green and the text “Leap 15” is displayed momentarily before the screen clears and we move on.

My question is: what is happening (or more likely not happening) during this time?
I have scanned the boot log (journelctl -bx > boot.txt) and can’t see evidence of what may be going on during the splash screens bouncing display.

If I remove the Splash= kernel parameters from the Grub setting, the splash screen is not displayed (of course) and I’m logged in in second (<10 seconds).
Is the bouncing box just for our entertainment?

Regards, Martin

Have you hit the Esc key to see what happens?

Yep… Tried that.

Nothing happens!

on my desktop hitting F1 or F2 shows what’s going on behind the scenes haven’t really tried esc

Ah… Both F1 and F2 will restore to boot log output to the screen. Thank you.

Extended boot times seem to be related to network? Will need to do some more poking about now that I have a clue of where to look.
But why would displaying a splash screen cause a problem configuring network interfaces? Race hazards?

Regards, Martin

15 has a bug in wicked

edit the file
" /etc/sysconfig/network/config"

and change ( should be line 94 )



WAIT_FOR_INTERFACES="30"

---- to this ----

WAIT_FOR_INTERFACES="1"


then reboot

There are several systemd services which are occasionally executing during boot and cause significant delays:

  • The “fstrim.service” – needs to be enabled only if you have an SSD with non-Btrfs partitioning (e.g. ext4) – it’s triggered by the “fstrim.timer” service which by default expires once a week …
  • The Btrfs and Snapper maintenance services which are triggered at various intervals on Btrfs partitions depending on the particular maintenance to be done: daily, weekly, monthly …
  • The “backup-rpmdb.service” – this runs during the boot whenever the RPM Database has been changed by patches and/or updates …

In addition, there are one or two issues with Plymouth – the boot splash which displays the “bouncing chevron” …

For systems being initialised by “systemd”, the amount of time taken by bits and pieces of the boot process can be examined by means of “systemd-analyze” – this application has several commands which can be used to examine the boot process in detail …

AFAICS, the correct way to disable Plymouth is to add “plymouth.enable=0” to GRUB2’s kernel parameters – see the man page “dracut.cmdline(7)” …

And, AFAICS, “splash=” is in the same class as the “showopts” kernel parameter: it seems to be no longer applicable for Leap 15.0 …

You can also consider the kernel parameter “quiet” – see the man pages “kernel-command-line(7)” and “systemd(1)” …

It’s “Plymouth” which, depending on your point of view, could be viewed as a source of entertainment …
Despite raising a couple of Change Requests ( “Bug Reports” for most people … ) with respect to the interaction between systemd and Plymouth, I’m now resigned to disabling Plymouth as I’ve described above but, with the caveat that, the following actions also, IMHO, need to be taken …


# From the directory '/usr/lib/systemd/system/':
x:..systemd/system # unlink ./sysinit.target.wants/plymouth-read-write.service
x:..systemd/system # unlink ./sysinit.target.wants/plymouth-start.service
x:..systemd/system # unlink ./kexec.target.wants/plymouth-kexec.service
x:..systemd/system # unlink ./reboot.target.wants/plymouth-reboot.service
x:..systemd/system # unlink ./halt.target.wants/plymouth-halt.service
x:..systemd/system # unlink ./poweroff.target.wants/plymouth-poweroff.service
x:..systemd/system # unlink ./initrd-switch-root.target.wants/plymouth-switch-root.service
x:..systemd/system # unlink ./multi-user.target.wants/plymouth-quit-wait.service
x:..systemd/system # unlink ./multi-user.target.wants/plymouth-quit.service

I simply remove Plymouth and taboo it. I prefer the scrolling lines at boot.

In the process of restoring the Plymouth boot splash because of the need to respond to a “needinfo requested:” Bug Report, I’ve noticed that “splash=silent” and “showopts” are needed if the Plymouth boot splash is to be displayed – if only “plymouth.enable=0” is removed from the GRUB2 kernel parameters list, the Plymouth boot splash doesn’t appear …

This goes a bit off-topic, i.e. plymouth is not the culprit here. To find what causes delay during boot:


systemd-analyze blame 

Please post the output here, between CODE tags

A bit, maybe, but then I am not so sure.

i.e. plymouth is not the culprit here.

I wouldn’t be that surprised if removing and tabooing plymouth makes the problem disappear.

It was: see Bug 1110199 – there’s a «flag associated with the framing of the “throbber”» issue which was causing the “Plymouth quit” to misbehave, loop indeterminately, and perform other evil behaviour …