A couple of years ago, I posted about a problem with removing plymouth from my system, original problem thread. Today, I finally figured out how to successfully remove plymouth If you read the original thread, you will see that the problem doesn’t occur after removing the packages. It appears on the first boot after running dracut. I poked around in /usr/lib/dracut/modules.d after removing all plymouth packages using
zypper remove --clean-deps (list of all installed plymouth packages)
Even after removing all the relevant packages, the directory
was still present, and it contained around half a dozen executable files. So I deleted the directory and it’s contents, ran dracut -f, and now I can successfully reboot without any traces of dracut on my system. I’m guessing that this is a bug against plymouth? Or is it the responsibility of the end user to clean up /usr/lib/dracut/modules.d?
Are you sure?
None of my TW or Leap installations have Plymouth installed. I taboo it at installation time. Even so, on the TW that’s in dup here ATM, and another just checked, /usr/lib/dracut/modules.d/50plymouth/ still exists, containing 5 scripts.
Since Plymouth becomes part of initrds when installed, its successful removal necessarily and normally requires initrd regeneration.
Oops, I meant without any trace of plymouth on my system. When I first installed the system, I didn’t block plymouth. So my question is, should removing plymouth clean up
Or is the administrator expected to clean that up? When it’s left behind, dracut creates an unbootable initrd.
Methinks there is a flaw with your attribution determination:
# ls -Gg /usr/lib/dracut/modules.d/50plymouth/
-rwxr-xr-x 1 1503 Jul 17 02:08 module-setup.sh
-rwxr-xr-x 1 52 Jul 17 02:08 plymouth-emergency.sh
-rwxr-xr-x 1 116 Jul 17 02:08 plymouth-newroot.sh
-rwxr-xr-x 1 1635 Jul 17 02:08 plymouth-populate-initrd.sh
-rwxr-xr-x 1 1183 Jul 17 02:08 plymouth-pretrigger.sh
# lsinitrd /boot/initrd | grep mouth
# rpm -qa | grep mouth
# grep RETT /etc/os-release
# uname -r
No, this is not. plymouth module is part of upstream dracut and belongs to the dracut package.
I wonder what was going on in my original problem thread? I reinstalled dracut with -f to get that directory and it’s contents back, and I can successfully boot now after running dracut -f. So whatever was broken in the linked thread in my OP must have been fixed at some time ago.
I don’t bother with the installed packages and turn off plymouth on the command line:
6700k:~ # grep CMD /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet plymouth.enable=0 mitigations=auto"
You mentioned that in the old thread, and that’s what I did back then. The problem was different than I remembered, xorg was crashing during boot after removing plymouth and running dracut. Apparently, that bug has been fixed, and I should have tested more thoroughly before starting this thread. Sorry for the noise.