Plymouth slow to start from Systemd Boot

Support
1

So I set up Systemd Boot with Plymouth on a LUKS parttion. Plymouth doesn’t display anything until LUKS wants the password, it’s like 4 seconds of blank but backlit screen.

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(piix ide_disk reiserfs)
MODULES="crc32c-intel i915"

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=("/usr/bin/btrfs")

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=""

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No raid, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect block filesystems)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev block filesystems)
#
##   This setup assembles a pata mdadm array with an encrypted root FS.
##   Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
#    HOOKS=(base udev block mdadm encrypt filesystems)
#
##   This setup loads an lvm2 volume group on a usb device.
#    HOOKS=(base udev block lvm2 filesystems)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr, fsck and shutdown hooks.
HOOKS="base systemd sd-plymouth keyboard keymap sd-vconsole block sd-encrypt autodetect modconf filesystems"

# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"
#COMPRESSION="zstd"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

here’s my systemdboot

title	Manjaro Linux 5.10
linux	/vmlinuz-5.10-x86_64
initrd	/intel-ucode.img
initrd	/initramfs-5.10-x86_64.img
options	root=UUID=8e129ee4-9e55-4558-b4ea-33eb08f6b95e rw rootflags=subvol=/@ cryptdevice=UUID=d14ab16d-26ae-4dc1-933c-fa516232997c:cryptrootluks.name=d14ab16d-26ae-4dc1-933c-fa516232997c=cryptroot ro elevator=kyber rootflags=subvol=@ quiet splash apparmor=1 security=apparmor udev.log_priority=3 threadirqs

and

# config file for sdboot-manage

# kernel options to be appended to the "options" line
LINUX_OPTIONS="luks.name=d14ab16d-26ae-4dc1-933c-fa516232997c=cryptroot ro elevator=kyber rootflags=subvol=@ quiet splash apparmor=1 security=apparmor udev.log_priority=3 threadirqs"
LINUX_FALLBACK_OPTIONS="luks.name=d14ab16d-26ae-4dc1-933c-fa516232997c ro rootflags=subvol=@"

# when LINUX_USE_DEVICE_FOR_RESUME is set to "yes", the specified device will be used for hibernation
#LINUX_USE_DEVICE_FOR_RESUME=/dev/sda4
#LINUX_USE_DEVICE_FOR_RESUME=UUID=device_uuid

# when LINUX_USE_SWAP_FOR_RESUME is set to "yes", the first detected available swap device will be used for hibernation
# i.e. the "resume=UUID=swap_device" parameter would be appended to the kernel command line
#LINUX_USE_SWAP_FOR_RESUME="no"

# the DEFAULT_ENTRY option determines if and how the default entry in loader.conf should be managed
#   "latest"    The most recent Manjaro kernel will be used(the one with the highest version number)
#   "oldest"    The oldest Manjaro kernel will be used(the one with the lowest version number)
#   "manual"    Don't modify the default setting
#DEFAULT_ENTRY="latest"

# ENTRY_ROOT is a template that describes the beginning of the name for system-boot entries
# The ENTRY_ROOT will be followed by the kernel version number
# For example, if ENTRY_ROOT="manjaro" and you are using kernel 4.19 your entry will be named "manjaro4.19.conf"
#ENTRY_ROOT="manjarolinux"

# ENTRY_TITLE is a template that describes the beginning of the title of (i.e. the text displayed in the loader screen for) systemd-boot entries
# For example, if ENTRY_TITLE="Manjaro" and you are using kernel 4.19, the title of your entry will be "Manjaro Linux 4.19"
#ENTRY_TITLE="Manjaro Linux"

# when ENTRY_APPEND_KVER is set to "yes", the kernel version number will be appended to both the filename and the title of systemd-boot entries
#ENTRY_APPEND_KVER="yes"

# Use this pattern to match kernels which should be considered native OS kernels
#KERNEL_PATTERN="vmlinuz-[0-9]*-*" \

# setting REMOVE_EXISTING to "yes" will remove all your existing systemd-boot entries before building new entries
#REMOVE_EXISTING="yes"

# unless OVERWRITE_EXISTING is set to "yes" existing entries for currently installed kernels will not be touched
# this setting has no meaning if REMOVE_EXISTING is set to "yes"
#OVERWRITE_EXISTING="no"

# when REMOVE_OBSOLETE is set to "yes" entries for kernels no longer available on the system will be removed
#REMOVE_OBSOLETE="yes"

# if PRESERVE_FOREIGN is set to "yes", do not delete entries starting with $ENTRY_ROOT
#PRESERVE_FOREIGN="no"

# setting NO_AUTOUPDATE to "yes" will stop the updates to systemd-boot when systemd is updated - not recommended unless you are seperately updating systemd-boot
#NO_AUTOUPDATE="no"

# setting NO_AUTOGEN to "yes" will stop the automatic creation of entries when kernels are installed or updated
#NO_AUTOGEN="no"

# add discard option to cryptdevice parameters
#DISCARD="no"

# add discard option to boot parameters for filesystems (rootflags=discard) for continuous TRIM 
# see: https://wiki.archlinux.org/index.php/Solid_state_drive#Continuous_TRIM
#CDISCARD="no"

What can I do to get Plymouth showing at the beginning instead of a blank screen?

2

You can try to use zstd compression instead of xz.

1 Like
3

Huh, that worked. It never occurred to me that it might be kernel decompression taking so long. Especially not on my CPU. Why is that? I thought xz decompressed almost as fast as zstd (if not faster). Maybe the kernel doesn’t do parallel decompression?

4

No, xz is very slow compared to zstd, see the decompression times here :

https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029520.html

xz can decompress an archive with multithreading only if it has been compressed with multireading option.

1 Like
5

Darn good catch! :sunglasses: Makes you wonder if ZSTD should be the default for mkinitcpio moving forwards? I know it’s officially supported by Grub and Systemd-boot for vimlinuz. Some stuff to read up on. If only it wasn’t a Facebook technology. :smirk:

The real selling point here is that booting up a computer is “fleeting” and thus speed matters more than absolute archive size and efficiency. For the record, practically everything I compress and archive I use XZ “Ultra” settings with multithreading. I find it to perform just as well, if not better, than 7Z “Ultra” settings. I find ZSTD doesn’t quite compress as efficiently as XZ when the goal is the smallest archive size possible. (I use “tar” before compression if I need to preserve UIDs, GIDs, and folder modification times.)

1 Like
6

xz compress better than many, but it’s one of the slowest compressor, that’s why I create my archives in tar.zst. I prefer much better speed for a size a few percents bigger.

7

Sorry, sometimes I can’t understand a native English speaker. You said “kernel decompression”, but that setting in mkinitcpio.conf is responsible for initrd compression format. I guess you meant this anyway :upside_down_face:

Sure it should.
Currently the default format is a bottleneck in Manjaro (and maybe Arch too) booting process because of xz being too slow to unpack. I used it once just to compare the speed of booting process with another formats before zstd became available and I was disappointed with that so much that I preferred to use lzop at the time. Also checked tests carried out by several enthusiasts and that only reassured me that xz is not a good choice for such use-cases as booting a desktop system. Since 5.7 or so I switched to zstd entirely and my whole boot process is about 18-20 second now (udev initrd) or even 15 (systemd initrd). That’s with lvm and decryption, note.
There’s only one gotcha with zstd now: don’t try kernels prior to 5.10 because they will fail to decompress archives of such format and will panic.

8

That would definitely be an issue for those using the 5.4 LTS kernel.

@xenoterracide did you intentionally change the setting in mkinitcpio.conf to use XZ compression?

I just checked my system and it appears all compression methods are commented out, and thus it defaults to GZIP (supported by old kernels, and just as fast as ZSTD when booting up, and the initramfs is the same size as when I tested it with ZSTD.)

Here’s what I noticed:

Apparently my system (and all freshly installed Manjaro systems?) defaults to GZIP compression for the initramfs.

  • GZIP
    – Fast (practically immediate) decompression during boot
    – 8MB for initramfs.img
  • ZSTD
    – Fast (practically immediate) decompression during boot
    – 8MB for initramfs.img
  • XZ
    – Tad slower decompression during boot (1-2 seconds, perhaps)
    – 6MB for initramfs.img

The reason I highlighted the filesize for the initramfs.img when using XZ compression is because I believe this is more to do with what flags/options are being passed to the program (gzip, xz, zstd) when compressing the initramfs filesystem image.

The initramfs size is 25% smaller when using XZ, compared to GZIP or ZSTD. I believe this might be the reason decompression takes longer during boot.

Does anyone know where to check what parameters/flags/options are being used for each of the compression choices listed in mkinitcpio.conf?

My hunch tells me that using comparable options for XZ will result in a similar size and startup time.

Yet at the end of the day, we’re talking about a handful of megabytes in 2021 (basically not even a dent in modern storage capacities), so I perhaps even leaving it at the default for GZIP is wise at this point, especially considering those who use older LTS kernels.

9

If you don’t care about the compression size, but you want the fastest decompression of the Linux kernel at startup. It is lz4 :wink:

See: Comparison of Compression Algorithms - LinuxReviews → Decompressing The Linux Kernel

I think gzip is by default, if you disable all compressions in mkinitcpio.conf

1 Like
10

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.