| Summary: | Only black screen with breeze plymouth theme in plasma 5.8.2 | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | somnium <stamper> |
| Component: | Plymouth | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | rajeeshknambiar, rdieter, simonandric5, sitter |
| Priority: | NOR | ||
| Version: | 5.11.3 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
somnium
2016-10-20 11:11:18 UTC
I forgot to mention the plymouth version: it is plymouth 0.9.2 If it works on neon it's hardly a problem with the theme though. Not quite sure what to do with this. Same case (black boot screen) with Fedora 24. On shutdown, though, the plasma icon within spinner is visible. Plymouth version 0.8.9. Right, so, Luca just checked on suse and the theme renders fine with the x11 renderer and runs through its test sequence without theme related problems. Meaning the theme itself is working. This leaves us with a number of options on why it breaks: - the distributions' dracut doesn't package all the assets of the theme into the initrd (images, font files maybe) - the script itself fails to parse when run from initrd, which would be super weird considering it is parsing just fine when run through the x11 renderer (at least on opensuse). So. Y'all want to take this to your distributions for investigation. Best thing would be to find out how to switch plymouth into debug mode for your distribution (usually kernel cmdline plymouth:debug) and then have a look at the logs for any obvious errors regarding the breeze theme. Additionally manually unpacking the initrd and checking that the theme tree in the initrd is the same as the tree on-disk would be useful there. When in doubt about the parsing bit: install the plymouth x11 renderer and run sudo test/plytest.sh in the breeze-plymouth source tree. This should run a fairly comprehensive ability test from offline-updates over fsck to password prompt. Most importantly it will touch most code paths to detect parsing errors. Closing this report as it's not a theme problem apparently. Is it maybe possible, that the password prompt is not working? My ssd is encrypted. In KDE NEON in an Virtualbox it is working, because I have no password prompt. It is also working in an x11 enviroment on openSUSE and Arch, but only the animation. I can't test the password prompt in x11. So maybe this is failing in breeze-plymouth. I really don't know what else can be wrong as all the other graphical splash screens are working, only breeze-plymouth stays black. Why can't you test the password prompt on x11? it seems that the folder with the images of plymouth-breeze theme is not included in initramfs when building with dracut on Tumbleweed or mkinitcpio on Arch Linux. This is why my screen is blank when a password prompt should appear. I reported it to the distros. I for myself don't know how to include those folders. But anyway, it is not a fault of the theme, so I close the bug report. mgoodwin fedora contributor helpfully looked into this awhile back, and came to the conclusion that dracut implementation currently only copies one level resources into initrd. The breeze theme is the only one I've seen that puts resources (images) into subdirectories. So, ways forward include: * modify plymouth-breeze to be flat and not use subdirs * wait for dracut to support subdirs A corollary to option 2, is fedora packaging includes a workaround installed as /usr/lib/dracut/dracut.conf.d/10-plymouth-theme-breeze.conf that includes: # This is a hack that is currently necessary for package: plymouth-theme-breeze # due to the fact that `dracut` only includes the top-level directory of theme folders # By default. See also https://bugs.kde.org/show_bug.cgi?id=371276 if [[ "$(plymouth-set-default-theme)" =~ ^breeze ]]; then readarray -t plymouth_theme_breeze_files < <( find /usr/share/plymouth/themes/breeze -mindepth 1 -type f ) install_optional_items+=" ${plymouth_theme_breeze_files[@]} " fi More references toward attempts to get this fixed properly in plymouth : https://lists.freedesktop.org/archives/plymouth/2017-October/000855.html https://bugs.freedesktop.org/show_bug.cgi?id=103424 So, given that stock plymouth (still) doesn't properly support this, I'd encourage kde to make it work somehow: 1. make the theme flat 2. include a form of the workaround I included earlier 3. some better idea It is supported just fine in Plymouth it is only the dracut scripty that is bugged. The image dir location is even configurable from a Plymouth pov, which makes the dracut deficiency even more mind boggling. our findings were that the plymouth script is used preferentially (if it exists), and the dracut stuff is only a fallback. either way, stock plymouth and dracut scripts do not support subdirs. Well yes, that still doesn't make it a theme bug though. libply-script supports subdirs, the script thingy doesn't. Clearly, the way to resolve the issue is fix the scripty bit so it supports what libply-script supports. What is libply-script ? You mean this? https://cgit.freedesktop.org/plymouth/tree/scripts/plymouth-populate-initrd.in The thing that doesn't work with breeze? Nah, the thing that actually implements script language themes https://cgit.freedesktop.org/plymouth/tree/src/plugins/splash/script OK, so sure, this is most definitely bug in plymouth's current implementation. We agree on that. What we do not agree on (apparently): You're saying you think it's OK to ship a theme known to be incompatible and not work. What I am saying is that this is not a bug in theme and it doesn't need fixing in the theme it needs fixing in the broken scripts. The theme works just fine on systems that use update-initramfs to pack the initrd. OK, I guess we can agree to disagree. plymouth breeze works with one implementation (update-initramfs) and not with the canonical one, plymouth-populate-initrd (which has been "broken" in this regard for years). Last comment (I promise): to put a positive spin on things: If making breeze a flat theme would make it more compatible with other distros and implementations, are there any technical reasons not to do it? 16bit compatibility heavily relies on the fact that all 16bit versions of the assets are in a different path (code-wise 16bit compat is a matter of switching the "root" image path from the 32bit dir to the 16bit dir). Without subdirs one would have to mutate the actual file names `if(16bit) { foo_16.png } else { foo.png }` for each file, or, well, not have 16bit compat (which probably doesn't affect many systems anyway).
Beyond that the non-technical downside is of course that the directory is a mess when flattened (there are some 80 images between 32bit and 16bit), which is the other reason the theme uses subdirs to begin with.
|