Package: plymouth Version: 0.9.4-3 We encountered a way how plymouth can cause initrd creation to fail:
/usr/share/initramfs-tools/hooks/plymouth contains a call to plymouth-set-default-theme, reading the set theme name. plymouth-set-default-theme fails back to "text" apparently, if the desired theme (set via plymouthd.conf) is unknown. If this name is not "text" or "details", the script later on tries to copy /etc/fonts/fonts.conf However, if fontconfig-config isn't yet installed (and thus plymouth-themes isn't installed yet), then the following sequence can (and for us reproducibly did) happen: - Configuration file plymouthd.conf was written, setting theme "lines". - Installation of kernel, plymouth, plymouth-themes, desktop-base, fontconfig-config requested - packages are unpacked by dpkg (which doesn't copy conffiles to their destination) - Note: plymouth hook script is now active (not a conffile) - kernel gets configured. tries to build initrd - plymouth hook gets executed - plymouth hook reads desired theme, finds "lines" (installed by desktop-base) - plymouth hook fails to copy /etc/fonts/fonts.conf and aborts I'll describe multiple options. The first two are the most sensible IMHO. Option 1: Let the hook script or plymouth-set-default-theme fall back to the "text" or "details" theme if required files are not available yet. At least in our case, the initrd would have gotten rebuilt again later on, eliminating the issue of a silent fallback. Option 2: Let plymouth declare a "Pre-Depends: fontconfig-config" to ensure that the conffile from fontconfig-config is actually available at the time plymouth gets installed and thus activates the initramfs-tools hook script. This introduces an indirect dependency on various fonts, but seems reasonable anyways. Would eliminate the silent fallback and would thus probably come closest to user expectation. Option 3: Let both desktop-base and plymouth-themes Pre-Depend on fontconfig-config - This would move the responsibility to whoever provides a plymouth theme. As the set of such packages is not necessarily a closed set, I'm not sure if this is maintainable in the long run. My personal preference would probably be Option 2: It would get the issue fixed for everyone at little extra cost.
