At the moment if a client disconnects while the daemon is completely
an asynchronous request, the daemon crashes trying to access a freed
connection object.
This commit changes the boot server code to keep the connection object
alive after the client disconnects, if there's pending work to do.
https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/125
Before this commit we would skip preferred-mode selection if a video=
kernel cmdline is argument, instead relying on the kernel to have activated
all the outputs and then we would inherit those modes.
But this relies on fbcon having initialized the outputs, which it does not
do when deferred-fbcon-takeover is used. Deferred-fbcon-takeover is
necessary for flickerfree boot, so this is now the default in many distros.
Instead of relying on the kernel having setup everything for us, honor
the video= mode selection by checking for modes with a DRM_MODE_TYPE_USERDEF
flag before checking for modes with a DRM_MODE_TYPE_PREFERRED flag.
Note that the DRM_MODE_TYPE_USERDEF flag is only ever set based on a
video= argument. So on systems without a video= argument on the kernel
cmdline nothing changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
setlocale was already called on filesystem mounting but that's not enough
to cover all the cases. The call needs to be conditional because doing it
at a time where the locales are not available (in the initrd) would
result in translations to not be working.
Because on some systems (like Ubuntu with its alternatives) the "Theme="
line will be missing from plymouthd.defaults. And bailing out early was
causing other settings like DeviceTimeout to never be loaded, which would
then cause the graphics renderers to fail.
At the moment switching modes affects two aspects of how plymouth
runs.
1) What log file is opened (i.e., boot.log or no log file at all)
2) What type of splash gets shown (the details of which are relegated
to the individual splash plugins)
The mode change handler has a check in place to avoid changing the
type of splash getting shown in the event no splash is supposed to
be shown yet. This check just makes the function return without
doing anything.
Unfortunately, the check is placed at the top of the function, so
it runs before the log file is changed.
This commit moves the check lower down, so the log file gets properly
updated when the mode is changed.
plymouthd can be run in various modes, for, e.g., boot up,
shutdown, and software upgrades.
The mode plymouthd is using can be changed at runtime.
The "boot" mode keeps a log of the console messages that
happen during boot up. At the moment, when changing from
the "boot" mode to any other mode, the log file is kept
open.
That open file can cause problems during shutdown.
This commit makes sure the log file is properly closed when
the mode is changed from boot to another mode.
https://gitlab.freedesktop.org/plymouth/plymouth/issues/88
When a kernel-mode-setting driver loads it will trigger an add udev event
for /dev/dri/card0, followed by one udev change event per connector on the
card. This means that after our initial probe of the card,
create_heads_for_active_connectors is called a number of times for all the
udev change events.
After the initial enum our outputs array will contain active entries for
all connected displays. Meaning that the first loop in
create_heads_for_active_connectors would call get_output_info for
these outputs. Under the hood this does a number of ioctls and especially
the drmModeGetConnector call can be quite expensive.
Then in the second loop create_heads_for_active_connectors would call
get_output_info for all connectors, including for the once which were
checked in the first loop.
There is no reason why we cannot check if active connectors in the
old outputs array have changed when we are calling get_output_info for
all connectors to build the new array. This avoids unnecessarily making
the expensive get_output_info call twice for active connectors in the
old outputs array.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Commit f9e376797a ("ply-device-manager: Consume all events in one go")
changed ply-device-manager to consume all pending udev events in one go
instead of consuming only 1 and then returning back to the mainloop.
The idea here was to avoid the overhead of returning back to the mainloop,
doing the poll again, seeing more events were pending and then re-enter
ply-device-manager.
In retrospect this is not a good idea. Systemd waits for oneshot units
like plymouth-switch-root.service to finish and this can block the boot.
Specifically plymouth-switch-root.service must complete before systemd in
the initrd will exec the systemd from the real rootfs. This means that
systemd inside the initrd waits for the:
ExecStart=-/usr/bin/plymouth update-root-fs --new-root-dir=/sysroot
Command to complete, if this command runs while we are consuming udev
events from the graphics card (which sends a change event per probed
connector during the initial probe), then plymouth will not send the ack
to the plymouth boot-client (completing the ExecStart) until all udev
events are consumed.
On my main workstation with i915 graphics and 2 HDMI connected FHD monitors,
this delays the actual switching of the root by 1.9 - 2.1 seconds,
because the re-enumaration of the connectors in the drm plugin takes
about 0.4 seconds per run.
Other upcoming changes will greatly reduce that 0.4 seconds, but still
returning to the main-loop after a single udev event so that we can
answer any waiting boot-clients ASAP is a good idea.
This reverts commit f9e376797a.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If the end-animation is disabled then directly becoming idle on halt /
reboot leads to no animation at all being shown.
Fix this by not jumping to the end-animation on halt/reboot if the
end-animation is disabled.
Fixes: 50c619ed41 ("two-step: Add UseEndAnimation setting")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
All plymouth's systemd unit files are meant to only run once, either during
boot or during shutdown/restart.
Certain events cause systemd to recheck the dependency try between systemd
units. Systemd had a bug before the 245 release which caused this check to
sometimes not restart exited services for which the dependencies are met.
Systemd 245 fixes this, this is causing problems with plymouth.
When the conditions are met for systemd to recheck the dependencies;
and the plymouthd started by plymouth-start.service has exited;
then systemd will restart the plymouth-start unit, causing plymouthd to
take over tty1 after boot. This is causing various problems, also see:
https://bugzilla.redhat.com/show_bug.cgi?id=1803293
Since all plymouth's systemd units are intended to run only once, they
all should be marked as remaining after exit by adding:
"RemainAfterExit=yes" to them. This causes systemd to still consider them
running after e.g. plymouthd has exited, as long as they have started
successfully. This fixes systemd restarting plymouth's units when it
should not do so.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1803293
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1807771
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We try to start the end animation early based on our progress accounting
but this is highly unreliable because e.g.:
-It counts time to enter the diskcrypt passwd as normal boot time, while
this varies wildly from boot to boot
-Boot times for laptops can differ significantly between docked / undocked
state
Between gdm calling /bin/plymouth deactivate and the drm plugin's deactivate
method getting called there can be e.g. 2.1 seconds (from a random boot),
with a theoretical maximum of 3 seconds (2 seconds to finish the throbber +
1 second for the end animation).
On a modern system userland boot should be able to finish in say 5 seconds,
making gdm wait an additional 1 - 3 seconds for deactivation is a huge amount
of extra wait time!
This commit adds a new "UseEndAnimation" option to the two-step plugin,
which defaults to true. Setting this to false makes deactivation immediate.
This works nicely with the spinner (and bgrt) themes since we do not really
do anything special in the end animation there anyways and since we fade-over
into gdm things will still look ok, while shaving a signifcant chunk of our
boot time.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The script plugin currently allows pixel buffers to be resized and
scaled, but provides no mechanism for script theme authors to just crop
the buffer, which is necessary for images that cannot be stretched,
such as progress bars with gradients.
This commit adds that feature as a new Crop method.
One case where the various widgets are being freed is the pixel-display-s
being removed because of a monitor being hot(un)plugged. When the monitor
configuration changes ply-device-manager removes all old pixel-displays
and then adds the pixel-displays from the new config.
Calling ply_pixel_display_draw_area on a pixel-display which is about to be
freed is a bad idea, if the monitor was actually unplugged this leads to
various sort of errors, including crashes in some cases.
ply-throbber is the only (older) widget which does a redraw on free,
this likely was not noticed until now because typically the throbber
will already have been stopped on free.
This commit adds a redraw parameter to ply_throbber_stop_now and sets
this to false when calling ply_throbber_stop_now from ply_throbber_free.
This fixes plymouth sometimes crashing when monitors are hot(un)plugged
while plymouth is running.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
