disable plymouth

English Install/Boot/Login
#1

On my Tumbleweed/KDE laptop the boot time was quite fast but over the time the boot time lengthened. The command systemd-analyze blame showed in the first place plymouth-quit-wait.service. I thought I can disable plymouth during boot. In YAST > Bootloader under the kernel paramerters was nothing with plymouth (I remeber there used to be plymouth=silent or something similar) but there was splash=silent. I changed this to splash=0. Now during boot the splash screen has disappeared but I still get

systemd-analyze blame          
         17.258s plymouth-quit-wait.service
         17.028s chrony-wait.service
           749ms display-manager.service
           577ms apparmor.service
           469ms initrd-switch-root.service
           455ms firewalld.service
           301ms systemd-logind.service
           271ms systemd-udevd.service
           183ms systemd-journald.service
           156ms systemd-localed.service
           119ms rsyslog.service
           109ms kbdsettings.service
           108ms mcelog.service
           107ms issue-generator.service
           100ms lm_sensors.service
            96ms avahi-daemon.service
            92ms user@464.service
            90ms nscd.service
            90ms initrd-parse-etc.service
            85ms smartd.service
            80ms systemd-vconsole-setup.service
            76ms upower.service
            63ms polkit.service
            60ms systemd-udev-trigger.service
            57ms udisks2.service
            53ms dev-disk-by\x2duuid-04950094\x2dcd8e\x2d421f\x2db63d\x2d7ba755b17b67.swap
            44ms geoclue.service
            43ms user@1000.service
            40ms systemd-fsck@dev-disk-by\x2duuid-522f4f33\x2d5c84\x2d4ecd\x2d9679\x2d915966952c13.service
            37ms systemd-fsck-root.service
            36ms NetworkManager.service
            32ms dracut-cmdline.service

How can I disable plymouth completely? Any other ideas to speed up the boot time?

#2

You can use “plymouth.enable=0”.

It might not help with the boot time.

I usually remove that “splash=silent”, and your “splash=0” probably has the same effect. I think that speeds up booting a little, but not very much. The slowness is probably due to all of the other things going on at the same time as plymouth.

#3

It’s probably the chrony-wait.service.

chrony-wait.service is disabled by default and should only be used on machines running services that strictly require synchronized time and have a permanent network connection.

https://bugzilla.suse.com/show_bug.cgi?id=1145193

It’s getting unexpectedly enabled for various reasons.

You can disable it with:

systemctl disable chrony-wait.service

For more detailed boot information:


systemd-analyze plot > boot.svg
display boot.svg

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.systemd.html#sec.boot.systemd.debug.time

#4

Thanks you, nrickert and ravas, I have changed the kernel parameter to plymouth.enable=0 and disabled chrony-wait.service. I need the computer right now but I will check the boot time later and come back if there are still problems.

#5

Parameter splash=0 equates to default configuration, “”. IOW, splash is an option, so omitting it altogether should produce the fastest non-splash boot, if only by microseconds or less.

Uninstalling plymouth shrinks the initrd size and thus load time and boot time, also what I do. Including plymouth.enable=0 is a good way to determine whether you need it, or even like not having it enabled. I’ve never found value in having boot progress hidden from view by silly graphics wasting energy, reminding me what a putz is Windows.

#6

Thank you mrmazda for clarifying this. After removing all those plymouth files - do I need to taboo them that the next update is not installing them again?

#7

I’m not sure. It’s possible some or all are recommended by something you might someday install. I have

sudo zypper al plymout*

preventing its/their appearance.

#8

If your display manager starts failing to load, you’ll know it’s because you uninstalled plymouth.

https://bugzilla.suse.com/show_bug.cgi?id=1137433

https://bugzilla.suse.com/show_bug.cgi?id=1148242

I reinstalled it and just use “plymouth.enable=0” now.

To satisfy my curiosity, can someone on Leap copy and paste the output of

systemctl cat display-manager.service
#9

Speaking of disabling Plymouth in various ways — I’ve recently tried to list all the things I did to improve boot speeds, some harmless, some quite aggressive.

For example, I told dracut to always build initrd images tailored for my system and to omit things I don’t need during boot — like, for example, network (which systemd-networkd will configure later anyway), server stuff like cifs/fcoe/rdma/multipath/iscsi/mdraid/dmraid, and stuff I personally never use: like cdrom, plymouth, btrfs, wacom, wicked, ipv6 etc. I also told it to not compress those initrd images which can make quite a difference if you boot from SSD.

During the years, I zeroed in on a boot/shutdown process that is fast, minimalistic and quiet and, because of that, is easier to reason about and to easily spot any differences in behaviour from update to update.

After I posted my little list linked above, I’ve remembered using even some dirtier tricks to minimize »noise« during boots, for example to do away with those regressive (but otherwise harmless) vconsole error messages:

# cp /usr/bin/true /usr/lib/systemd/systemd-vconsole-setup
# dracut --hostonly --force --no-compress --omit "cdrom pollcdrom btrfs plymouth *[etc, etc, your mileage may vary]*"

After reboot, I still had my text console whenever I needed it, just not configured in any way (US kbd, 80x25), which I don’t mind.

The reason I consider this »dirty« is because I clobber a systemd binary into returning »no error«, and because this hack may need to be re-applied whenever there’s been a systemd update. Compared to that, most other optimizations are permanent and play well with the openSUSE ecosystem, as should disabling Plymouth.

#10

https://bugzilla.opensuse.org/show_bug.cgi?id=1137433 for opensuse users.

https://bugzilla.suse.com/show_bug.cgi?id=1148242
https://bugzilla.opensuse.org/show_bug.cgi?id=1148242 for opensuse users.

I reinstalled it and just use “plymouth.enable=0” now.

To satisfy my curiosity, can someone on Leap copy and paste the output of

systemctl cat display-manager.service

## leap 15.1
# systemctl cat display-manager.service
# /usr/lib/systemd/system/display-manager.service
[Unit]
Description=X Display Manager
Requires=var-run.mount
Conflicts=getty@tty7.service plymouth-quit.service
After=ypbind.service gpm.service time-sync.target winbind.service acpid.service
Wants=remote-fs.target dbus.socket systemd-user-sessions.service systemd-logind.service
After=remote-fs.target dbus.socket systemd-user-sessions.service systemd-logind.service getty@tty7.service plymouth-quit.service
OnFailure=plymouth-quit.service

[Service]
Type=forking
PIDFile=/var/run/displaymanager.pid
ExecStart=/usr/lib/X11/display-manager start
ExecStop=/usr/lib/X11/display-manager stop
ExecReload=/usr/lib/X11/display-manager reload
KillMode=process

[Install]
WantedBy=graphical.target
Alias=xdm.service

# systemctl status graphical.target
● graphical.target - Graphical Interface
   Loaded: loaded (/usr/lib/systemd/system/graphical.target; static; vendor preset: disabled)
   Active: active since Wed 2019-09-04 03:21:52 EDT; 41s ago
     Docs: man:systemd.special(7)

Sep 04 03:21:52 big31 systemd[1]: Reached target Graphical Interface.
#11

Here you go; I’m still on Leap 15.0, mind you:

# /usr/lib/systemd/system/display-manager.service
[Unit]
Description=X Display Manager
Requires=var-run.mount
Conflicts=getty@tty7.service plymouth-quit.service
After=ypbind.service gpm.service time-sync.target winbind.service acpid.service
Wants=remote-fs.target dbus.socket systemd-user-sessions.service systemd-logind.service
After=remote-fs.target dbus.socket systemd-user-sessions.service systemd-logind.service getty@tty7.service plymouth-quit.service
OnFailure=plymouth-quit.service

[Service]
Type=forking
PIDFile=/var/run/displaymanager.pid
ExecStart=/usr/lib/X11/display-manager start
ExecStop=/usr/lib/X11/display-manager stop
ExecReload=/usr/lib/X11/display-manager reload
KillMode=process

[Install]
WantedBy=graphical.target
Alias=xdm.service

Hmm… seems those references to my nonexistent Plymouth are responsible for the last Plymouth-related message I still get once every boot:

kdm[561]: plymouth is NOT running

(I decided to stick with my tiny, unthemed kdm because it seems to have the quickest startup time and preloads all that kdelibs/qt5 stuff my KDE-Plasma5 session needs anyway.)

The journalctl command shows it as if it is a notice, not an error, that’s why I don’t notice it usually.
Sometimes I like to check for any kernel- oder driver-related errors, warnings and other oddities with

journalctl -b --no-hostname | grep -Ei '\S*( no |warn|\Werr|fail|conflict|igno|repeat|n^a-n p-z]t)\S*\s*\S*'

… a contraption that has grewn incrementally throughout the years, as other lengthy stuff in the shell history file happens to do as well. The output has even gotten nicer with that grep color-highlighting, which can be more than eye-candy. Cheers!

#12

Thanks yall. It looks like the display-manager.service has not changed.

I noticed that the coredump mentioned modesetting, nouveau and glamor, so I thought maybe reinstalling xf86-video-nouveau could help. No problems so far.

https://bugzilla.opensuse.org/attachment.cgi?id=816735

I wonder if it’s related to the update to xorg-x11-server 1.20.5
https://build.opensuse.org/request/show/706740

Thanks for the link correction mrmazda, I had not noticed >_<.

#13

@mrmazda

Is it true that you are using xf86-video-modesetting with a NVIDIA card and have purged your system of plymouth?


zypper rm xf86-video-nouveau
zypper rm -u plymouth*
dracut --force

This is the case where my display manager fails to load.
If it’s working for you, then it seemingly must be a difference in video cards (GTX 750 here) or xorg-x11-server versions.

If I install xf86-video-nouveau, then the problem is eliminated.

#14

And now I just thought about

zypper rm -u xf86-video-nouveau

The following 3 packages are going to be REMOVED:
Mesa-dri-nouveau libvdpau_nouveau xf86-video-nouveau

It looks like Mesa-dri-nouveau provides nouveau_dri.so, which is mentioned in the coredump.

#15

I didn’t get the coredump, but the display manager still failed to load. Oh well.