manuel
/
live-build
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
live-build/scripts/build/binary_grub-efi

305 lines
9.5 KiB
Plaintext
Raw Normal View History

Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
#!/bin/sh
## live-build(7) - System Build Scripts
amend copyright & licensing blocks Current versions of the project files are built upon versions published and licensed by Daniel Baumann, but are modified copies of those files and thus need to be marked as such per licensing requirements (afaik he did not pass along ownership / licensing rights to anyone when he left the project). We should also be careful to not be misrepresenting such modified copies as being attributed to Daniel. Adding a new copyright line referring to "The Debian Live team" should suffice for this. The authorship block in man pages has also similarly been updated. Notes: - tweaked a copy of daniel copyright lines stating 2014 instead of 2015. both of these cases were in files that i had personally introduced in some of my past merged commits that moved some code around. i don't know why they stated 2014. - binary_onie was introduced in 2018, so that has a 2018 date instead of 2016 unlike the rest. - 'efi-image' is a 3rd-party (Canonical Ltd) work that we bundle, but it has been modified by 674794a8f4d61a729d2dbd6d99385d2826138694 and 36a3ba76347ef72df1c316312ed3a26aa4b0c816 so I similarly added a debian live copyright line. - 'grub-cpmodules' is similar. it was only changed by the indentation fix of 36a3ba76347ef72df1c316312ed3a26aa4b0c816 but modification is modification, and this does help cover any possible future changes that might be made.
2020-03-11 09:07:21 -01:00
## Copyright (C) 2016-2020 The Debian Live team
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
## Copyright (C) 2016 Adrian Gibanel Lopez <adrian15sgd@gmail.com>
##
## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
## This is free software, and you are welcome to redistribute it
## under certain conditions; see COPYING for details.
set -e
# Including common functions
[ -e "${LIVE_BUILD}/scripts/build.sh" ] && . "${LIVE_BUILD}/scripts/build.sh" || . /usr/lib/live/build.sh
# Setting static variables
help/usage: fix overly complex script description handling Closes: #952887
2015-02-05 02:30:47 -01:00
DESCRIPTION="Prepares and installs Grub based EFI support into binary"
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
USAGE="${PROGRAM} [--force]"
tidy script init (1/4) - arg and config processing Partial fix for #952919 Gbp-Dch: Short
2015-02-05 02:30:47 -01:00
# Processing arguments and configuration files
Init_config_data "${@}"
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
Check_Any_Bootloader_Role "grub-efi"
Echo_message "Begin preparing Grub based EFI support..."
# Requiring stage file
stagefiles: s/Require_stagefile/Require_stagefiles/ this function takes one or more required stage fileS _plural_, and exits if any are missing (or at least it does now after the refactor). let's rename it to make things more clear Gbp-Dch: Short
2020-03-15 12:05:44 -01:00
Require_stagefiles config bootstrap
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
# Checking stage file
stagefiles: further robustify with auto filenames as suggested by Raphaël rather than have fixed stagefile filename strings at all in the scripts, use `$(basename $0)` to use the name of the script (which is the same for almost all cases anyway, and the stage files are supposed to be almost exclusively unique per-script). we can thus simplify things by determining the filename for most use cases within the functions themselves. this does change the file used by a couple of scripts, affecting backwards compatibility of executing live-build upon an existing partially or fully completed build: - binary_grub-pc used "binary_grub" - chroot_includes used "includes.chroot" care had to be taken for the following cases: - there are some cases like bootstrap_cache, source_debian and bootstrap_debootstrap which are dealing with more than one file, and/or otherwise a filename that is not specific to the script itself exactly, or should not be based upon its name. - some cases like chroot_cache, bootstrap_cache and chroot_install-packages need to append something to the end of the name depending upon which pass/action mode the script is being executed with. - furthermore in the bootstrap_cache case one of the filenames is used within the bootstrap_debootstrap and thus needs very careful handling to be certain that a change in filename of bootstrap_cache does not break bootstrap_debootstrap. Gbp-Dch: Short
2020-03-13 16:11:53 -01:00
Check_stagefile
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
fix comment typo Gbp-Dch: Ignore
2020-03-13 15:19:59 -01:00
# Acquire lock file
locks: tidy lock acquisition Combine the check+create done in each script. (The original functions are still callable as before, but a new combined `Aquire_lockfile` function can be called instead, as now used). Note, a further simplification could be done in removing the passing of the lock filename in as a parameter since every use of the functions is with ".lock". The lock functions already have a fallback to ".build/lock" though. Checking the history, the fallback used to be for a system wide lock, which was then replaced with this config-tree specific one. As long as that is not used implicitly by 3rd-party hooks then surely we are free to change the fallback to ".lock" and further remove passing in a name as a param...? history: db5d2b0dcdae96e712661605e17bc9875e224f9f 0aa8289a3773fd8a3885090b72622c2f95ab099c Gbp-Dch: Short Closes: #952918
2015-02-05 02:30:47 -01:00
Acquire_lockfile
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
# Check architecture
Add grub EFI support for armhf arch.
2020-03-15 10:35:19 -01:00
Check_architectures amd64 i386 arm64 armhf
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
Check_crossarchitectures
grub-efi: fix image type check ordering this should take place before working on efi related stuff Gbp-Dch: Short
2020-03-11 22:04:49 -01:00
# Setting destination directory
case "${LIVE_IMAGE_TYPE}" in
--binary-images can support only a single type whilst some parts of the codebase were set up to work with multiple types specified, others did not work with it and would not necessarily be easy to adjust. this thus makes some tweaks to adjust things accordingly. - option renamed to singular form (maintaining backwards compatibility) - a validation check has been added - unnecessary glob style type references fixed - checks with In_list changed to a direct singular comparison - typo of type "netboot" written as just "net" fixed (though unreachable so of no consequence; really the code could be removed but it's trivial) Gbp-Dch: Short
2020-03-28 04:13:11 -01:00
hdd|netboot)
grub-efi: fix image type check ordering this should take place before working on efi related stuff Gbp-Dch: Short
2020-03-11 22:04:49 -01:00
Echo_warning "Bootloader in this image type not yet supported by live-build."
Echo_error "This would produce a not bootable image, aborting (FIXME)."
exit 1
;;
esac
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
# Checking depends
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
case "${LB_ARCHITECTURES}" in
amd64|i386)
Check_package chroot /usr/lib/grub/x86_64-efi/configfile.mod grub-efi-amd64-bin
Check_package chroot /usr/lib/grub/i386-efi/configfile.mod grub-efi-ia32-bin
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
arm64)
Check_package chroot /usr/lib/grub/arm64-efi/configfile.mod grub-efi-arm64-bin
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
Add grub EFI support for armhf arch.
2020-03-15 10:35:19 -01:00
armhf)
Check_package chroot /usr/lib/grub/arm-efi/configfile.mod grub-efi-arm-bin
;;
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
esac
Check all dependencies independent of LB_BUILD_WITH_CHROOT Since commit fdc9250bc (Changing package dependency checks within chroot to work outside as well), Check_package automatically checks for LB_BUILD_WITH_CHROOT and works inside as well as outside of the chroot, so no need to check LB_BUILD_WITH_CHROOT before calling them. Install_package and Remove_package are just a no-op when building without chroot, so they can also be called unconditionally. Restore_cache and Save_cache do not check LB_BUILD_WITH_CHROOT but it it should not hurt to call them when not needed (which already happened in some cases). This commit makes all Check_package calls unconditional on LB_BUILD_WITH_CHROOT. For binary_syslinux, this fixes the check (which used outdated paths outside the chroot since 7b6dfd9d1), for binary_grub-efi, binary_package-lists and chroot_package-lists this simplifies the code (but also causes the check to become package-based instead of file-based on apt-based systems), and for binary_loadlin and binary_win32-loader this adds the check outside the chroot which was previously missing.
2017-08-28 09:29:54 +00:00
Check_package chroot /usr/bin/grub-mkimage grub-common
Check_package chroot /usr/bin/mcopy mtools
Check_package chroot /sbin/mkfs.msdos dosfstools
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
# Check UEFI Secure Boot setting and depends
# By default (auto) do a best-effort build: if the signed binaries are available use
# them, but don't fail if they are not, just print a warning.
case "${LB_ARCHITECTURES}" in
amd64|i386)
_SB_EFI_PLATFORM="x86_64"
_SB_EFI_NAME="x64"
_SB_EFI_DEB="amd64"
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
arm64)
_SB_EFI_PLATFORM="arm64"
_SB_EFI_NAME="aa64"
_SB_EFI_DEB="arm64"
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
Add grub EFI support for armhf arch.
2020-03-15 10:35:19 -01:00
armhf)
_SB_EFI_PLATFORM="arm"
_SB_EFI_NAME="arm"
_SB_EFI_DEB="arm"
;;
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
esac
_PRE_SB_PACKAGES="${_LB_PACKAGES}"
_LB_PACKAGES="shim-signed grub-efi-${_SB_EFI_DEB}-signed"
case "${LB_UEFI_SECURE_BOOT}" in
auto)
# Use Check_installed, as Check_package will error out immediately
set +e
Install_package
set -e
Use gcd{x64.aa64}.efi.signed for amd64/arm64 arch. For secured boot in binary_grub-efi, the gcdx64.efi.signed is the boot loader for removable device, like CD or USB flash drive, while grubx64.efi.signed is for hard drive. Therefore for live system, use gcdx64.efi.signed for amd64 and gcdaa64.efi.signed for arm64.
2018-08-22 03:43:40 +00:00
Check_installed chroot /usr/lib/grub/${_SB_EFI_PLATFORM}-efi-signed/gcd${_SB_EFI_NAME}.efi.signed \
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
grub-efi-${_SB_EFI_DEB}-signed
_GRUB_INSTALL_STATUS="${INSTALL_STATUS}"
Check_installed chroot /usr/lib/shim/shim${_SB_EFI_NAME}.efi.signed \
shim-signed
if [ "${INSTALL_STATUS}" -ne 0 -o "${_GRUB_INSTALL_STATUS}" -ne 0 ]
then
Echo_warning "UEFI Secure Boot disabled due to missing signed Grub/Shim."
else
Echo_message "UEFI Secure Boot support enabled."
fi
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
enable)
Use gcd{x64.aa64}.efi.signed for amd64/arm64 arch. For secured boot in binary_grub-efi, the gcdx64.efi.signed is the boot loader for removable device, like CD or USB flash drive, while grubx64.efi.signed is for hard drive. Therefore for live system, use gcdx64.efi.signed for amd64 and gcdaa64.efi.signed for arm64.
2018-08-22 03:43:40 +00:00
Check_package chroot /usr/lib/grub/${_SB_EFI_PLATFORM}-efi-signed/gcd${_SB_EFI_NAME}.efi.signed \
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
grub-efi-${_SB_EFI_DEB}-signed
Check_package chroot /usr/lib/shim/shim${_SB_EFI_NAME}.efi.signed \
shim-signed
Install_package
Echo_message "UEFI Secure Boot support enabled."
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
disable)
Echo_message "UEFI Secure Boot support disabled."
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
esac
_LB_PACKAGES="${_PRE_SB_PACKAGES}"
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
# Restoring cache
cache: clarify and simplify package cache save/restore These functions are specific to handling packages stored in the cache, not other files. They are also always used with the same `cache/packages.` prefix to the path. Gbp-Dch: Short Closes: #952916
2015-01-06 02:46:37 -01:00
Restore_package_cache binary
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
# Installing depends
Install_package
# Cleanup files that we generate
Add grub EFI support for armhf arch.
2020-03-15 10:35:19 -01:00
rm -rf binary/boot/efi.img binary/boot/grub/i386-efi/ binary/boot/grub/x86_64-efi binary/boot/grub/arm64-efi binary/boot/grub/arm-efi
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
# This is workaround till both efi-image and grub-cpmodules are put into a binary package
case "${LB_BUILD_WITH_CHROOT}" in
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
true)
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
if [ ! -e "${LIVE_BUILD}" ] ; then
LIVE_BUILD_PATH="/usr/lib/live/build"
else
LIVE_BUILD_PATH="${LIVE_BUILD}/scripts/build"
fi
mkdir -p chroot/${LIVE_BUILD_PATH}
cp "${LIVE_BUILD_PATH}/efi-image" "chroot/${LIVE_BUILD_PATH}"
cp "${LIVE_BUILD_PATH}/grub-cpmodules" "chroot/${LIVE_BUILD_PATH}"
Check all dependencies independent of LB_BUILD_WITH_CHROOT Since commit fdc9250bc (Changing package dependency checks within chroot to work outside as well), Check_package automatically checks for LB_BUILD_WITH_CHROOT and works inside as well as outside of the chroot, so no need to check LB_BUILD_WITH_CHROOT before calling them. Install_package and Remove_package are just a no-op when building without chroot, so they can also be called unconditionally. Restore_cache and Save_cache do not check LB_BUILD_WITH_CHROOT but it it should not hurt to call them when not needed (which already happened in some cases). This commit makes all Check_package calls unconditional on LB_BUILD_WITH_CHROOT. For binary_syslinux, this fixes the check (which used outdated paths outside the chroot since 7b6dfd9d1), for binary_grub-efi, binary_package-lists and chroot_package-lists this simplifies the code (but also causes the check to become package-based instead of file-based on apt-based systems), and for binary_loadlin and binary_win32-loader this adds the check outside the chroot which was previously missing.
2017-08-28 09:29:54 +00:00
_CHROOT_DIR=""
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
Check all dependencies independent of LB_BUILD_WITH_CHROOT Since commit fdc9250bc (Changing package dependency checks within chroot to work outside as well), Check_package automatically checks for LB_BUILD_WITH_CHROOT and works inside as well as outside of the chroot, so no need to check LB_BUILD_WITH_CHROOT before calling them. Install_package and Remove_package are just a no-op when building without chroot, so they can also be called unconditionally. Restore_cache and Save_cache do not check LB_BUILD_WITH_CHROOT but it it should not hurt to call them when not needed (which already happened in some cases). This commit makes all Check_package calls unconditional on LB_BUILD_WITH_CHROOT. For binary_syslinux, this fixes the check (which used outdated paths outside the chroot since 7b6dfd9d1), for binary_grub-efi, binary_package-lists and chroot_package-lists this simplifies the code (but also causes the check to become package-based instead of file-based on apt-based systems), and for binary_loadlin and binary_win32-loader this adds the check outside the chroot which was previously missing.
2017-08-28 09:29:54 +00:00
false)
_CHROOT_DIR="chroot"
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
;;
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
esac
#####
cat >binary.sh <<END
#!/bin/sh
set -e
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
gen_efi_boot_img(){
local platform="\$1"
local efi_name="\$2"
local netboot_prefix="\$3"
local outdir="grub-efi-temp-\${platform}"
"\${LIVE_BUILD_PATH}/efi-image" "${_CHROOT_DIR}/\$outdir" "\$platform" "\$efi_name" "\$netboot_prefix"
UEFI: use uppercase EFI directory name for Tianocore The Tianocore reference UEFI implementation, used for example by Qemu, wants the EFI directory name to be uppercase in the fat32 partition when Secure Boot is enabled, and will fail to load otherwise.
2018-02-27 18:30:19 -01:00
mkdir -p ${_CHROOT_DIR}/grub-efi-temp/EFI/boot
mcopy -n -i ${_CHROOT_DIR}/\$outdir/efi.img '::efi/boot/boot*.efi' ${_CHROOT_DIR}/grub-efi-temp/EFI/boot
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
cp -r "${_CHROOT_DIR}"/\$outdir/* "${_CHROOT_DIR}/grub-efi-temp/"
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
# Secure Boot support:
UEFI: use uppercase EFI directory name for Tianocore The Tianocore reference UEFI implementation, used for example by Qemu, wants the EFI directory name to be uppercase in the fat32 partition when Secure Boot is enabled, and will fail to load otherwise.
2018-02-27 18:30:19 -01:00
# - create the EFI directory in the ESP with uppercase letters to make
# certain firmwares (eg: TianoCore) happy
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
# - use shim as the boot<arch>.efi that gets loaded first by the firmware
# - drop a grub.cfg (same reason as below) in the cfg directory as configured
UEFI: parse vendor from Grub package metadata When using Secure Boot, grub2 as built by Debian will now load a config file from EFI/$VENDOR instead of having EFI/debian hardcoded. $VENDOR comes from dpkg-vendor or from the user building grub2. The vendor string is stored in the control metadata as Efi-Vendor, so retrieve it when building the EFI image.
2018-06-06 12:41:35 +00:00
# by the signed grub efi binary creation. This is set dynamically when grub2 is
# built with the ouput of dpkg-vendor, and can be overridden by the builder, so
# we do the same here in live-build.
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
# - the source paths are taken from shim-signed:
# https://packages.debian.org/sid/amd64/shim-signed/filelist
# and grub-efi-amd64-signed, currently in Ubuntu:
# https://packages.ubuntu.com/xenial/amd64/grub-efi-amd64-signed/filelist
# https://packages.ubuntu.com/bionic/arm64/grub-efi-arm64-signed/filelist
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
# E.g., gcdx64.efi.signed is the boot loader for removable device, like CD or
# USB flash drive, while grubx64.efi.signed is for hard drive.
# Therefore here gcdx64.efi.signed is used for amd64 and gcdaa64.efi.signed is
# for arm64.
Use gcd{x64.aa64}.efi.signed for amd64/arm64 arch. For secured boot in binary_grub-efi, the gcdx64.efi.signed is the boot loader for removable device, like CD or USB flash drive, while grubx64.efi.signed is for hard drive. Therefore for live system, use gcdx64.efi.signed for amd64 and gcdaa64.efi.signed for arm64.
2018-08-22 03:43:40 +00:00
if [ -r ${_CHROOT_DIR}/usr/lib/grub/\$platform-signed/gcd\$efi_name.efi.signed -a \
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
-r ${_CHROOT_DIR}/usr/lib/shim/shim\$efi_name.efi.signed -a \
"${LB_UEFI_SECURE_BOOT}" != "disable" ]; then
Use gcd{x64.aa64}.efi.signed for amd64/arm64 arch. For secured boot in binary_grub-efi, the gcdx64.efi.signed is the boot loader for removable device, like CD or USB flash drive, while grubx64.efi.signed is for hard drive. Therefore for live system, use gcdx64.efi.signed for amd64 and gcdaa64.efi.signed for arm64.
2018-08-22 03:43:40 +00:00
cp ${_CHROOT_DIR}/usr/lib/grub/\$platform-signed/gcd\$efi_name.efi.signed \
UEFI: use uppercase EFI directory name for Tianocore The Tianocore reference UEFI implementation, used for example by Qemu, wants the EFI directory name to be uppercase in the fat32 partition when Secure Boot is enabled, and will fail to load otherwise.
2018-02-27 18:30:19 -01:00
${_CHROOT_DIR}/grub-efi-temp/EFI/boot/grub\$efi_name.efi
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
cp ${_CHROOT_DIR}/usr/lib/shim/shim\$efi_name.efi.signed \
UEFI: use uppercase EFI directory name for Tianocore The Tianocore reference UEFI implementation, used for example by Qemu, wants the EFI directory name to be uppercase in the fat32 partition when Secure Boot is enabled, and will fail to load otherwise.
2018-02-27 18:30:19 -01:00
${_CHROOT_DIR}/grub-efi-temp/EFI/boot/boot\$efi_name.efi
UEFI: add support for Secure Boot on amd64 and arm64 Support for UEFI Secure Boot is modelled after how it currently works in Ubuntu and on how it is going to work on Debian. A minimal bootloader, shim, is used as the first-stage and it then loads grub. Both have to be signed. shim-signed is already available in Debian so the filenames are already established, and the grub2 repository and packaging is common between the 2 distros so we can already be reasonably sure of what it is going to be. So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed as boot[x64|aa64].efi so that UEFI loads it first, and copy /usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as grub[x64|aa64].efi. This grub2 EFI monolithic image is currently hard-coded in grub2's repository to look for a config file in efi/debian, so make a copy of the previously added minimal grub.cfg that loads the real one in that directory in both the fat32 and ISO 9660 partitions. The new option --uefi-secure-boot can be set to auto (default, enable or disable. In auto, the lack of the signed EFI binaries is intentionally left as a soft failure - live-build will simply fallback to using the locally generated non-signed grub2 monolithic EFI binary as the only bootloader. Given the difficulties surrounding the Secure Boot signing infrastructure this approach gives the most flexibility and makes sure things will "just work" once the packages are available, without the need to change anything in the configuration. This will also greatly help downstream distributions and users who want to do self-signing. The enable or disable options work as expected. Closes: #821084
2018-02-27 18:28:33 -01:00
fi
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
}
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
PRE_EFI_IMAGE_PATH="${PATH}"
if [ ! -e "${LIVE_BUILD}" ] ; then
LIVE_BUILD_PATH="/usr/lib/live/build"
else
LIVE_BUILD_PATH="${LIVE_BUILD}/scripts/build"
fi
PATH="${PATH}:\${LIVE_BUILD_PATH}" # Make sure grub-cpmodules is used as if it was installed in the system
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
case "${LB_ARCHITECTURES}" in
amd64|i386)
gen_efi_boot_img "x86_64-efi" "x64" "debian-live/amd64"
gen_efi_boot_img "i386-efi" "ia32" "debian-live/i386"
PATH="\${PRE_EFI_IMAGE_PATH}"
Add grub EFI support for armhf arch.
2020-03-15 10:35:19 -01:00
;;
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
arm64)
gen_efi_boot_img "arm64-efi" "aa64" "debian-live/arm64"
PATH="\${PRE_EFI_IMAGE_PATH}"
Add grub EFI support for armhf arch.
2020-03-15 10:35:19 -01:00
;;
armhf)
gen_efi_boot_img "arm-efi" "arm" "debian-live/arm"
PATH="\${PRE_EFI_IMAGE_PATH}"
;;
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
esac
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
UEFI: add minimal grub.cfg to fat32 partition On some UEFI implementations, like the AMI found in the Supermicro X10SDV-TP8F development board, the fat32 partition will be loaded first and so Grub will set it the root, and then drop to the console as it cannot find any config on it. Add a minimal grub.cfg that allows Grub to find the main config on the ISO 9660 partition and load it. Closes: #892406
2018-02-27 18:23:41 -01:00
# On some platforms the EFI grub image will be loaded, so grub's root
# variable will be set to the EFI partition. This means that grub will
# look in that partition for a grub.cfg file, and even if it finds it
# it will not be able to find the vmlinuz and initrd.
# Drop a minimal grub.cfg in the EFI partition that sets the root and prefix
grub-efi: fix partial broken boot capability when used alongside syslinux and when a single kernel flavour is used, things work correctly. otherwise booting from EFI is broken. the problem comes from the fact that syslinux, for a single kernel flavour creates the file /live/vmlinuz, which is used by the minimal EFI grub.cfg to locate the device and partition containing the live image. when multiple kernel flavours are used, it instead creates /live/vmlinuz1, /live/vmlinuz2, etc. which thus is a problem. similarly when syslinux is not used, you are left only with long filenames for the kernel files, for example /live/vmlinuz-4.19.0-8-amd64. in these situations grub cannot find the device containing the image and thus fails to display the boot menu. the solution here, instead of dynamically changing the filename searched for depending upon bootloader configuration, switches to doing a search for the file /.disk/info instead. this file is generated by binary_disk, and is present for iso, iso-hybrid and hdd images types, though grub-efi cannot be used for the hdd type. it is not created for the netboot type, but again, grub-efi is not compatible with that anyway. it is not created for the tar type, which the grub-efi script does not block as incompatible, but is this not a mistake? furthermore, switching to searching for /.disk/info helps avoid issues for systems that happen to actually include a real /live/vmlinuz path other than on a removable live disk or CD/DVD, as is the case with a HP system discussed in #924053. this patch was written by adrian15sgd@gmail.com, as per the authorship, who attached it to the #924053 bug discussion. this commit message however has been re-written by jnqnfe@gmail.com, prior to submission via an MR, as part of the fix towards the issues reported in #956131. Gbp-Dch: Short Closes: #924053
2019-03-09 12:49:01 -01:00
# to whatever partition holds the /.disk/info file, and load the grub
UEFI: add minimal grub.cfg to fat32 partition On some UEFI implementations, like the AMI found in the Supermicro X10SDV-TP8F development board, the fat32 partition will be loaded first and so Grub will set it the root, and then drop to the console as it cannot find any config on it. Add a minimal grub.cfg that allows Grub to find the main config on the ISO 9660 partition and load it. Closes: #892406
2018-02-27 18:23:41 -01:00
# config from that same partition.
mkdir -p ${_CHROOT_DIR}/grub-efi-temp-cfg
cat >${_CHROOT_DIR}/grub-efi-temp-cfg/grub.cfg <<EOF
grub-efi: fix partial broken boot capability when used alongside syslinux and when a single kernel flavour is used, things work correctly. otherwise booting from EFI is broken. the problem comes from the fact that syslinux, for a single kernel flavour creates the file /live/vmlinuz, which is used by the minimal EFI grub.cfg to locate the device and partition containing the live image. when multiple kernel flavours are used, it instead creates /live/vmlinuz1, /live/vmlinuz2, etc. which thus is a problem. similarly when syslinux is not used, you are left only with long filenames for the kernel files, for example /live/vmlinuz-4.19.0-8-amd64. in these situations grub cannot find the device containing the image and thus fails to display the boot menu. the solution here, instead of dynamically changing the filename searched for depending upon bootloader configuration, switches to doing a search for the file /.disk/info instead. this file is generated by binary_disk, and is present for iso, iso-hybrid and hdd images types, though grub-efi cannot be used for the hdd type. it is not created for the netboot type, but again, grub-efi is not compatible with that anyway. it is not created for the tar type, which the grub-efi script does not block as incompatible, but is this not a mistake? furthermore, switching to searching for /.disk/info helps avoid issues for systems that happen to actually include a real /live/vmlinuz path other than on a removable live disk or CD/DVD, as is the case with a HP system discussed in #924053. this patch was written by adrian15sgd@gmail.com, as per the authorship, who attached it to the #924053 bug discussion. this commit message however has been re-written by jnqnfe@gmail.com, prior to submission via an MR, as part of the fix towards the issues reported in #956131. Gbp-Dch: Short Closes: #924053
2019-03-09 12:49:01 -01:00
search --set=root --file /.disk/info
UEFI: add minimal grub.cfg to fat32 partition On some UEFI implementations, like the AMI found in the Supermicro X10SDV-TP8F development board, the fat32 partition will be loaded first and so Grub will set it the root, and then drop to the console as it cannot find any config on it. Add a minimal grub.cfg that allows Grub to find the main config on the ISO 9660 partition and load it. Closes: #892406
2018-02-27 18:23:41 -01:00
set prefix=(\\\$root)/boot/grub
configfile (\\\$root)/boot/grub/grub.cfg
EOF
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
# The code below is adapted from tools/boot/jessie/boot-x86
# in debian-cd
# Stuff the EFI boot files into a FAT filesystem, making it as
# small as possible. 24KiB headroom seems to be enough;
# (x+31)/32*32 rounds up to multiple of 32.
# This is the same as in efi-image, but we need to redo it here in
# the case of a multi-arch amd64/i386 image
size=0
UEFI: use uppercase EFI directory name for Tianocore The Tianocore reference UEFI implementation, used for example by Qemu, wants the EFI directory name to be uppercase in the fat32 partition when Secure Boot is enabled, and will fail to load otherwise.
2018-02-27 18:30:19 -01:00
for file in ${_CHROOT_DIR}/grub-efi-temp/EFI/boot/*.efi \
UEFI: add minimal grub.cfg to fat32 partition On some UEFI implementations, like the AMI found in the Supermicro X10SDV-TP8F development board, the fat32 partition will be loaded first and so Grub will set it the root, and then drop to the console as it cannot find any config on it. Add a minimal grub.cfg that allows Grub to find the main config on the ISO 9660 partition and load it. Closes: #892406
2018-02-27 18:23:41 -01:00
${_CHROOT_DIR}/grub-efi-temp-cfg/grub.cfg; do
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
size=\$((\$size + \$(stat -c %s "\$file")))
done
UEFI: use uppercase EFI directory name for Tianocore The Tianocore reference UEFI implementation, used for example by Qemu, wants the EFI directory name to be uppercase in the fat32 partition when Secure Boot is enabled, and will fail to load otherwise.
2018-02-27 18:30:19 -01:00
# directories: EFI EFI/boot boot boot/grub
UEFI: add minimal grub.cfg to fat32 partition On some UEFI implementations, like the AMI found in the Supermicro X10SDV-TP8F development board, the fat32 partition will be loaded first and so Grub will set it the root, and then drop to the console as it cannot find any config on it. Add a minimal grub.cfg that allows Grub to find the main config on the ISO 9660 partition and load it. Closes: #892406
2018-02-27 18:23:41 -01:00
size=\$((\$size + 4096 * 4))
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
blocks=\$(((\$size / 1024 + 55) / 32 * 32 ))
rm -f ${_CHROOT_DIR}/grub-efi-temp/boot/grub/efi.img
mkfs.msdos -C "${_CHROOT_DIR}/grub-efi-temp/boot/grub/efi.img" \$blocks >/dev/null
UEFI: use uppercase EFI directory name for Tianocore The Tianocore reference UEFI implementation, used for example by Qemu, wants the EFI directory name to be uppercase in the fat32 partition when Secure Boot is enabled, and will fail to load otherwise.
2018-02-27 18:30:19 -01:00
mmd -i "${_CHROOT_DIR}/grub-efi-temp/boot/grub/efi.img" ::EFI
mmd -i "${_CHROOT_DIR}/grub-efi-temp/boot/grub/efi.img" ::EFI/boot
mcopy -o -i "${_CHROOT_DIR}/grub-efi-temp/boot/grub/efi.img" ${_CHROOT_DIR}/grub-efi-temp/EFI/boot/*.efi \
"::EFI/boot"
UEFI: add minimal grub.cfg to fat32 partition On some UEFI implementations, like the AMI found in the Supermicro X10SDV-TP8F development board, the fat32 partition will be loaded first and so Grub will set it the root, and then drop to the console as it cannot find any config on it. Add a minimal grub.cfg that allows Grub to find the main config on the ISO 9660 partition and load it. Closes: #892406
2018-02-27 18:23:41 -01:00
mmd -i "${_CHROOT_DIR}/grub-efi-temp/boot/grub/efi.img" ::boot
mmd -i "${_CHROOT_DIR}/grub-efi-temp/boot/grub/efi.img" ::boot/grub
mcopy -o -i "${_CHROOT_DIR}/grub-efi-temp/boot/grub/efi.img" ${_CHROOT_DIR}/grub-efi-temp-cfg/grub.cfg \
"::boot/grub"
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
END
case "${LB_BUILD_WITH_CHROOT}" in
fix indentation including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2020-02-10 14:48:49 -01:00
true)
Drop useless code in binary_grub-efi
2016-12-02 12:57:45 -01:00
mv binary.sh chroot/
Chroot chroot "sh binary.sh"
rm -f chroot/binary.sh
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
Drop useless code in binary_grub-efi
2016-12-02 12:57:45 -01:00
# Saving cache
cache: clarify and simplify package cache save/restore These functions are specific to handling packages stored in the cache, not other files. They are also always used with the same `cache/packages.` prefix to the path. Gbp-Dch: Short Closes: #952916
2015-01-06 02:46:37 -01:00
Save_package_cache binary
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
Drop useless code in binary_grub-efi
2016-12-02 12:57:45 -01:00
# Removing depends
Remove_package
;;
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
Drop useless code in binary_grub-efi
2016-12-02 12:57:45 -01:00
false)
sh binary.sh
rm -f binary.sh
;;
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
esac
# Remove unnecessary files
rm -f chroot/grub-efi-temp/bootnetia32.efi
rm -f chroot/grub-efi-temp/bootnetx64.efi
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
rm -f chroot/grub-efi-temp/bootnetaa64.efi
Add grub EFI support for armhf arch.
2020-03-15 10:35:19 -01:00
rm -f chroot/grub-efi-temp/bootnetarm.efi
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
mkdir -p binary
cp -r chroot/grub-efi-temp/* binary/
rm -rf chroot/grub-efi-temp-x86_64-efi
rm -rf chroot/grub-efi-temp-i386-efi
Add grub-based UEFI boot support for ARM64 Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-02-28 13:39:32 -01:00
rm -rf chroot/grub-efi-temp-arm64-efi
Add grub EFI support for armhf arch.
2020-03-15 10:35:19 -01:00
rm -rf chroot/grub-efi-temp-arm-efi
UEFI: add minimal grub.cfg to fat32 partition On some UEFI implementations, like the AMI found in the Supermicro X10SDV-TP8F development board, the fat32 partition will be loaded first and so Grub will set it the root, and then drop to the console as it cannot find any config on it. Add a minimal grub.cfg that allows Grub to find the main config on the ISO 9660 partition and load it. Closes: #892406
2018-02-27 18:23:41 -01:00
rm -rf chroot/grub-efi-temp-cfg
Added EFI support by the means of grub-efi This work is based on debian-cd team work and uses, as much as possible, the same mkisofs options than the Debian Installation CD disk does. It assumes that /boot/grub/grub.cfg (and other design items) is generated by: binary_loopback_cfg . It relies on efi-image and grub-cpmodules being setup as build scripts on live-build package. In the future event of these two files being moved to a binary package (they are originally from: src: live-installer) the binary_grub-efi script would have to be rewritten to take the new paths into account.
2016-01-18 02:21:39 -01:00
rm -rf chroot/grub-efi-temp
# We rely on: binary_loopback_cfg to generate grub.cfg and other configuration files
# Creating stage file
stagefiles: further robustify with auto filenames as suggested by Raphaël rather than have fixed stagefile filename strings at all in the scripts, use `$(basename $0)` to use the name of the script (which is the same for almost all cases anyway, and the stage files are supposed to be almost exclusively unique per-script). we can thus simplify things by determining the filename for most use cases within the functions themselves. this does change the file used by a couple of scripts, affecting backwards compatibility of executing live-build upon an existing partially or fully completed build: - binary_grub-pc used "binary_grub" - chroot_includes used "includes.chroot" care had to be taken for the following cases: - there are some cases like bootstrap_cache, source_debian and bootstrap_debootstrap which are dealing with more than one file, and/or otherwise a filename that is not specific to the script itself exactly, or should not be based upon its name. - some cases like chroot_cache, bootstrap_cache and chroot_install-packages need to append something to the end of the name depending upon which pass/action mode the script is being executed with. - furthermore in the bootstrap_cache case one of the filenames is used within the bootstrap_debootstrap and thus needs very careful handling to be certain that a change in filename of bootstrap_cache does not break bootstrap_debootstrap. Gbp-Dch: Short
2020-03-13 16:11:53 -01:00
Create_stagefile