Created attachment 1406990 [details] fix skipped view_t initialisation for multiple displays Initial state: plymouth not working, on boot or shutdown, just text mode messages. "solar" theme selected. A bit of digging shows it getting an AVC denial opening the framebuffer, which is bug 1551842. After taking that fix, things improve only slightly. Now plymouth shows for about half a second on startup then drops back to text. Still not working on shutdown. More digging, and it appears to be hitting an assertion failure. After an epic battle between systemd, plymouthd and selinux (there were no survivors) I manage to get the following backtrace: Mar 08 03:18:41 kanargh.hell systemd-coredump[684]: Process 548 (plymouthd) of user 0 dumped core. Stack trace of thread 548: #0 0x00007ff1291a466b raise (libc.so.6) #1 0x00007ff1291a6381 abort (libc.so.6) #2 0x00007ff12919c8fa __assert_fail_base (libc.so.6) #3 0x00007ff12919c972 __assert_fail (libc.so.6) #4 0x00007ff12782bdde ply_image_get_width (libply-splash-graphics.so.4) #5 0x00007ff127a34c46 draw_background.isra.23 (space-flares.so) #6 0x00007ff127a34e05 on_draw (space-flares.so) #7 0x00007ff129ed8819 ply_pixel_display_draw_area (libply-splash-core.so.4) #8 0x00007ff127a342f2 redraw_views.isra.5 (space-flares.so) #9 0x00007ff127a3729d display_normal (space-flares.so) #10 0x00007ff129ed55f3 create_pixel_displays_for_renderer (libply-splash-core.so.4) #11 0x00007ff129ed58cc create_devices_for_terminal_and_renderer_type (libply-splash-core.so.4) #12 0x00007ff129ed61f3 create_devices_for_subsystem (libply-splash-core.so.4) #13 0x00007ff129ed6524 create_devices_from_udev (libply-splash-core.so.4) #14 0x00007ff12a0ed682 ply_event_loop_process_pending_events (libply.so.4) #15 0x00007ff12a0edcd0 ply_event_loop_run (libply.so.4) #16 0x000056219f97b3e7 main (plymouthd) #17 0x00007ff12918e00a __libc_start_main (libc.so.6) #18 0x000056219f97c51a _start (plymouthd) (Don't ask me how I got the backtrace. At the point it happens systemd is in no fit state to accept coredumps, and despite plymouthd taking extreme measures to try and enable this - it installs a SIGABRT signal handler that sleeps for 30 seconds in the hope that when it finally crashes systemd-coredump/abrt are ready - more often than not it appears to just ignore the sleep and crash immediately, with no helpful diagnostics.) Problem is: plymouth enumerates the output devices, creates the splash plugin, tells the plugin about the new device, the plugin creates a view_t for the device and tells plymouth to set the redraw handler for the device, plymouth then tells the plugin to start, the plugin initialises its view_t - in this case rescaling the background image and storing the resulting image pointer in the view_t, then plymouth sends repeated redraw commands to the redraw handler. If there are multiple output devices, plymouth will tell the existing plugin to add them later, at which point the plugin will create new view_t's for them. But the background image scaling is done in the start call which only happens once and has already been done. When the subsequent redraw call comes in the view_t finds itself with a NULL image pointer and hits that assertion. The attached patch fixes that two ways: first we return from the redraw handler if the view hasn't been initialised yet. Second, when adding a new view/display, if the plugin has already started then we fully initialise the view immediately rather than waiting for another start call (which will not happen.) With that patch it now survives longer, but the display is seriously messed up. Like it's drawing two different versions of the display and alternating between them. Probably not so noticeable for themes like charge, but for solar which is randomly seeded it's just a flickery mess. A quick google shows that that is an upstream bug fixed last year: https://bugs.freedesktop.org/show_bug.cgi?id=104353 So it really was genuinely drawing twice for each output. After applying the upstream patch solar now shows a stable, smoothly animating display.
(The view_t/abort part of the above might in fact be the same problem as bug 1411051, which was CLOSED EOL for f25 last year.)
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.