We assume /proc/cmdline will be no more than 512 bytes (including NUL).
It can actually be 4096 bytes (excluding NUL).
This commit makes sure we allocate enough space for it and its NUL.
At the moment, we don't bother showing the splash
screen if init=/bin/sh since we assume the user
wants to be see the shell prompt.
The problem is, since we don't show a splash screen
we don't handle LUKS in the initrd.
This commit makes us show the splash for the duration
of the initrd but quit on switch root.
This reverts commit 7adb50c267.
The .service files are already statically enabled, adding the Install
section and the WantedBy option is useless
Conflicts:
systemd-units/plymouth-quit-wait.service.in
https://bugs.freedesktop.org/show_bug.cgi?id=80048
For some reason in commit 113526408c
I commited the sequence \x25\x96\xa0 in place of the block character
that was there before. I don't know where I got \x25 from, but it's
not right (and couldn't even be right since the high order bit isn't
set which is a requirement for the first byte in multi-byte utf-8
sequences).
This commit uses \xe2 instead which I got from doing:
$ echo ■ | xxd
0000000: e296 a00a ....
We can end up in a situation where a seat object doesn't have a terminal
associated with it. In that case we shouldn't crash, but continue on
with no input available for that seat.
https://bugs.freedesktop.org/show_bug.cgi?id=80553
Due to removed interfaces since 0.8.8:
ply_boot_splash_set_keyboard
ply_boot_splash_unset_keyboard
ply_boot_splash_add_pixel_display
ply_boot_splash_remove_pixel_display
ply_boot_splash_add_text_display
ply_boot_splash_remove_text_display
And a bunch of new ones added.
plymouth-quit-wait.service is a synchronization point that
other services tie into, so they know when boot is finished
and the splash is down.
Unfortunately, in cases where the boot stalls, the last thing
users see is:
Starting Wait for Plymouth Boot Screen to Quit...
and then assume the problem is with the boot splash.
This commit makes the description less finger-pointy.
systemd doesn't block waiting for a reply to its update request, since
it would pointlessly slow down boot up.
This commit makes sure we don't bother logging that case.
This patch adding support for operation log messages and updating upstart
bridge code to use it. This is usefull for verbose log output (e.g daemon
starting, stopping).
Example:
Register operation ssh:
$ plymouth register-operation --operation-id=ssh --name='Starting OpenSSH server ssh'
Set state of operation ssh to wait:
$ plymouth update --operation-id=ssh --status="wait"
Details plugin will show: 'Starting OpenSSH server ssh... [wait]'
Set state of operation ssh to done:
$ plymouth update --operation-id=ssh --status="done"
Details plugin will show: 'Starting OpenSSH server ssh... [done]'
Unregister operation ssh:
$ plymouth unregister-operation --operation-id=ssh
https://bugs.freedesktop.org/show_bug.cgi?id=77389
This reverts commit 8c267e9a3b.
I think this patch was accidentally pushed, since the commit date is
years older than the push date, and it seems to overlap in already
existing pid-file functionality.
If we actually do need this commit we can always add it back of course.
If we have a pixel display, the renderer will handle opening the
associated terminal. but if we don't have a pixel display, something
needs to open the terminal.
This commit adds code to do that.
we need to call update display any time a splash is shown,
because there may be a pending password request.
The code attempted to do this in show_splash, but did it before
the splash was assigned to running state, so function was a noop.
This commit moves it a little later in code after the splash is
properly assigned.
Right now we use the heuristic, "more than one entry in
/sys/class/tty/console/active" to mean "has serial consoles".
We used to use the heuristic "file has more than tty0 in it".
The older heuristic is more accurate because a user may have
console=ttyS0 without console=tty0 on the kernel command line.
We never want to use a /dev/fb device if a DRM device will work instead
(since it supports multi-monitor, isn't a legacy interface, etc)
Unfortunately, right now plymouthd notices efifb at early start up,
see's there is no DRM device associated with it and chooses it for
the main display, which causes all sort of problems.
This commit defers using /dev/fb devices until after udev settles.
Right now, we piggyback off fb subsystem events to know whether or
not a drm device is hotplugged (since all drm devices have fb devices
for backward compat).
This commit makes drm and fb processing more independent, so we don't
rely on the compat device being available for drm hotplug to work..
We used to use plymouth:debug to enable debugging in the
plymouth daemon, and changed it to plymouth.debug to be more
consistent with other users of the kernel command line.
We neglected to update the client to support the new format
though. This commit does that.
Currently plymouth stays in control of the terminal
after hide-splash. This is wrong. Once plymouth is
hidden, the terminal should be free to use for other
programs.
This commit makes sure we free up the terminal on
hide splash.
This fixes a race/crash where plymouthd get deactivated
right before the show timer fires and it tries to
show itself after things have been torn down.
It was a weird to show something in a function called "cancel..show"
Instead move the logic to the one caller that actually needed that
functionality (on_ask_for_password)
If plymouth is configured --with-system-root-install=no then the
systemd unitd files will write the paths of plymouth and plymouthd
relative to /usr . The script currently hardcodes installing them
to the initrd's /
This commit makes sure they get placed on the same part of the of
the initrd filesystem as systemd expects to find them.
https://bugs.freedesktop.org/show_bug.cgi?id=74174
If a seat gets opened with a renderer type of AUTO, and the renderer
fails to open, then it's okay and expected to proceed without a
renderer (and just use the terminal). The code attempted to do this
but failed to nullify the seat->renderer object, so it ended up
going down the renderer-active code path.
This commit fixes that.
There's no point in waiting for a graphics device if details are
forced, and we shouldn't ever delay showing details. If details
are requested, we shouldn't be hiding them.
