Bug 599282 - sugar-logos doesn't uninstall properly
Summary: sugar-logos doesn't uninstall properly
Alias: None
Product: Fedora
Classification: Fedora
Component: sugar-logos
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Sebastian Dziallas
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-03 03:16 UTC by Fran Rogers
Modified: 2010-07-07 13:35 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2010-07-07 13:35:06 UTC

Attachments (Terms of Use)

Description Fran Rogers 2010-06-03 03:16:05 UTC
Description of problem:
After uninstalling sugar-logos, the Sugar boot splash imagery remains on the system.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. yum install sugar-logos
2. yum remove sugar-logos
3. Reboot the machine
Actual results:
The Sugar boot splash screen still displays on boot.

Expected results:
The default boot splash screen ("charge" on Fedora 13) should display on boot.

Additional info:
When installing sugar-logos, the following error comes up:
Non-fatal POSTIN scriptlet failure in rpm package sugar-logos-3-3.fc13.noarch
warning: %post(sugar-logos-3-3.fc13.noarch) scriptlet failed, exit status 1

However, no error occurs upon removal of the package.

Comment 1 Sebastian Dziallas 2010-06-22 14:08:26 UTC
I think this is a behaviour all plymouth themes share, since one has to rebuild the initrd afterwards. I'm not entirely sure why this isn't happening as part of the RPM remove process, though. plymouth-set-default-theme supports a trigger called --rebuild-initrd which you'd have to use.

Comment 2 Sebastian Dziallas 2010-07-02 21:36:16 UTC
Does the use of --rebuild-initrd or a call of dracut solve this for you?

Comment 3 Fran Rogers 2010-07-03 19:06:27 UTC
Yes; I ran dracut a few days ago to build a new initrd (for an unrelated matter), and now the splash screens are back to the Fedora default. So it appears rebuilding the initrd fixes it.

Comment 4 Sebastian Dziallas 2010-07-07 13:35:06 UTC
The plymouth folks say this happens for a reason, since we don't want to randomly rebuild the user's initrd without their permission. I'd rather have us follow them on this decision, but I hear that there might be a way for this to work better in F14, because plymouth might get its own initrd. I'm closing this for now. Thanks for the report, though!

Note You need to log in before you can comment on or make changes to this bug.