[systemd-devel] GNOME boot-complete.target integration ?

[Hans de Goede]

Hi,

On 7/14/20 10:03 AM, Lennart Poettering wrote:
> On Di, 30.06.20 12:17, Hans de Goede (hdegoede at redhat.com) 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