Bug 781508

Summary:	plymouth not cleanly deinstallable
Product:	[openSUSE] openSUSE 12.2	Reporter:	Ingo R. <rull>
Component:	Basesystem	Assignee:	Forgotten User sM9JzehKpy <forgotten_sM9JzehKpy>
Status:	VERIFIED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	crrodriguez
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE 12.2
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Ingo R. 2012-09-21 15:29:01 UTC

User-Agent:       Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120909 Firefox/15.0.1 SeaMonkey/2.12.1

To remove all bells and whistles i tried to deinstall plymouth (wow: doubles initrd space need for nothing). But then the boot messages are gone. It seems, that some dependencies in systemd scripts are not removed or rather hard wired.

(Using

grub2: no graphic console
kernel parameter: splash=verbose quiet

which works with keeping plymouth installed.)


Reproducible: Always

Steps to Reproduce:
1. deinstall plymouth
2. boot
3.
Actual Results:  
nothing to see until login console

Expected Results:  
common boot messages

Comment 1 Forgotten User sM9JzehKpy 2012-09-27 12:46:47 UTC

Can you indicate which packages you exactly have removed ? Plymouth itself does not have any influence on grub2, so to me it looks like some other packages were de-installed as well.

Comment 2 Ingo R. 2012-09-28 15:38:50 UTC

There's no problem with grub2, i suppose, because it is booting until text login screen (runlevel 3 of course), but without any output after grub2 menue and login text console.

The difference is only all plymouth* and libply* modules installed or not.

I have seen, that there are explicit dependencies to plymouth in systemd configs, so there might be missing some default behaviour on plymouth absence.

Comment 3 Cristian Rodríguez 2012-11-01 02:56:03 UTC

you have to boot with plymouth.enable=0 as documented, there is no bug here.

Comment 4 Ingo R. 2012-11-01 17:04:04 UTC

has no effect.