This GRUB Quiet Splash says:

The splash (which eventually ends up in your /boot/grub/grub.cfg ) causes the splash screen to be shown.

At the same time you want the boot process to be quiet, as otherwise all kinds of messages would disrupt that splash screen.

Although specified in GRUB these are kernel parameters influencing the loading of the kernel or its modules, not something that changes GRUB behaviour.

However, I have not found splash on https://www.kernel.org/doc/html/v5.0/admin-guide/kernel-parameters.html, but AFAIK it works on modern distros which are kernel 5+ based. Why?

2 Answers 2


If you specify a boot option that the kernel does not recognize, it does not cause an error: the unknown boot parameter will have no effect to the kernel, other than being listed in /proc/cmdline. Then initramfs scripts or other userspace programs can look for it and use it to modify their behavior.

The unknown boot parameters are also passed to the init process, whichever it may be (whether SysVinit, systemd or something else). In fact, this is how important troubleshooting/recovery boot options work, like single to boot a SysVinit system to single-user mode, or systemd.unit=emergency.target for the closest equivalent on a system with systemd.

If your distribution uses user-space boot splash software like plymouth, the kernel just "passes through" any splash/nosplash boot option to /proc/cmdline, and plymouth in initramfs will check for it.

Your distribution may have other troubleshooting/recovery functions implemented as extra boot options by the initramfs generator package. In Debian/Ubuntu and related distributions, see man 7 initramfs-tools for a list of boot options specific to initramfs files created by the initramfs-tools package; in modern RedHat/Fedora, see man dracut.


These days, Linuxes (in fact, Fedora since Fedora 10, so that's 10 years ago, Ubuntu since 10.04, and so on) don't use the kernel's own facilities to load some splash image at boot, but depend on userland software included in the initramfs, to use the kernels Direct Rendering Manager or the framebuffer device, to show something during boot.

On almost all systems, that software is going to be plymouth, which might infer what (not) to do by reading the command line passed to the kernel from grub.

  • 1
    But it's really good to know, so Gilles wrote: Kernel parameters are also visible to user land (via /proc/cmdline). Nov 4, 2021 at 9:53
  • There used to be things like a small tux displayed for every core in the framebuffer during boot, I don't know exactly how that worked Nov 4, 2021 at 10:40
  • 1
    @MarcusMüller That's still there, it's a bitmap built into the kernel (there are even several versions for different platforms) and shown on boot when a framebuffer is available. It's enabled by compiling with CONFIG_LOGO and it resides in drivers/video/logo.
    – TooTea
    Nov 4, 2021 at 20:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .