On Mo, 11.06.18 12:48, Hans de Goede (hdegoede at redhat.com) 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? 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) 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. 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. Would love to take a patch adding that generic concept! Lennart -- Lennart Poettering, Red Hat