[systemd-devel] [PATCH 1/2] systemctl: Add reboot to firmware support

[Dimitri John Ledkov]

On 17 March 2015 at 12:58, Jan Janssen <medhefgo at web.de> wrote:
>
>
>> Gesendet: Dienstag, 17. März 2015 um 13:41 Uhr
>> Von: "Dimitri John Ledkov" <dimitri.j.ledkov at intel.com>
>> An: "Jan Janssen" <medhefgo at web.de>
>> Cc: "systemd Mailing List" <systemd-devel at lists.freedesktop.org>
>> Betreff: Re: [systemd-devel] [PATCH 1/2] systemctl: Add reboot to firmware support
>>
>> On 17 March 2015 at 12:12, Jan Janssen <medhefgo at web.de> wrote:
>> > Dimitri John Ledkov <dimitri.j.ledkov <at> intel.com> writes:
>> >
>> >> Both gummyboot and grub-efi have a menu option to reboot into
>> >> firmware, is that not enough? Why do we need to have it from userspace
>> >> / the booted system?
>> >>
>> >
>> > There can be plenty of reasons why the firmware won't provide you with an
>> > option. One of them being a FastBoot implementation that doesn't initialize
>> > USB input devices. And also, if one were to directly boot from the efi stub
>> > without boot loader (and not getting 5000€ in the process).
>> >
>> > But this is primarily a reason of convenience. If your bootloader doesn't
>> > give you a boot to firmware option, or your bootloader is being annoying and
>> > boots to your OS faster than you can interface with it, you're currently out
>> > of luck. I'm not too sure, but grub-efi probably even requires you to
>> > actually specifically create the entry in the configuration; and touching
>> > the grub config is just plain annoying. Especially if you just want that
>> > entry for the one time EFI setup every once in a blue moon.
>> >
>> > Also, the fact that there have been people asking questions about how to get
>> > to the EFI/BIOS has always been there. With this you can just tell them to
>> > "systemctl --firmware reboot" on any modern computer and be done with it.
>>
>> Then wouldn't we want to support it generically in src/core/shutdown.c
>> / systemctl halt_now and expose it via logind API somehow as well?
>
> Someone already did something like that a year ago, with no real response:
> http://lists.freedesktop.org/archives/systemd-devel/2013-January/008216.html
>

Thanks for pointer. I like that, cause it adds both a --firmware flag
to reboot and an explicit firmware action with exposure over DBus.
Maybe we can just rebase that on to the current source tree?

>> In some ways it is similar to REBOOT_PARAM_FILE handling for the
>> SYS_reboot syscall, e.g. on Nexus devices $ reboot bootloader ->
>> reboots one into firmware (there is also usually "recovery" reboot
>> argument support).
>
> When looking at the code I did consider consuming the reboot param, but since I don't
> know anything about I, I wouldn't know if that would break any existing use cases.
>

Even if we implement and reserve "efi-reboot" for this thing, older
systemctl's will not have it and will pass that arg to the reboot
syscall, which will be written out. In best case scenario one would
end up simply rebooting or have some undefined behaviour.

>> This efi reboot is useful functionality, but if it's only hidden
>> inside systemctl invocation, it would hard to integrate via e.g. DBus
>> api calls from GUI application.
>
> I feel like doing it that way is just overcomplicating things. Exposing it so easily to GUI
> applications is mostly a waste of time for the rare occasion that it would get used.
>

Hehe, In Ubuntu we have UX designs for this and we actually want to
expose it in the UI. Because UEFI grub menu is clunky and that's where
"reboot to firmware" is currently exposed.

>> Can this be piggybacked on to reboot command arg?
>>
>> $ systemctl reboot efi-firmware
>>
>> same way that $ systemctl reboot bootloader is already supported (on
>> platforms that support that arg)
>
> That's an option, but is there any EFI system out there that already consumes the
> parameter itself? I don't know, but is so, we can't consume it ourselves.
>
>> Looking at Logind1 Api Reboot() it does not accept string argument
>> there. RebootWithArg() or SetRebootParam() calls would be nice as
>> well.
>>
>
> Jan



-- 
Regards,

Dimitri.

Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.