On Di, 12.06.18 11:33, Hans de Goede (hdego...@redhat.com) wrote: > > I figure gdm could > > try to expose that feature somewhere, maybe in the top-right menu or > > so? > > Yes I need to talk to the GNOME designers about adding some advanced > reboot options somewhere: > > 1) Reboot into firmware setup > 2) Show boot menu next menu > > Any others?
I wouldn't know any. > I'm thinking myself to do something like what Windows does (assuming > that will help with discoverability) where shift + click on reboot shows > this menu. Makes sense. > > I figure if there's need for it we could even have some mini daemon > > whose only job is to provide a reboot-into-firmware hotkey during > > early boot time. i.e. something that just listens to some otherwise > > silent keycombo (maybe shift+alt+ctrl), and when it's pressed within > > the first minute of bootup we'll instantly reboot into firmware or > > so... In theory that could even be systemd-logind (which already > > watches input devices for SW_DOCK and SW_LID events), but logind is > > started quite late, hence maybe a seperate mini daemon might be > > wise... > > Hmm, how soon during boot is the ctrl+alt+up target available ? as soon as PID 1 initialized, and that includes the initrd if the initrd runs systemd (and fedora's does). > We could add a .service file there which forces showing the grub > menu next time (and the grub menu will also allow entering > firmware). That's an option, indeed. > > > If I understand correctly systemd will start all services under: > > > /lib/systemd/system/system-update.target.wants one by one and > > > the service to mark the boot indeterminate should exit with an > > > error since it is not the one handling the updates (that is fine), > > > but if the actual update service runs before us then we won't > > > run. > > > > > > I could modify all the services under > > > /lib/systemd/system/system-update.target.wants > > > with an ExecStartPre to call grub2-editenv but I would prefer > > > a generic solution, any suggestions here ? > > > > Not sure I follow. I mean, setting the state to "indeterminate" should > > happen whenever the offline update operation succeeded, no? If the > > offline update operation fails then this should be counted as a bad > > boot, no? As such your little plugin should run after > > system-update.target, exactly like in the default.target regular boot > > case? > > AFAIK the service actually doing the updates is supposed to call > systemctl reboot --force when it is done, so any targets after > system-update.target won't get started ? True, the service in question could split the reboot call of course, if it wanted, so that you can plug things in between. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
