Hi,
On 11-06-18 13:31, Lennart Poettering wrote:
On Mo, 11.06.18 12:48, Hans de Goede ([email protected]) wrote:
Hi All,
So as you may have heard, I'm working on hiding the grub-menu
by default on single OS Fedora Workstation. Part of the plan
here is to detect if a previous boot was successful and
cleanly shutdown the machine and show the menu (not hide the
menu) if the previous boot has failed to set either the
boot_success or shutdown_success flags:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
So now I'm working on writing a unit file which will
be added to poweroff.target.wants, reboot.target.want,
etc. and which will call:
Uurks. Quite frankly, it appears strange to me to delay this for this
long. I mean we reworked most code that delayed worked to shutdown
like this these days to happen as early as possible to make sure we
don't lose state unnecessarily. For example the RTC syncing is
generally done when the RTC is changed instead of synced back during
shutdown. Hence, why not simply write this out when the boot is
successful?
There are 2 flags / grub environment variables in play here:
boot_success
shutdown_success
The idea being that we also want to show the grub menu if the
system did not shutdown cleanly (or somewhat cleanly given
that by the time we know we really have a clean shutdown we
can no longer write the grubenv).
E.g. the system hangs and the user presses the power-button for
4 seconds.
The feedback I've been getting on the fedora-devel list is that
people are somewhat worried about not being able to get to the
grub menu, so we are being very careful here and err-ing on the
side of showing the menu too often, rather then possibly not
often enough.
Note that /boot or /efi is very likely an automount point, (that's at
least how we recommend things to be set up, as this provides the best
guarantees that the ESP remains is a clean state, as it will be very
quickly after the last access, and hence only be in dirty state during
a very short timeframe around accesses), and in that case "right
before unmount" doesn't make much sense in general, as that would be
pretty much all the time (that said, I don't think fedora/Anaconda
makes use automount points for /boot and /esp, or even systemd's
auto-discovery of the ESP currently, they haven't seen the light there
yet, but they really really should)
Right Fedora still uses a regular fstab entry for the ESP and changing
that is out of scope for what I'm working on.
Hence, my recommendation would be: write a small service that is
pulled in by default.target, but orders itself after it. Then make
your changes from there. i.e. do it as final steps during boot, rather
than delay it to shutdown.
See above, currently this is for Fedora Workstation only, and the plan
is actually to do set boot_success from the systemd user session
(using pkexec with a user on console check to execute a new grub2-set-bootflag
binarty which only supports changing a limited no env variables),
so that we know that the user has actually logged in successfully
before setting the flag.
note that there have been plans of introducing some generic framework
for such "boot completion" tests, as it is useful for a number of
usecases, for example Atomic would like to use that. Such a framework
would be very minimal most likely: add a new generically named target,
before which all "is all good" checkers would be ordered, and after
which all "mark the boot as successful" servers ared ordered. Your
grub service would fit in perfectly in the latter then.
So something like this would make sense for server / container
scenarios but not really for Fedora WS, if gdm starts but the
keyboard is not functional so the user cannot log in we still
want to show the menu the next boot so that the user can say
try an older kernel.
And even in server / container scenarios ideally asserting
success would come from a service which checks that say a http
connection can be made or whatever depending on the role of
the server...
###
I cannot help but notice that you've not answered my original
question. So given that the plan is to have both a boot_success
and a shutdown_success flag how would you go about implementing
the service for this?
As explained my current plan is a grub_shutdown.service which gets
added to /lib/systemd/system/poweroff.target, etc. and has a:
Before=umount.target
But I'm thinking about also adding a:
After=shutdown.target
Which I think you won't like, in which case I can live with just
the Before=umount.target but I wonder what your thoughts are on
this?
Regards,
Hans
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
