Hans de Goede [Sat, 27 Mar 2021 12:20:29 +0000 (13:20 +0100)]
main: Redirect stdio/stderr to null when tracing to a file
When the user has chosen to enable tracing to a file, so that the terminal
output stays the same as when not tracing, we should still redirect
tdio/stderr to /dev/null as we do when not tracing.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 27 Mar 2021 12:07:32 +0000 (13:07 +0100)]
ply-logger: Add a ply_is_tracing_to_terminal () helper
Track if we are logging to the terminal (or to a file) and add
a new ply_is_tracing_to_terminal () helper.
This will be used in follow-up patches to replace some
ply_is_tracing () checks for things which should only be done
when tracing to a terminal (and not when tracing to a file).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Gaël PORTAY [Fri, 18 Dec 2020 11:24:09 +0000 (06:24 -0500)]
main: Retain splash on on_show_splash() and on_hide_splash()
The function ply_device_manager_activate_keyboard() asserts for positive
file-descriptors.
However, the daemon aborts after the splash screen is shown again after
being hidden; the virtual terminal file-descriptor is -1 (i.e. plymouth
show-splash; plymouth hide-splash; plymouth-show-spash).
The three helpers on_show_splash(), on_hide_splash() and on_quit() share
the same function dump_details_and_quit_splash().
This function calls on_hide() and on_quit(); the later deallocates and
closes the virtual terminal if the flag should_retain_splash is not set.
This is always the case on both on_show_splash() and on_hide_splash().
Only on_quit() has the ability to set that flag. Therefore, the virtual
terminal is always deallocated and closed on on_hide_splash (), and in a
some condition on on_show_splash().
The virtual terminal is allocated by ply_device_manager_new() in the
function main() and it is deallocated in the function quit_program()
(i.e. at the begining and at the end of the daemon). The function
quit_program() is called either by on_quit() or by on_boot_splash_idle()
(on quit only, not on deactivate). The two helpers on_show_splash() and
on_hide_splash() *MUST NOT* dealocates and closes the virtual terminal.
This sets the flag should_retain_splash in both helpers on_show_splash()
and on_hide_splash() to prevent them from deallocation the virtual
terminal.
Fixes:
01:24:16.983 ply-event-loop.c:732:ply_event_loop_watch_fd : fd: 9
01:24:16.994 ply-boot-server.c:393:print_connection_process_identity : connection is from pid 8474 (plymouth show-splash) with parent pid 2137 (-ash)
01:24:16.994 ply-boot-server.c:492:ply_boot_connection_on_request : got show splash request
01:24:16.994 main.c:832:plymouth_should_ignore_show_splash_calls : checking if plymouth should be running
01:24:16.994 main.c:933:on_show_splash : at least one display already available, so loading splash
01:24:16.994 main.c:864:plymouth_should_show_default_splash : checking if plymouth should show default splash
01:24:16.994 main.c:892:plymouth_should_show_default_splash : using default splash because kernel command line has option "splash"
01:24:16.994 main.c:445:show_default_splash : Showing splash screen
01:24:16.994 main.c:459:show_default_splash : Trying distribution default splash
01:24:16.994 main.c:1692:load_theme : Loading boot splash theme '/usr/share/plymouth/themes/spinner/spinner.plymouth'
01:24:16.995 ply-key-file.c:175:ply_key_file_load_group : trying to load group Plymouth Theme
01:24:16.995 ply-key-file.c:175:ply_key_file_load_group : trying to load group two-step
01:24:16.995 ply-key-file.c:175:ply_key_file_load_group : trying to load group boot-up
01:24:16.995 ply-key-file.c:175:ply_key_file_load_group : trying to load group shutdown
01:24:16.995 ply-key-file.c:175:ply_key_file_load_group : trying to load group reboot
01:24:16.995 ply-key-file.c:175:ply_key_file_load_group : trying to load group updates
01:24:16.995 ply-key-file.c:175:ply_key_file_load_group : trying to load group system-upgrade
01:24:16.996 ply-key-file.c:175:ply_key_file_load_group : trying to load group firmware-upgrade
01:24:16.996 ply-key-file.c:262:ply_key_file_load_groups : key file has no more groups
01:24:16.996 plugin.c:1030:create_plugin : Using '/usr/share/plymouth/themes/spinner' as working directory
01:24:16.996 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'ProgressBarHorizontalAlignment'
01:24:16.996 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'ProgressBarVerticalAlignment'
01:24:16.996 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'ProgressBarWidth'
01:24:16.996 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'ProgressBarHeight'
01:24:16.996 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'SuppressMessages'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'ProgressBarShowPercentComplete'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseProgressBar'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseFirmwareBackground'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'Title'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'SubTitle'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'SuppressMessages'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'ProgressBarShowPercentComplete'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseProgressBar'
01:24:16.997 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseFirmwareBackground'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'Title'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'SubTitle'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'SuppressMessages'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'ProgressBarShowPercentComplete'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseProgressBar'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseFirmwareBackground'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'Title'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'SubTitle'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseFirmwareBackground'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseFirmwareBackground'
01:24:17.331 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'UseFirmwareBackground'
01:24:17.332 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'DialogClearsFirmwareBackground'
01:24:17.332 ply-key-file.c:359:ply_key_file_get_raw_value : key file does not have entry for key 'ProgressFunction'
01:24:17.332 main.c:1708:load_theme : attaching plugin to event loop
01:24:17.332 main.c:1711:load_theme : attaching progress to plugin
01:24:17.332 ply-boot-splash.c:138:ply_boot_splash_add_pixel_display : adding 1920x1080 pixel display
01:24:17.332 plugin.c:1563:add_pixel_display : adding pixel display to plugin
01:24:17.332 ply-device-manager.c:1028:ply_device_manager_activate_renderer: activating renderers
01:24:17.332 plugin.c:918:activate : taking master and scanning out
01:24:17.332 ply-terminal.c:242:ply_terminal_unlock : couldn't unlock terminal settings: Bad file descriptor
01:24:17.332 plugin.c:693:ply_renderer_head_set_scan_out_buffer : Setting scan out buffer of 1920x1080 head to our buffer
01:24:17.333 plugin.c:1693:flush_head : Needed to reset scan out buffer on 1920x1080 renderer head
01:24:17.334 ply-boot-splash.c:486:ply_boot_splash_show : showing splash screen
01:24:17.334 plugin.c:1621:show_splash_screen : loading lock image
01:24:17.335 plugin.c:1626:show_splash_screen : loading box image
01:24:17.335 plugin.c:1635:show_splash_screen : loading corner image
01:24:17.335 plugin.c:1644:show_splash_screen : loading header image
01:24:17.335 plugin.c:1653:show_splash_screen : loading background tile image
01:24:17.335 plugin.c:1681:show_splash_screen : loading watermark image
01:24:17.335 plugin.c:615:view_load : loading entry
01:24:17.340 ply-keymap-icon.c:158:ply_keymap_icon_load : loading '/usr/share/plymouth/themes/spinner/keyboard.png': success
01:24:17.495 ply-keymap-icon.c:165:ply_keymap_icon_load : loading '/usr/share/plymouth/themes/spinner/keymap-render.png': success
01:24:17.496 plugin.c:625:view_load : loading progress animation
01:24:17.497 ply-progress-animation.c:373:ply_progress_animation_add_frames: could not find any progress animation frames
01:24:17.497 plugin.c:627:view_load : optional progress animation wouldn't load
01:24:17.498 plugin.c:636:view_load : loading throbber
01:24:17.531 plugin.c:1697:show_splash_screen : starting boot animations
01:24:17.531 plugin.c:1336:start_progress_animation : starting animation
01:24:17.587 ply-terminal.c:242:ply_terminal_unlock : couldn't unlock terminal settings: Bad file descriptor
01:24:17.599 ply-terminal.c:242:ply_terminal_unlock : couldn't unlock terminal settings: Bad file descriptor
01:24:17.599 ply-device-manager.c:1061:ply_device_manager_activate_keyboard: activating keyboards
Assertion failed: fd >= 0 (ply-event-loop.c: ply_event_loop_watch_fd: 732)
Aborted
Gaël PORTAY [Fri, 18 Dec 2020 17:12:54 +0000 (12:12 -0500)]
two-step: Links against libintl.so if LNS
The plugin two-step cannot be loaded on a system based on the musl libc
library.
01:25:00.427 ply-utils.c:536:ply_open_module : Could not load module "/usr/lib/plymouth/two-step.so": Error relocating /usr/lib/plymouth/two-step.so: libintl_dgettext: symbol not found
The utilities ldd and objdump reports the missing symbol:
The story is much complicated, however, the autotools does the magic.
The GNU gettext FAQ[1] says explicitly that if the program's final link
command does not contain the option -lintl...
> In this case it's likely a bug in the package you are building: The
package's Makefiles should make sure that “-lintl” is used where needed.
Autoconf sets both variables LIBINTL and LTLIBINTL with the appropriate
link options if NLS is being used. These variables are left empty if the
option --disable-nls is set at the configure step.
This links the plugin two-step to libintl by adding the libtool variable
LTLIBINTL to the list of the plugin's libraries to link with.
Note: The plugin two-step loads fine on a system based on the glibc
library (without this commit). The plugin uses the intermediate symbol
dcgettext which is implemented by the glibc instead of the remapped
symbol libintl_gettext which is implemented by gettext in libintl.
However, this commit changes nothing for system based on glibc as the
magic of the Autoconf leaves the LIBINTL and LTLIBINTL empty even if the
NLS is being used.
A S Alam [Wed, 3 Mar 2021 20:47:31 +0000 (21:47 +0100)]
Translated using Weblate (Punjabi)
Currently translated at 100.0% (7 of 7 strings)
Co-authored-by: A S Alam <amanpreet.alam@gmail.com>
Translate-URL: https://translate.fedoraproject.org/projects/plymouth/master/pa/
Translation: plymouth/master
Wolfgang Haupt [Wed, 3 Mar 2021 15:06:37 +0000 (16:06 +0100)]
The use of AM_GNU_GETTEXT_VERSION in configure.ac instructs autopoint to
copy po/Makefile.in.in from the exact gettext version. It is fine if the
version of gettext installed on the system has the same minor version
number with the requested version, but it fails if you have a newer
version of gettext because of the mismatch between autoconf macros and
Makefile.in.in.
*** error: gettext infrastructure mismatch: using a Makefile.in.in
from gettext version 0.19 but the autoconf macros are from gettext
version 0.20
Instead of specifying the exact version with AM_GNU_GETTEXT_VERSION, we
can use AM_GNU_GETTEXT_REQUIRE_VERSION to ask autopoint to simply use
the gettext version installed on the system to prevent the mismatch.
Hans de Goede [Fri, 5 Mar 2021 11:25:36 +0000 (12:25 +0100)]
ply-device-manager: Speed up DRM-connector probing
During the initial monitor/connector enumeration on boot the kernel
fires a large number of change events. If we process these 1 by 1,
we spend a lot of time probing the DRM-connectors. So instead we
collect them all and then coalescence them so that if there are multiple
change events pending for a single card, we only re-probe the card once.
Here are some numbers of the probing times before / after this patch:
1. Lenovo X1 carbon 8th gen connected to a Lenovo Thunderbolt dock gen 2
with 2 FullHD monitors connected:
Before: add event card0: 00:00:02.543 last change complete at: 00:00:04.250,
12 change events processed, 13 probes done!
After: add event card0: 00:00:02.548 last change complete at: 00:00:04.049
1 change event processed, 2 probes done!
2. Intel skylake CPU + iGPU based desktop with 2 FullHD monitors connected:
Before: add event card0: 00:00:02.394 last change complete at: 00:00:05.024,
5 change events processed, 6 probes done!
After: add event card0: 00:00:02.343 last change complete at: 00:00:03.744,
1 change event processed, 2 probes done!
In the Thunderbolt dock case we probe the DRM-connectors 2 times instead
of 13 times after this change. This does not lead to a big speed-up though
because the dock caches the monitors EDID info and the DP aux channel to
the dock is quite fast.
In the desktop case we only reduce the amount of probes from 6 to 2, so
less then in the Thunderbolt dock case, but since we don't have the EDID
caching happening there this does reduce the time which it takes to probe
the DRM-connectors from 2.6 seconds to 1.4 seconds which is a huge
improvement.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 5 Mar 2021 11:20:52 +0000 (12:20 +0100)]
ply-device-manager: add a verify_add_or_change() helper
Add a verify_add_or_change() helper function. This is a preparation
patch for coalescing multiple change events on the same card together
to speed up probing of the drm connectors.
Note this causes the action == "add" || action == "change" check to
be done twice. This double checking goes away in the next patch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 28 Sep 2020 13:04:11 +0000 (15:04 +0200)]
ply-device-manager: push udev_device_get_devnode call up into on_udev_event
on_udev_event calls either on_drm_udev_add_or_change; or
free_devices_for_udev_device. Both of these functions call
udev_device_get_devnode and are a no-op if that returns NULL.
Cleanup things by directly calling udev_device_get_devnode from
on_udev_event and exit eary if the udev_device does not have
an associated devnode.
With the udev_device_get_devnode call handled by on_udev_event,
all that is left of free_devices_for_udev_device is a single
line calling free_devices_from_device_path. So drop
free_devices_for_udev_device and directly call
free_devices_from_device_path from on_udev_event.
Note this also fixes a theoretical udev_device reference leak
in the action == NULL early-exit path. In practice action never
is NULL, so this was not really a problem. But in the refactored
code we now also do the early-exit on dev_path == NULL which does
actually happen.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 5 Mar 2021 10:57:53 +0000 (11:57 +0100)]
two-step: Always load the BGRT fallback image
view_set_bgrt_background() can fail even if the BGRT image was loaded
successfully. So we may need the fallback image even though the
BGRT image was loaded successfully.
This commit also fixes plugin->background_bgrt_fallback_image not being
free-ed and set to NULL when loading the fallback image fails.
Note this also drops the clearing of the use_firmware_background flagss
when we fail to load both the BGRT and the fallback images. Clearing
these flags is not necessary. They are only checked if
plugin->background_bgrt_image or plugin->background_bgrt_fallback_image
are non NULL; and if the loading of both images failed then both
are NULL.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Ray Strode [Tue, 25 Aug 2020 14:49:11 +0000 (10:49 -0400)]
systemd: switch to KillMode=mixed
KillMode=none is deprecated, so we need to stop using it.
For now, use `KillMode=mixed` and `IgnoreOnIsolate=true` instead.
In the future, we should change plymouth to be able to exit and
start again without restarting the active animation, but that's
going to require some effort.
Brian Murray [Mon, 26 Oct 2020 19:13:20 +0000 (20:13 +0100)]
Don't wait forever for a ping reply.
In the event that plymouthd is not responding the plymouth client will wait
forever when sending a ping to the daemon. Instead of waiting forever timeout
after a while.
Charles Lee [Fri, 25 Sep 2020 11:29:43 +0000 (13:29 +0200)]
Translated using Weblate (Chinese (Simplified))
Currently translated at 71.4% (5 of 7 strings)
Co-authored-by: Charles Lee <lchopn@gmail.com>
Translate-URL: https://translate.fedoraproject.org/projects/plymouth/master/zh_CN/
Translation: plymouth/master
Ray Strode [Wed, 2 Sep 2020 17:44:37 +0000 (13:44 -0400)]
boot-server: Handle client disconnecting while trigger pending
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.
Hans de Goede [Sun, 10 Nov 2019 17:23:27 +0000 (18:23 +0100)]
drm: Honor modes selected by the user through video= kernel cmdline argument
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>
Sebastien [Thu, 6 Aug 2020 11:52:01 +0000 (11:52 +0000)]
Initialize the translations on start if they are available
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.
Daniel van Vugt [Fri, 17 Apr 2020 09:27:12 +0000 (17:27 +0800)]
main: Don't bail out of load_settings if "Theme" is missing
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.
Ray Strode [Thu, 26 Mar 2020 18:11:50 +0000 (14:11 -0400)]
main: switch log file when switching mode
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.
Hans de Goede [Tue, 24 Mar 2020 22:17:42 +0000 (23:17 +0100)]
drm: Do not unnecessarily get output info twice
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>
Hans de Goede [Mon, 23 Mar 2020 16:38:18 +0000 (17:38 +0100)]
ply-device-manager: Only consume one udev event at a time
Commit f9e376797a91 ("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:
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.
Hans de Goede [Mon, 23 Mar 2020 14:59:24 +0000 (15:59 +0100)]
Add RemainAfterExit=yes to plymouth's systemd service files
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:
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.