Hi,
On 7/14/20 10:03 AM, Lennart Poettering wrote:
On Di, 30.06.20 12:17, Hans de Goede (hdegoede@xxxxxxxxxx) wrote:
1. The user has logged in successfully and the session lasts
at least 2 minutes (could be a bit shorter, we want to catch the
case where the session immediately exits / crashes after login); or
2. The user selects reboot/shutdown from the GNOME system-control
menu.
In both these cases we want to block the boot-complete.target
from being considered finished/ready until GNOME says it is.
I can easily achieve this by not adding the grub2-bless-boot.service
to any targets, and then manually starting it (with a polkit rule to
allow a regular user to do this) when either condition becomes true,
but then I still have the GNOME code doing something grub (Fedora's
grub even) specific. So what I really want to do is delay the
the boot-complete.target from being considered finished/ready until
GNOME says it is.
So the question really is, is there a way to have a unit wait with
starting until a certain event happens?
I guess I could use a Oneshot type service and have a little helper app
which waits until it is signalled that the boot is complete? Any other
ideas?
Why not have a tiny service that is started as part of boot. It hangs
around for 2min or, and then exits with failure. If however it is
contacted by D-Bus before that it exist immediately with
success. Then, make GNOME just ping that service if all is good.
The service would then become part of the usual boot process, ordered
before the boot blessing.
Wouldn#t that suffice?
That will break in the following scenario:
1. User powers on the machine goes to grab coffee
2. User returns after 5 min. logs in and goes to work
Notice that the contacting by DBUS you suggest would not happen
until after 2, at which point the timeout has happened.
So on the low level we actually have a concept for marking a boot as
"neutral", but I think we only expose that in sd-boot, and
badly. i.e. the idea is that a boot can be considered "bad", "good" or
"neutral". I guess we could model things for you so that initially the
boot is marked as "bad", up to the point where gdm decides it
managed to start up. In that case we'd mark things as "neutral". As
soon as gdm then received user input so that the log in starts, it
would mark things as "bad" again. And when GNOME in the user's session
finally is done with everything we'd mark things as "good" and
everything is complete.
From a boot loader that boots up and finds the boot success state as
"bad" it will increment the fail counter of the boot item. If it finds
it as "good" it will mark the boot item as "good" forever. But if it
finds it in "neutral" it will do neither.
Such a logic would work for you, right?
No I do not think such a logic would work for the current Fedora workstation
hidden menu stuff.
The good/neutral/bad way of thinking seems to be very much oriented around
the automatic fallback to a previous boot-loader-menu entry (typically
an older kernel, but could also be a whole other os with a/b booting).
But that is not how things currently work in Fedora Workstation and also
not a direction which we want to go in.
Currently Fedora WS hides the boot-menu be default, we do good/bad detection
to decide if need to show the menu on the next boot to give the user easy
access to it (without key pounding at boot) when the previous boot as bad.
That is all that is done, there is no automatic fallback and no permanently
marking boot-menu-entries as bad/good.
So to go to your example how this could work:
1. Early at boot something (e.g. the bootloader itself) marks the boot as bad
2. Once GDM starts mark the boot as neutral
3. Re-mark as bad before doing login
If we then lack a functioning keyboard due to driver issues
(which is rare but does happen), we never reach 3, the user then power-cycles
to recover and we see a neutral state and this don't show the menu ?
Your example could work for Fedora ws if we treat neutral the same as bad.
But this whole discussion seems somewhat orthogonal to the original problem.
I guess your idea behind this is to not delay the marking of neutral with
some helper as discussed before and to still reach boot-complete.target
once gdm starts without waiting for user input ?
But then how would gdm re-mark as bad when starting to login the user and
how would the user-session mark things as good, in a way that does not
require root rights ?
Regards,
Hans
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
