With Debian 9.9 and GNOME 3.22, I'm trying to load the OS without boot menu. I've installed plymouth to show a graphical loading and set this options in grub: GRUB_DEFAULT=0 GRUB_TIMEOUT=0 GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX="" GRUB_HIDDEN_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=true But for a split second, I still see some kind of grub menu. This time with no options. What I see is an image located here /usr/share/images/desktop-base/desktop-grub.png, and a text that says loading linux 4.9.0-9-amd64... loading initial memory image... Then plymouth theme is shown and normal boot happens. Is it possible to hide this? I would like to just see the theme

I am working on an appliance system based on CentOS 6. I have created a custom boot splash, but I can't find any information on how I would disable the feature to switch to text mode (switching the splash on and off) through a keypress. I do not want a user to be able to drop the splash and view the boot messages. Can anyone point me in the right direction?

I've been using Debian 12 for the last couple of years and decided to give Ubuntu 24.04 a chance, first thing I noticed is that the boot animation starts at the very beginning of the boot up sequence in the system and shows no message from kernel nor grub and then, when you shut down the system, the animation plays again without showing any messages. The thing is that I'm back in Debian 12 and I can't configure the booting sequence to run as smoothly as it does in Ubuntu 24.04, I could hide grub and run the animation when booting up the system and when shutting it down, but I still get the kernel screen that says "Booting 'Debian GNU/Linux'", "Loading Linux 6.1.0-32-amd64 ..." and "Loading initial ramdisk ...". How can I get rid of that so the booting animation runs smoothly from start to finish?

I have an HP DL360 Gen9 with CentOS7 running and we recently physically migrated the server. Perhaps we didn't reboot the server in a long time or we never connected physically so I don't know if it was a previous issue or not. xfce was installed sometime in the last few years and we were able to remote into the server with xrdp installed without an issue. But when I'm connected physically to the server, it shows the OS loading screen right before its supposed to show a log-in screen. But it just goes blank (black) from there. Hitting Alt+F2, I can see that it is stuck at this: A start job is running Wait for Plymouth Boot Screen to Quit

I have a number of Fedora systems; some run fc41, but the more production-like one I keep one behind at fc40. On one of them (I call it cleo), the bootup takes longer than I like. In a blog, I learned that one might discover why, by using systemd-analyze critical-chain , which yielded the error

Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs

Following that suggestion, I get

JOB UNIT                                 TYPE  STATE
334 plymouth-quit-wait.service           start running
462 power-profiles-daemon.service        start waiting
146 multi-user.target                    start waiting
432 systemd-update-utmp-runlevel.service start waiting
145 graphical.target                     start waiting

5 jobs listed.

I am puzzled by the fact that despite bootup being incomplete, I can connect to a GNOME desktop using TigerVNC, and I can also login by ssh without problems. On a different production system (shadow), I get

[lpoulsen@shadow ~]$ sudo systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

multi-user.target @17.354s
└─pmlogger_farm.service @17.350s +2ms
  └─pmlogger.service @16.283s +1.055s
    └─pmcd.service @15.873s +398ms
      └─network-online.target @15.800s
        └─NetworkManager-wait-online.service @14.231s +1.567s
          └─NetworkManager.service @13.387s +829ms
            └─network-pre.target @13.375s
              └─firewalld.service @10.932s +2.441s
                └─polkit.service @10.663s +251ms
                  └─basic.target @10.622s
                    └─dbus-broker.service @10.567s +51ms
                      └─dbus.socket @10.564s
                        └─sysinit.target @10.550s
                          └─systemd-resolved.service @10.375s +174ms
                            └─systemd-tmpfiles-setup.service @10.000s +356ms
                              └─systemd-journal-flush.service @4.037s +5.947s
                                └─systemd-journald.service @3.906s +118ms
                                  └─systemd-journald-audit.socket @3.916s
                                    └─system.slice
                                      └─-.slice
[lpoulsen@shadow ~]$ sudo systemctl list-jobs
No jobs running.
[lpoulsen@shadow ~]$

On my raspberry, I have enabled plymouth splash screen and I have a custom systemd service that starts an app at boot. My problem is that the initialization of the app takes some time and currently plymouth splash disappears long before the app is ready, resulting in a long black screen. What would be the proper way to keep plymouth splash visible during app initialization ?

i create file sh, i click file sh will start to executive. but Xterm not work to run plymouthd... instead kdesu is worked to run plymouthd..but i want to use xterm.. maybe i missing something parameter.. this is KDESU **(works)** #!/bin/bash kdesu -c "sudo plymouthd; plymouth --show-splash; sleep 10; plymouth quit" this is xterm **(not work)** #!/bin/bash xterm -geometry 130x15 -fg Plum1 -bg Purple4 -fa 'Monospace' -fs 10 -e 'sudo plymouthd; plymouth --show-splash; sleep 10; plymouth quit' I checked in google but nothing find..damn...

I have created a custom Plymouth theme (based on MIB Ossigeno) configured to process fsck's messages coming from systemd-fsckd by implementing the communication protocol whose message has the following format: fsckd::: According documentation (8-systemd-fsckd.service ) When executed it, in test mode ("post-boot"), using the command: plymouthd; plymouth --show-splash ; for ((I=0; I<10; I++)); do plymouth --update=fsck:sda1:$I ; sleep 1; done; plymouth quit With special FSCK messages, plymouth shows desired messages, like "Checking disk 1 of 1 (2% complete)". See: Plymouth . So far, so good. But when restarting the system, the fsck messages are not displayed on bootsplash. But if I switch to console by pressing Esc key, fsck progress messages are visible. To force fsck to run at boot, I have alternately used tune2fs and grub (GRUB_CMDLINE_LINUX_DEFAULT="quiet splash fsck.mode=force fsck.repair=yes") to see if there were any implications. For some reason the communication between fsck and Plymouth is not working or working well. The default theme, futureprototype, does not work either. I guess the problem is in systemd-fsckd, How does one determine whether systemd-fsckd's tasks were performed at bootup?, Is there a report or status that shows whether any issues were found? I look in /run/initramfs/fsck.log (this looks good): ~# cat /run/initramfs/fsck.log Log of fsck -C -f -y -T -t ext4 /dev/sda1 Wed Feb 28 15:26:27 2024 e2fsck 1.47.0 (5-Feb-2023) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda1: 212266/593344 files (0.2% non-contiguous), 1705537/2371072 blocks Wed Feb 28 15:26:30 2024 Journal... ~# journalctl -u systemd-fsck* -- Boot f8b976dfd857400085057901577c56f9 -- feb 28 10:40:53 debian12 systemd[1] : Started systemd-fsckd.service - File System Check Daemon to report status. feb 28 10:41:23 debian12 systemd[1] : systemd-fsckd.service: Deactivated successfully. feb 28 10:51:02 debian12 systemd[1] : Started systemd-fsckd.service - File System Check Daemon to report status. feb 28 10:51:32 debian12 systemd[1] : systemd-fsckd.service: Deactivated successfully And systemctl ~# systemctl status systemd-fsckd.socket ● systemd-fsckd.socket - fsck to fsckd communication Socket Loaded: loaded (/lib/systemd/system/systemd-fsckd.socket; static) Active: active (listening) since Wed 2024-02-28 15:26:31 -03; 16min ago Triggers: ● systemd-fsckd.service Docs: man:systemd-fsckd.service(8) man:systemd-fsck@.service(8) man:systemd-fsck-root.service(8) Listen: /run/systemd/fsck.progress (Stream) CGroup: /system.slice/systemd-fsckd.socket ~# systemctl status systemd-fsckd.service ○ systemd-fsckd.service - File System Check Daemon to report status Loaded: loaded (/lib/systemd/system/systemd-fsckd.service; static) Active: inactive (dead) TriggeredBy: ● systemd-fsckd.socket Docs: man:systemd-fsckd.service(8) The goal is to notify the user that the boot process is delayed by fsck's disk check and to view its progress. I have exhausted all my resources and have found nothing on the web. In general, all I find is about hiding boot messages. ~# more /etc/debian_version 10.13 ~# uname -a Linux debian 4.19.0-26-686-pae #1 SMP Debian 4.19.304-1 (2024-01-09) i686 GNU/Linux For reasons that are not relevant, the development is on OS Debian 10, although I have also tried with Debian 12 with the same result. PD: A detail that may be relevant: the tests with Debian 10 and Debian 12 were both carried out on virtual machines on Virtual Box. More test: **Case one:** Debian 10 on Virtual Box. The fsck messages do not appear and the journal shows the following: root@debian:~# systemctl list-sockets | grep fsckd /run/systemd/fsck.progress systemd-fsckd.socket systemd-fsckd.service root@debian:~# journalctl -b /usr/lib/systemd/systemd-fsck -- No entries -- root@debian:~# journalctl -b /usr/lib/systemd/systemd-fsckd -- No entries -- root@debian:~# journalctl --boot | grep systemd-fsck* mar 04 13:07:01 debian systemd[1] : Listening on systemd-fsckd.socket - fsck to fsckd communication Socket. mar 04 13:07:01 debian systemd[1] : systemd-fsck-root.service - File System Check on Root Device was **skipped** because of an unmet condition check (**ConditionPathExists=!/run/initramfs/fsck-root**). root@debian:~# cat /run/initramfs/fsck.log Log of fsck -C -a -T -t ext4 /dev/sda1 Mon Mar 4 13:06:59 2024 /dev/sda1: clean, 212351/593344 files, 1708897/2371072 blocks Mon Mar 4 13:06:59 202 **Case Two:** Debian 10 on physical PC (amd64). In this case the messages are visible, but at the end of the process and very few seconds. Nothing is displayed during execution of fsck. root@Dell:~# systemctl list-sockets | grep fsckd /run/systemd/fsck.progress systemd-fsckd.socket systemd-fsckd.service root@Dell:~# journalctl -b /usr/lib/systemd/systemd-fsck -- Logs begin at Mon 2024-03-04 15:58:16 -03, end at Mon 2024-03-04 19:25:01 -03. -- mar 04 15:58:21 Dell systemd-fsck: e2fsck 1.44.5 (15-Dec-2018) mar 04 15:58:21 Dell systemd-fsck: Pass 1: Checking inodes, blocks, and sizes mar 04 15:58:21 Dell systemd-fsck: Pass 2: Checking directory structure mar 04 15:58:21 Dell systemd-fsck: Pass 3: Checking directory connectivity mar 04 15:58:21 Dell systemd-fsck: Pass 4: Checking reference counts mar 04 15:58:21 Dell systemd-fsck: Pass 5: Checking group summary information mar 04 15:58:22 Dell systemd-fsck: /dev/sda1: 1034/69360 files (0.7% non-contigu root@Dell:~# journalctl -b /usr/lib/systemd/systemd-fsckd -- Logs begin at Mon 2024-03-04 15:58:16 -03, end at Mon 2024-03-04 19:25:01 -03. -- -- No entries -- root@Dell:~# journalctl --boot | grep systemd-fsck* mar 04 15:58:21 Dell systemd-fsck: e2fsck 1.44.5 (15-Dec-2018) mar 04 15:58:21 Dell systemd-fsck: Pass 1: Checking inodes, blocks, and sizes mar 04 15:58:21 Dell systemd-fsck: Pass 2: Checking directory structure mar 04 15:58:21 Dell systemd-fsck: Pass 3: Checking directory connectivity mar 04 15:58:21 Dell systemd-fsck: Pass 4: Checking reference counts mar 04 15:58:21 Dell systemd-fsck: Pass 5: Checking group summary information mar 04 15:58:22 Dell systemd-fsck: /dev/sda1: 1034/69360 files (0.7% non-contiguous), 189933/276480 blocks mar 04 15:59:01 Dell systemd[1] : systemd-fsckd.service: Succeeded. root@Dell:~# cat /run/initramfs/fsck.log Log of fsck -C -f -y -T -t ext4 /dev/sda2 Mon Mar 4 18:57:36 2024 e2fsck 1.44.5 (15-Dec-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda2: 673194/9551872 files (0.8% non-contiguous), 29651430/38200576 blocks Mon Mar 4 18:58:11 2024 ---------------- **Case three:** Debian 10 on physical PC (amd64) with multiple entries grub menu (Debian and other bootable partitions with Windows). root@5VQU7SN:~# systemctl list-sockets | grep fsckd /run/systemd/fsck.progress systemd-fsckd.socket systemd-fsckd.service root@5VQU7SN:~# journalctl -b /usr/lib/systemd/systemd-fsck -- Logs begin at Mon 2024-03-04 15:38:25 -03, end at Mon 2024-03-04 20:39:47 -03. -- -- No entries -- root@5VQU7SN:~# journalctl -b /usr/lib/systemd/systemd-fsckd -- Logs begin at Mon 2024-03-04 15:38:25 -03, end at Mon 2024-03-04 20:39:47 -03. -- -- No entries -- root@5VQU7SN:~# journalctl --boot | grep systemd-fsck* -- No entries -- root@5VQU7SN:~# cat /run/initramfs/fsck.log Log of fsck -C -f -y -T -t ext4 /dev/sda6 Mon Mar 4 18:37:59 2024 e2fsck 1.44.5 (15-Dec-2018) /dev/sda6: recovering journal Clearing orphaned inode 15992282 (uid=1000, gid=1000, mode=0100644, size=32768) Clearing orphaned inode 15991323 (uid=1000, gid=1000, mode=0100600, size=460) Clearing orphaned inode 15990858 (uid=1000, gid=1000, mode=0100644, size=4132) Clearing orphaned inode 15990852 (uid=1000, gid=1000, mode=0100600, size=131072) Clearing orphaned inode 15990840 (uid=1000, gid=1000, mode=0100644, size=4132) Clearing orphaned inode 15990827 (uid=1000, gid=1000, mode=0100644, size=4132) Clearing orphaned inode 15990826 (uid=1000, gid=1000, mode=0100644, size=4132) Clearing orphaned inode 15990859 (uid=1000, gid=1000, mode=0100644, size=4132) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong (112010854, counted=112010689). Fix? yes Free inodes count wrong (28961618, counted=28961585). Fix? yes /dev/sda6: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sda6: 292047/29253632 files (0.3% non-contiguous), 4981311/116992000 blocks fsck exited with status code 1 Mon Mar 4 18:38:19 2024 ---------------- This issue is becoming quite complex and I don't see where to move forward. I hope there is some expert collegue who can help me in this matter. STATUS UPDATE: I found that the default Plymouth theme worked on another PC, and when I installed my theme, it worked too. I spent days checking grub, fsck, and plymouth configurations, but I couldn't find a difference. Until I noticed that on that PC the /boot directory was mounted on a different partition from the root. Install Debian from scratch on a physical and a virtual PC, with /boot separately. And it worked!!! Could it be a bug of systemd-fsck?

Here is a gentoo-kernel(6.11.3) with openrc(0.55.1)+elogind(255.5) and dracut(103-r4)+grub(2.12-r5) operating system. plymouth version is 22.02.122-r2 Hardware: amd64, nvidia Plymouth can not work smoothly to start sddm with any graphic theme, configration wiht graphic theme will spalsh or flash the animation over and over again, but sddm is not be there as it should. Only "details" theme could work normally, but as you all known, this theme is not a graphic theme. I noticed that the publisher of Plymouth in gitlab announced that Plymouth do not support to build from source code, caused by it's relative to distro. And I noticed that current version of plymouth in gentoo repository with a timestamp in 2022, and current version in gitlab with timestamp 2024, I'm not sure whether what I'm encountered is relative to the version difference.

OpenSUSE Leap 15.6. I have a systemd service which backups the system to a NFS share just before the latter is unmounted using rsnapshot:

[Install]
WantedBy=multi-user.target

[Service]
ExecStop=sh -c 'systemctl list-jobs | grep -q "poweroff.target.*start" && mountpoint -q /mnt/nas/backup && rsnapshot -V alpha'
RemainAfterExit=true
TimeoutStopSec=infinity

[Unit]
After=mnt-nas-backup.mount
Description=rsnapshot

The systemctl list-jobs | grep -q "poweroff.target.*start" && mountpoint -q /mnt/nas/backup shananigans are just guards set in place to make sure that the service won't run on reboot and that it will run only on poweroff, if the NFS share is accessible: you can ignore those. For any practical purpose, the ExecStop action is just running rsnapshot -V alpha. I thought it would be nice for plymouth to display a relevant message such as "Backing up..." on the poweroff's splash screen while the ExecStop action is running. Mind you, this is uncharted territory for me. First I started plymouth on /dev/tty3 from the fully booted-up system, and I tried displaying a simple message by running:

sudo plymouthd --no-daemon --tty=/dev/tty3

In one terminal and:

sudo plymouth display-message --text="Test"

In another terminal. This worked perfectly. After that, I copied the backup service to /etc/systemd/system/test.service and edited it so that the thing would just display a message on plymouth's splash screen and wait, changing TimeoutStopSec to 60 as a safety measure:

[Install]
WantedBy=multi-user.target

[Service]
ExecStop=sh -c 'plymouth display-message --text="Test"; sleep 30'
RemainAfterExit=true
TimeoutStopSec=60

[Unit]
After=mnt-nas-backup.mount
Description=test

sudo systemctl enable --now test.service and sudo reboot. Of course, the poweroff process hangs for 30 seconds with no message on plymouth's splash screen. Although technically I should make sure plymouth-reboot.service is still up when the service runs, since I latched this using After=mnt-nas-backup.mount, plymouth-reboot.service being up is basically guaranteed, and proof of that is the fact that I can see the service running and hanging the poweroff process. I thought maybe some kernel parameter was preventing plymouth from displaying messages. So I changed:

GRUB_CMDLINE_LINUX_DEFAULT="splash=silent preempt=full mitigations=auto quiet security=apparmor"

to:

GRUB_CMDLINE_LINUX_DEFAULT="splash preempt=full mitigations=auto quiet security=apparmor"

and ran sudo grub2-mkconfig -o /boot/grub2/grub.cfg (basically changing splash=silent to splash). quiet should be irrelevant here, however I also tried removing quiet at some point; security=apparmor also should be irrelevant since there are no apparmor profiles configured for plymouth. No dice. Any idea what could be preventing this from working? Here's the contents of plymouth-reboot.service, which isn't shedding any light for me:

[Unit]
Description=Show Plymouth Reboot Screen
After=getty@tty1.service display-manager.service plymouth-start.service
Before=systemd-reboot.service
DefaultDependencies=no
ConditionKernelCommandLine=!plymouth.enable=0
ConditionVirtualization=!container

[Service]
ExecStart=/usr/sbin/plymouthd --mode=reboot --attach-to-session
ExecStartPost=-/usr/bin/plymouth show-splash
Type=forking
RemainAfterExit=yes

I've got a beautiful seamless startup experience with Arch & KDE Plasma 6.1, thanks to Plymouth. But after recent updates (I believe to kernel 6.9.x), the splash screen is interrupted by a stacktrace. The trace doesn't seem to offer any meaningful information on what went wrong. Also, Plymouth works fine regardless. The stacktrace doesn't show up in logs, so I've made a photo of it - ignore the 'no key available' message, I was hitting return to see if it froze, but it didn't, it was still waiting for my passphrase: Then there was some mention of Plymouth exiting abnormally in journalctl:

Jul 23 12:21:31 archlinux systemd-coredump: Process 311 (plymouthd) of user 0 terminated abnormally with signal 11/SEGV, processing...
Jul 23 12:21:31 archlinux systemd-coredump: Due to PID 1 having crashed coredump collection will now be turned off.
Jul 23 12:21:31 archlinux systemd: Starting NVIDIA System Management Interface...
Jul 23 12:21:31 archlinux systemd-coredump: Resource limits disable core dumping for process 311 (plymouthd).
Jul 23 12:21:31 archlinux systemd-coredump: [🡕] Process 311 (plymouthd) of user 0 terminated abnormally without generating a coredump.

I also tried adding the kernel option plymouth.debug. This doesn't seem to provide much more insight. There is an interesting thing, it has a lot of mentions like this:

00:00:46.600 ../plymouth/src/libply-splash-core/ply-terminal-emulator.c:989: terminal escape character: carriage return

This suggests I'm hitting return? Because I was not. Here's the entire log: https://pastebin.com/rpvnkgZ3 There are also some mentions of a timeout. This is interesting, because when I boot, the Plymouth splash screen comes up normally, in proper resolution etc., but after a few seconds, it cuts to the stacktrace. Then, when I enter my passphrase, it continues to boot normally. Curiously, if I use the plymouth.debug kernel option, it fails to boot, it then hangs on 'Reached Target Graphical Interface'. Any ideas what this could be? I've tried reinstalling Plymouth, but that made no difference. I also rebuilt initramfs (multiple times, obviously to get the debug log), also no difference.

Info - OS: Debian GNU/Linux 12 (bookworm) x86_64 - Kernel: 6.1.0-10-amd64 - Desktop Environment: Plasma 5.27.5 (KDE) - Hardware: 82HU IdeaPad Flex 5 14ALC05 I am trying to use plymouth to display splash screen while booting. But after trying many times, I couldn't find a way to get it to work. I followed the instructions from the link below and other websites. https://wiki.debian.org/plymouth Here is the grub's config file.

GRUB_DEFAULT="0"
GRUB_DISTRIBUTOR="lsb_release -i -s 2> /dev/null || echo Debian"
GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=3 splash  rd.udev.log-priority=3 vt.global_cursor_default=0 amdgpu.modeset=1"
GRUB_CMDLINE_LINUX="console=tty12"

export GRUB_COLOR_NORMAL="light-gray/black"
export GRUB_COLOR_HIGHLIGHT="magenta/black"
GRUB_THEME="/boot/grub/themes/ROG/theme.txt"
GRUB_GFXMODE=1920x1080
GRUB_TIMEOUT="0"
GRUB_TIMEOUT_STYLE="menu"

GRUB_BACKGROUND=""

I recently dual booted Arch and Windows and I've been playing around with Plymouth to try to make the boot up process more aesthetic and I found a really nice theme but rEFInd's boot up text ruins it by appearing before the theme loads and then after it before loading my lightdm login. I already took a look at this question and I followed the answer and it works. The text no longer appears. However, instead there's a weird blackish screen that replaces it and my theme is still ruined. Is there anyway to remove this and just show my theme? The plymouth theme is dark-arch if that makes a difference. I can post any needed config files or anything else too, don't know what's needed though. Thanks for any help!

**System: Fedora 37, Gnome 43** I enabled LUKS encryption on setup and enabled auto-decrypt via TPM 2 with following an article from Fedora Magazine. Auto-decrypt works but while it decrypts, it shows the passphrase screen until system boots. How can I hide this screen?

I installed Plymouth on a LUKS encrypted machine. Works fine. Theme is Spinner, in case it matters. I'd like to modify one thing, though: After entering the LUKS passphrase, there's a status message cryptsetup: nvme0n1p3_crypt set up successfully showing for 2-3 seconds. Is it possible to get rid of it? In /usr/share/plymouth/themes/spinner/spinner.plymouth there is a MessageBelowAnimation=true option, but that's just for the position on the screen. Is it possible to completely hide the status messages?

I'm trying to create a completely flickerless boot and login with Xorg, and I'm particularly interested in the time between the bootsplash (I use Plymouth) and Xorg being fully loaded (i.e. after the screen flickers black to allow Xorg to start). So far, I have created a Plymouth theme that ends with all-white frames, so I just need to force the screen to go white until my wallpaper (using feh) is fully loaded, at which point I will hopefully be able to seamlessly transition to my desktop. So far, my ideas have included some type of low-level program to force all the screen pixels to be white before and while the tty is loaded, and allow the screen to go back to normal after the wallpaper is loaded, however, I don't know of any program that does that. If there exists such a program, or if there is some method to create one, that would be very helpful. I would probably need to load it as a systemd service in order for it to take effect before the tty is loaded.

I have managed to install a custom splash screen for Debian (buster) using plymouth. However once installed and rebooted I noticed that my OEM logo was in the way so i disabled it with UseFirmwareBackground=False and added a background-tile.png file (blank black image) to the theme. This fixed the OEM issue but now I am left with this Debian logo. How can i remove this?

Im trying make my plymouth-git work Im on Arch Linux When i restart or shutdown, the plymouth init and appears the theme i choosed But when the PC boot, it doesn't appear the theme, it only appears a grey screen and white 3 dots /etc/mkinitcpio.conf # 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=() # 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=() # 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 ' 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 udev plymouth autodetect modconf block filesystems keyboard fsck) # COMPRESSION # Use this to compress the initramfs image. By default, zstd compression # is used. Use 'cat' to create an uncompressed image. #COMPRESSION="zstd" #COMPRESSION="gzip" #COMPRESSION="bzip2" #COMPRESSION="lzma" #COMPRESSION="xz" #COMPRESSION="lzop" #COMPRESSION="lz4" # COMPRESSION_OPTIONS # Additional options for the compressor #COMPRESSION_OPTIONS=() /etc/default/grub # GRUB boot loader configuration GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Arch" GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet splash vt.global_cursor_default=0" GRUB_CMDLINE_LINUX="" # Preload both GPT and MBR modules so that they are not missed GRUB_PRELOAD_MODULES="part_gpt part_msdos" # Uncomment to enable booting from LUKS encrypted devices #GRUB_ENABLE_CRYPTODISK=y # Set to 'countdown' or 'hidden' to change timeout behavior, # press ESC key to display menu. GRUB_TIMEOUT_STYLE=menu # Uncomment to use basic console GRUB_TERMINAL_INPUT=console # Uncomment to disable graphical terminal #GRUB_TERMINAL_OUTPUT=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' GRUB_GFXMODE=auto # Uncomment to allow the kernel use the same resolution used by grub GRUB_GFXPAYLOAD_LINUX=keep # Uncomment if you want GRUB to pass to the Linux kernel the old parameter # format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx" #GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entries GRUB_DISABLE_RECOVERY=true # Uncomment and set to the desired menu colors. Used by normal and wallpaper # modes only. Entries specified as foreground/background. #GRUB_COLOR_NORMAL="light-blue/black" #GRUB_COLOR_HIGHLIGHT="light-cyan/blue" # Uncomment one of them for the gfx desired, a image background or a gfxtheme #GRUB_BACKGROUND="/path/to/wallpaper" #GRUB_THEME="/path/to/gfxtheme" # Uncomment to get a beep at GRUB start #GRUB_INIT_TUNE="480 440 1" # Uncomment to make GRUB remember the last selection. This requires # setting 'GRUB_DEFAULT=saved' above. #GRUB_SAVEDEFAULT=true # Uncomment to disable submenus in boot menu #GRUB_DISABLE_SUBMENU=y # Probing for other operating systems is disabled for security reasons. Read # documentation on GRUB_DISABLE_OS_PROBER, if still want to enable this # functionality install os-prober and uncomment to detect and include other # operating systems. GRUB_DISABLE_OS_PROBER=false /etc/plymouth/plymouthd.conf # Set your plymouth configuration here. [Daemon] Theme=spinfinity ShowDelay=0 DeviceTimeout=8 lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) I/O Memory Management Unit 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Host Bridge 00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Host Bridge 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Carrizo Platform Security Processor 00:09.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Carrizo Audio Dummy Host Bridge 00:09.2 Audio device: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Audio Controller 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 20) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 49) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 49) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 4a) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 5 05:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43bc (rev 02) 05:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] Device 43b8 (rev 02) 05:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b3 (rev 02) 06:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 06:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 06:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 06:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 22:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) 22:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) Can somewhone help :(?

I decided I wanted to get my hands a little dirty and make a custom Plymouth boot theme. I basically just copied one of the defaults and changed some of the parameters and added my own image. Now on boot, I get to grub but after selecting Manjaro the screen goes to boot but hangs with the cursor in the top left staying solid. Not able to type or hop into console with CTRL+ALT+F2. I have access to the drive because I'm dual-booted with Win11 so could potentially edit files on my linux partition. I also could get a new live boot USB to try to repair, but not sure if any of these are the right way to fix this. Does anyone have any suggestions on how I could approach fixing this? ___ Manjaro XFCE on Razer Blade RTX 2070 but intel CPU is what handles display (laptop) Linux Kernel 15.7?? the most recent stable for manjaro. EDIT: Thanks to a little push from Bravo I have access to the partition from my Tails USB I carry around. Still have no idea how I should go about removing Plymouth. Gonna try and dive into some documentation.

I have configured Plymouth with Gnome on Arch Linux and can boot without problem (as in I enter my encryption key, get to the login screen, and can successfully log in). Unfortunately, plymouth-quit-wait.service never finishes:

~ systemctl status plymouth-quit-wait

● plymouth-quit-wait.service - Hold until boot process finishes up
     Loaded: loaded (/usr/lib/systemd/system/plymouth-quit-wait.service; static)
     Active: activating (start) since Wed 2020-08-19 11:37:12 CEST; 4min 31s ago
   Main PID: 603 (plymouth)
      Tasks: 1 (limit: 38119)
     Memory: 312.0K
     CGroup: /system.slice/plymouth-quit-wait.service
             └─603 /usr/bin/plymouth --wait

Aug 19 11:37:12 hostname systemd: Starting Hold until boot process finishes

I don't understand the reason for this, as everything works fine. Where could I look for troubleshooting?