GNU GRUB - Bugs: bug #61522, Expose a command to set the UEFI...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61522: Expose a command to set the UEFI variable BootNext
Submitter: | David Ward <dpward> | ||
Submitted: | Mon 22 Nov 2021 04:12:47 AM UTC | ||
Category: | Booting | Severity: | Major |
Priority: | 5 - Normal | Item Group: | Feature Request |
Status: | None | Privacy: | Public |
Assigned to: | None | Originator Name: | David Ward |
Open/Closed: | Open | Release: | Git master |
Release: | Reproducibility: | None | |
Planned Release: | None |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
It is documented that the 'chainloader' command does not work with UEFI Secure Boot. In particular, this affects booting Windows with a BitLocker-encrypted partition. os-prober will detect the Windows installation and create a GRUB menu entry for it using 'chainloader'; but the user will be prompted for the BitLocker recovery key when choosing this entry.
As an alternative to chainloading, GRUB should provide a way to set the UEFI variable BootNext to a specific UEFI boot entry (such as the Windows Boot Manager). Then GRUB can reboot the system, and this entry will be selected automatically during the next boot. This would avoid the issue with BitLocker described above.
This could either be exposed as a new GRUB command, or as an optional parameter to the 'reboot' command on EFI systems. The existing function grub_efi_set_variable() can be used to achieve this.