Select Git revision
Search by author
- Any Author
- authors
-
Carsten Schoenert
carsten.schoenert
-
Francois Techene
francois.techene
-
Guido Gunther
guido.gunther
-
Jeremiah Foster
jeremiah.foster
-
Jonathon Hall
jonathon.hall
-
Julian Sparber
julian.sparber
-
Matthias Klumpp
matthias.klumpp
-
Nicole Faerber
nicole.faerber
-
Sebastian Krzyszkowiak
sebastian.krzyszkowiak
-
Stelios Milidonis
stelios.milidonis
-
Theodotos Andreou
theodotos.andreou
- Sep 27, 2021
-
-
Javier Martinez Canillas authored
Commit f60ba9e5 (util/mkimage: Refactor section setup to use a helper) added a helper function to setup PE sections, but it caused regressions in some arches where the natural alignment lead to wrong section sizes. This patch fixes a few things that were caused the section sizes to be calculated wrongly. These fixes are: * Only align the virtual memory addresses but not the raw data offsets. * Use aligned sizes for virtual memory sizes but not for raw data sizes. * Always align the sizes to set the virtual memory sizes. These seems to not cause problems for x64 and aa64 EFI platforms but was a problem for ia64. Because the size of the ".data" and "mods" sections were wrong and didn't have the correct content. Which lead to GRUB not being able to load any built-in module. Reported-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by:
-
Ian Jackson authored
For complicated reasons, even if you have XSM/FLASK disabled (as is the default) the Xen build system still builds a policy file and puts it in /boot. Even so, we shouldn't be loading this in the usual non-"XSM enabled" entries. It doesn't do any particular harm but it is quite confusing. Signed-off-by:
-
Steve McIntyre authored
In this case, we need both the signed shim as /EFI/BOOT/BOOTXXX.EFI and signed Grub as /EFI/BOOT/grubXXX.efi. Also install the BOOTXXX.CSV into /EFI/debian, and FBXXX.EFI into /EFI/BOOT/ so that it can work when needed (*iff* we're updating the NVRAM). [cjwatson: Refactored also_install_removable somewhat for brevity and so that we're using consistent case-insensitive logic.] Bug-Debian: https://bugs.debian.org/930531 Last-Update: 2021-09-24 Patch-Name: grub-install-removable-shim.patch
-
Colin Watson authored
Some UEFI firmware is easily provoked into running out of space in its variable storage. This is usually due to certain kernel drivers (e.g. pstore), but regardless of the cause it can cause grub-install to fail because it currently asks efibootmgr to delete and re-add entries, and the deletion often doesn't result in an immediate garbage collection. Writing variables frequently also increases wear on the NVRAM which may have limited write cycles. For these reasons, it's desirable to find a way to minimise writes while still allowing grub-install to ensure that a suitable boot entry exists. Unfortunately, efibootmgr doesn't offer an interface that would let grub-install do this. It doesn't in general make very much effort to minimise writes; it doesn't allow modifying an existing Boot* variable entry, except in certain limited ways; and current versions don't have a way to export the expected variable data so that grub-install can compare it to the current data. While it would be possible (and perhaps desirable?) to add at least some of this to efibootmgr, that would still leave the problem that there isn't a good upstreamable way for grub-install to guarantee that it has a new enough version of efibootmgr. In any case, it's cumbersome and slow for grub-install to have to fork efibootmgr to get things done. Fortunately, a few years ago Peter Jones helpfully factored out a substantial part of efibootmgr to the efivar and efiboot libraries, and so it's now possible to have grub-install use those directly. We still have to use some code from efibootmgr, but much less than would previously have been necessary. grub-install now reuses existing boot entries where possible, and avoids writing to variables when the new contents are the same as the old contents. In the common upgrade case where nothing needs to change, it no longer writes to NVRAM at all. It's also now slightly faster, since using libefivar is faster than forking efibootmgr. Fixes Debian bug #891434. Signed-off-by:
-
Hervé Werner authored
On full-encrypted systems, including /boot, the current code omits cryptodisk commands needed to open the drives if Secure Boot is enabled. This prevents grub2 from reading any further configuration residing on the encrypted disk. This patch fixes this issue by adding the needed "cryptomount" commands in the load.cfg file that is then copied in the EFI partition. Bug-Debian: https://bugs.debian.org/917117 Last-Update: 2019-02-10 Patch-Name: uefi-secure-boot-cryptomount.patch
-
Colin Watson authored
These don't work with and aren't needed by dynamically-loaded completions. Bug-Debian: https://bugs.debian.org/912852 Forwarded: no Last-Update: 2018-11-16 Patch-Name: bash-completion-drop-have-checks.patch
-
Colin Watson authored
Add fallback boot entries for alternative installed init systems. Based on patches from Michael Biebl and Didier Roche. Bug-Debian: https://bugs.debian.org/757298 Bug-Debian: https://bugs.debian.org/773173 Forwarded: no Last-Update: 2017-06-23 Patch-Name: mkconfig-other-inits.patch
-
Steve McIntyre authored
Add an extra option to grub-install "--force-extra-removable". On EFI platforms, this will cause an extra copy of the grub-efi image to be written to the appropriate removable media patch /boot/efi/EFI/BOOT/BOOT$ARCH.EFI as well. This will help with broken UEFI implementations where the firmware does not work when configured with new boot paths. Signed-off-by:
-
Ian Campbell authored
This is needed in case the Linux kernel is compiled with CONFIG_KERNEL_XZ or CONFIG_KERNEL_LZO rather than CONFIG_KERNEL_GZ (gzio is already loaded by grub.cfg today). Signed-off-by:
-
Ian Campbell authored
Upstream have defined a specification for where guests ought to place their xenpv grub binaries in order to facilitate chainloading from a stage 1 grub loaded from dom0. http://xenbits.xen.org/docs/unstable-staging/misc/x86-xenpv-bootloader.html The spec calls for installation into /boot/xen/pvboot-i386.elf or /boot/xen/pvboot-x86_64.elf. Signed-off-by:
-
Colin Watson authored
Some powerpc machines require not updating the NVRAM. This can be handled by existing grub-install command-line options, but it's friendlier to detect this automatically. On chrp_ibm machines, use the nvram utility rather than nvsetenv. (This is possibly suitable for other machines too, but that needs to be verified.) Forwarded: no Last-Update: 2014-10-15 Patch-Name: install-powerpc-machtypes.patch
-
Colin Watson authored
This allows the controversial "recovery mode" text to be customised. Bug-Ubuntu: https://bugs.launchpad.net/bugs/1240360 Forwarded: no Last-Update: 2013-12-25 Patch-Name: mkconfig-recovery-title.patch
-
Colin Watson authored
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1237519 Forwarded: no Last-Update: 2016-09-18 Patch-Name: probe-fusionio.patch
-
Colin Watson authored
This is used for non-recovery Linux entries only; it enables flicker-free booting if gfxpayload=keep is in use and a suitable kernel is present. Author: Andy Whitcroft <apw@canonical.com> Forwarded: not-needed Last-Update: 2013-12-25 Patch-Name: vt-handoff.patch
-
Evan Broder authored
Set GRUB_GFXPAYLOAD_LINUX=keep unless it's known to be unsupported on the current hardware. See https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-grub2-boot-framebuffer. Author: Colin Watson <cjwatson@ubuntu.com> Forwarded: no Last-Update: 2019-05-25 Patch-Name: gfxpayload-dynamic.patch
-
Steve Langasek authored
If we don't have writable grubenv, recordfail doesn't work, which means our quickboot behavior - with a timeout of 0 - leaves the user without a reliable way to access the boot menu if they're on UEFI, because unlike BIOS, UEFI does not support checking the state of modifier keys (i.e. holding down shift at boot is not detectable). Handle this corner case by always using a non-zero timeout on EFI when save_env doesn't work. Reuse GRUB_RECORDFAIL_TIMEOUT to avoid introducing another variable. Signed-off-by:
-
Colin Watson authored
If other operating systems are installed, then automatically unhide the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus if available to check whether Shift is pressed. If it is, show the menu, otherwise boot immediately. If keystatus is not available, then fall back to a short delay interruptible with Escape. This may or may not remain Ubuntu-specific, although it's not obviously wanted upstream. It implements a requirement of https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader. If the previous boot failed (defined as failing to get to the end of one of the normal runlevels), then show the boot menu regardless. Author: Richard Laager <rlaager@wiktel.com> Author: Robie Basak <robie.basak@ubuntu.com> Forwarded: no Last-Update: 2015-09-04 Patch-Name: quick-boot.patch
-
Colin Watson authored
This is not a very good approach, and certainly not sanely upstreamable; we probably need to split GRUB_DISTRIBUTOR into a couple of different variables. Bug-Ubuntu: https://bugs.launchpad.net/bugs/1242417 Bug-Debian: https://bugs.debian.org/932966 Forwarded: not-needed Last-Update: 2019-08-06 Patch-Name: install-efi-adjust-distributor.patch
-
Colin Watson authored
If this option is enabled, then do all of the following: Don't display introductory message about line editing unless we're actually offering a shell prompt. (This is believed to be a workaround for a different bug. We'll go with this for now, but will drop this in favour of a better fix upstream if somebody figures out what that is.) Don't clear the screen just before booting if we never drew the menu in the first place. Remove verbose messages printed before reading configuration. In some ways this is awkward because it makes debugging harder, but it's a requirement for a smooth-looking boot process; we may be able to do better in future. Upstream doesn't want this, though. Disable the cursor as well, for similar reasons of tidiness. Suppress kernel/initrd progress messages, except in recovery mode. Suppress "GRUB loading" message unless Shift is held down. Upstream doesn't want this, as it makes debugging harder. Ubuntu wants it to provide a cleaner boot experience. Author: Will Thompson <will@willthompson.co.uk> Bug-Ubuntu: https://bugs.launchpad.net/bugs/386922 Bug-Ubuntu: https://bugs.launchpad.net/bugs/861048 Forwarded: (partial) http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00056.html Last-Update: 2021-09-24 Patch-Name: maybe-quiet.patch
-
Colin Watson authored
Since we're already being booted from the Windows boot loader, including entries that take us back to it mostly just causes confusion, and stops us from being able to hide the menu if there are no other OSes installed. https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-wubi Forwarded: not-needed Last-Update: 2013-11-26 Patch-Name: wubi-no-windows.patch
-
Colin Watson authored
Author: Stéphane Graber <stgraber@ubuntu.com> Author: Steve Langasek <steve.langasek@ubuntu.com> Author: Linn Crosetto <linn@hpe.com> Author: Mathieu Trudel-Lapierre <cyphermox@ubuntu.com> Forwarded: no Last-Update: 2021-09-24 Patch-Name: install-signed.patch
-
Colin Watson authored
Forwarded: no Last-Update: 2013-12-25 Patch-Name: mkconfig-signed-kernel.patch
-
- Sep 24, 2021
-
-
Javier Martinez Canillas authored
Commit f60ba9e5 (util/mkimage: Refactor section setup to use a helper) added a helper function to setup PE sections, but it caused regressions in some arches where the natural alignment lead to wrong section sizes. This patch fixes a few things that were caused the section sizes to be calculated wrongly. These fixes are: * Only align the virtual memory addresses but not the raw data offsets. * Use aligned sizes for virtual memory sizes but not for raw data sizes. * Always align the sizes to set the virtual memory sizes. These seems to not cause problems for x64 and aa64 EFI platforms but was a problem for ia64. Because the size of the ".data" and "mods" sections were wrong and didn't have the correct content. Which lead to GRUB not being able to load any built-in module. Reported-by:
-
Ian Jackson authored
For complicated reasons, even if you have XSM/FLASK disabled (as is the default) the Xen build system still builds a policy file and puts it in /boot. Even so, we shouldn't be loading this in the usual non-"XSM enabled" entries. It doesn't do any particular harm but it is quite confusing. Signed-off-by:
-
Steve McIntyre authored
In this case, we need both the signed shim as /EFI/BOOT/BOOTXXX.EFI and signed Grub as /EFI/BOOT/grubXXX.efi. Also install the BOOTXXX.CSV into /EFI/debian, and FBXXX.EFI into /EFI/BOOT/ so that it can work when needed (*iff* we're updating the NVRAM). [cjwatson: Refactored also_install_removable somewhat for brevity and so that we're using consistent case-insensitive logic.] Bug-Debian: https://bugs.debian.org/930531 Last-Update: 2021-09-24 Patch-Name: grub-install-removable-shim.patch
-
Colin Watson authored
Some UEFI firmware is easily provoked into running out of space in its variable storage. This is usually due to certain kernel drivers (e.g. pstore), but regardless of the cause it can cause grub-install to fail because it currently asks efibootmgr to delete and re-add entries, and the deletion often doesn't result in an immediate garbage collection. Writing variables frequently also increases wear on the NVRAM which may have limited write cycles. For these reasons, it's desirable to find a way to minimise writes while still allowing grub-install to ensure that a suitable boot entry exists. Unfortunately, efibootmgr doesn't offer an interface that would let grub-install do this. It doesn't in general make very much effort to minimise writes; it doesn't allow modifying an existing Boot* variable entry, except in certain limited ways; and current versions don't have a way to export the expected variable data so that grub-install can compare it to the current data. While it would be possible (and perhaps desirable?) to add at least some of this to efibootmgr, that would still leave the problem that there isn't a good upstreamable way for grub-install to guarantee that it has a new enough version of efibootmgr. In any case, it's cumbersome and slow for grub-install to have to fork efibootmgr to get things done. Fortunately, a few years ago Peter Jones helpfully factored out a substantial part of efibootmgr to the efivar and efiboot libraries, and so it's now possible to have grub-install use those directly. We still have to use some code from efibootmgr, but much less than would previously have been necessary. grub-install now reuses existing boot entries where possible, and avoids writing to variables when the new contents are the same as the old contents. In the common upgrade case where nothing needs to change, it no longer writes to NVRAM at all. It's also now slightly faster, since using libefivar is faster than forking efibootmgr. Fixes Debian bug #891434. Signed-off-by:
-
Hervé Werner authored
On full-encrypted systems, including /boot, the current code omits cryptodisk commands needed to open the drives if Secure Boot is enabled. This prevents grub2 from reading any further configuration residing on the encrypted disk. This patch fixes this issue by adding the needed "cryptomount" commands in the load.cfg file that is then copied in the EFI partition. Bug-Debian: https://bugs.debian.org/917117 Last-Update: 2019-02-10 Patch-Name: uefi-secure-boot-cryptomount.patch
-
Colin Watson authored
These don't work with and aren't needed by dynamically-loaded completions. Bug-Debian: https://bugs.debian.org/912852 Forwarded: no Last-Update: 2018-11-16 Patch-Name: bash-completion-drop-have-checks.patch
-
Colin Watson authored
Add fallback boot entries for alternative installed init systems. Based on patches from Michael Biebl and Didier Roche. Bug-Debian: https://bugs.debian.org/757298 Bug-Debian: https://bugs.debian.org/773173 Forwarded: no Last-Update: 2017-06-23 Patch-Name: mkconfig-other-inits.patch
-
Steve McIntyre authored
Add an extra option to grub-install "--force-extra-removable". On EFI platforms, this will cause an extra copy of the grub-efi image to be written to the appropriate removable media patch /boot/efi/EFI/BOOT/BOOT$ARCH.EFI as well. This will help with broken UEFI implementations where the firmware does not work when configured with new boot paths. Signed-off-by:
-
Ian Campbell authored
This is needed in case the Linux kernel is compiled with CONFIG_KERNEL_XZ or CONFIG_KERNEL_LZO rather than CONFIG_KERNEL_GZ (gzio is already loaded by grub.cfg today). Signed-off-by:
-
Ian Campbell authored
Upstream have defined a specification for where guests ought to place their xenpv grub binaries in order to facilitate chainloading from a stage 1 grub loaded from dom0. http://xenbits.xen.org/docs/unstable-staging/misc/x86-xenpv-bootloader.html The spec calls for installation into /boot/xen/pvboot-i386.elf or /boot/xen/pvboot-x86_64.elf. Signed-off-by:
-
Colin Watson authored
Some powerpc machines require not updating the NVRAM. This can be handled by existing grub-install command-line options, but it's friendlier to detect this automatically. On chrp_ibm machines, use the nvram utility rather than nvsetenv. (This is possibly suitable for other machines too, but that needs to be verified.) Forwarded: no Last-Update: 2014-10-15 Patch-Name: install-powerpc-machtypes.patch
-
Colin Watson authored
This allows the controversial "recovery mode" text to be customised. Bug-Ubuntu: https://bugs.launchpad.net/bugs/1240360 Forwarded: no Last-Update: 2013-12-25 Patch-Name: mkconfig-recovery-title.patch
-
Colin Watson authored
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1237519 Forwarded: no Last-Update: 2016-09-18 Patch-Name: probe-fusionio.patch
-
Colin Watson authored
This is used for non-recovery Linux entries only; it enables flicker-free booting if gfxpayload=keep is in use and a suitable kernel is present. Author: Andy Whitcroft <apw@canonical.com> Forwarded: not-needed Last-Update: 2013-12-25 Patch-Name: vt-handoff.patch
-
Evan Broder authored
Set GRUB_GFXPAYLOAD_LINUX=keep unless it's known to be unsupported on the current hardware. See https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-grub2-boot-framebuffer. Author: Colin Watson <cjwatson@ubuntu.com> Forwarded: no Last-Update: 2019-05-25 Patch-Name: gfxpayload-dynamic.patch
-
Steve Langasek authored
If we don't have writable grubenv, recordfail doesn't work, which means our quickboot behavior - with a timeout of 0 - leaves the user without a reliable way to access the boot menu if they're on UEFI, because unlike BIOS, UEFI does not support checking the state of modifier keys (i.e. holding down shift at boot is not detectable). Handle this corner case by always using a non-zero timeout on EFI when save_env doesn't work. Reuse GRUB_RECORDFAIL_TIMEOUT to avoid introducing another variable. Signed-off-by:
-
Colin Watson authored
If other operating systems are installed, then automatically unhide the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus if available to check whether Shift is pressed. If it is, show the menu, otherwise boot immediately. If keystatus is not available, then fall back to a short delay interruptible with Escape. This may or may not remain Ubuntu-specific, although it's not obviously wanted upstream. It implements a requirement of https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader. If the previous boot failed (defined as failing to get to the end of one of the normal runlevels), then show the boot menu regardless. Author: Richard Laager <rlaager@wiktel.com> Author: Robie Basak <robie.basak@ubuntu.com> Forwarded: no Last-Update: 2015-09-04 Patch-Name: quick-boot.patch
-
Colin Watson authored
This is not a very good approach, and certainly not sanely upstreamable; we probably need to split GRUB_DISTRIBUTOR into a couple of different variables. Bug-Ubuntu: https://bugs.launchpad.net/bugs/1242417 Bug-Debian: https://bugs.debian.org/932966 Forwarded: not-needed Last-Update: 2019-08-06 Patch-Name: install-efi-adjust-distributor.patch
-