Hi,
On 6/30/20 11:36 AM, Lennart Poettering wrote:
On Mo, 29.06.20 11:02, Hans de Goede (hdego...@redhat.com) wrote:
Hi All,
For Fedora 33 I would like to get rid of some ugly hacks we have
wrt the grub-hidden-menu feature Fedora has been shipping for a
while now.
One part of this will be setting SYSTEMD_REBOOT_TO_BOOT_LOADER_ENTRY
in logind's environment, and add /run/systemd/reboot-to-boot-loader-menu
support to the Fedora grub-packages (the hidden-boot-menu stuff is
not in upstream grub yet) and make GNOME use the dbus protocol to
request rebooting into the boot menu.
Another, harder part is boot-success or in systemd terms boot-complete
support. ATM the Fedora GNOME packages contain a downstream patch
which directly invokes "grub2-set-bootflag boot success". The plan
is to have a grub2-bless-boot.service which will be a copy of
systemd-bless-boot.service which will do grub's equivalent of
calling /usr/lib/systemd/systemd-bless-boot good (we do not
want automatic-boot-assesment, we just want the menu to show or
not show on the next boot). This bit is east too.
The tricky part is having grub2-bless-boot.service not run until
GNOME says that it is ok. The thinking behind this (and current
behavior) is that even if everything looks ok from the all services
are running pov, then things might still be wrong. E.g. the kbd
and mouse could be non-functional leaving the user with a
non-functional system. So we only want to mark the boot successful
after:
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.
Currently for "boot-success" marking we rely on confirmation
of successful interaction with the user (so working gfx output
+ kbd + mouse) and we want to keep doing that.
If we remove the timeout from your proposal then it should work fine
though.
So I think we agree on needing a tiny service for this, which
gets contacted by the GNOME session when the GNOME session
considers the boot successful. The main difference between
our proposals seems to be that I want to add the service to
the boot-complete.target and you suggest adding it to the
usual boot process, which I assume would be multi-user.target.
To me adding it to boot-complete.target feels like it makes
more sense, since the whole purpose of the mini service is
just to delay boot-blessing, and AFAIK that is exactly what
boot-complete.target is for ?
Regards,
Hans
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
