summaryrefslogtreecommitdiff
path: root/scripts/build/binary_grub-efi
AgeCommit message (Collapse)Author
2021-02-16mkfs.msdos needs at most 32 bits for the -i argument.Roland Clobus
Use the hexadecimal version of SOURCE_DATE_EPOCH, limited to the lower 32 bits
2021-01-15Set timestamp embedded in EFI filesRoland Clobus
2021-01-15Use SOURCE_DATE_EPOCH for the partition-id of /boot/grub/efi.imgRoland Clobus
2021-01-01Preserve timestampsRoland Clobus
2020-10-12For 32bit UEFI secure boot, the package name is grub-efi-ia32-signedMarcel Partap
avoids spitting out warning > [2020-06-07 22:30:32] lb binary_grub-efi > P: Begin preparing Grub based EFI support... > Reading package lists... > Building dependency tree... > Reading state information... > Package grub-efi-amd64-signed is not available, but is referred to by another package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > > E: Package 'grub-efi-amd64-signed' has no installation candidate > W: UEFI Secure Boot disabled due to missing signed Grub/Shim.
2020-05-05s/Remove_package/Remove_packages/Lyndon Brown
it removes one or more, so should be plural for clarity Gbp-Dch: Short
2020-05-05s/Install_package/Install_packages/Lyndon Brown
it installs one or more, so should be plural for clarity Gbp-Dch: Short
2020-05-04rename binary_loopback_cfg to binary_grub_cfgLyndon Brown
when loopback support was introduced, it initially duplicated the code for generating a grub2 config, before the duplicated code was removed from the grub-pc script, effectively thus moving grub config generation to the loopback feature script. grub-efi support was added after this. this results in a misleading filename, since the `binary_loopback_cfg` script is essential for use of grub-pc|grub-efi, and actually only has a single line of code on top that's needed for adding actual loopback support on top. (when grub-pc and grub-efi are not used, the entire script is still needed for loopback support to work). so here we rename it to make better sense, and correct/clarify bits of documentation. Gbp-Dch: Short
2020-05-04config: improve BIOS/EFI bootloader selection handlingLyndon Brown
the design choice from when EFI support was introduced was to change `--bootloader` to `--bootloaders`, with users specifying their selection of BIOS and EFI bootloaders together. at this time there were not even any decent validation checks being performed, and invalid combinations could cause some chaos. since then proper validation was put in place, including checking that only a single instance of each of BIOS and EFI bootloaders exists in the selection. here we tweak things such that we stick with the same option, but we split the selection up such that we store the BIOS and EFI selections separately within the saved config file, and offer it up to scripts to help simplify those scripts. we must however retain support for splitting from the combined option, both because we still use it in the combined option, and for backwards compatibility with older saved configs. Gbp-Dch: Short
2020-05-04fully validate BIOS/EFI bootloader combinationsLyndon Brown
thus far, config bootloader validation only did the basic check that each bootloader specified was a known and supported bootloader, it did not check combinations. it now checks combinations, and strips out the previous "bootloader role" stuff. the no-bootloaders warning is duplicated, covering two slightly different situations (empty string, and whitespace string). this is anticipated to be just temporary, with this just being the first step in better handling bootloader selections. Gbp-Dch: Short
2020-04-23config: s/LIVE_IMAGE_TYPE/LB_IMAGE_TYPE/Lyndon Brown
no backwards compatibility hack for reading the old var from existing saved config used because this was previously stored in the alternate format config/build file. Gbp-Dch: Short
2020-04-23rename LB_ARCHITECTURES to LB_ARCHITECTURELyndon Brown
this was previously not done in 8b109ffb96282a6dd1aa5d61aa935bcba69c56f1 to keep the renaming simple, but leaving the variable plural is a cause for confusion. since this property is stored in the INI style config/build config file rather than a shell script based one, at the property there is already singular, there was no need for a backwards compatibility hack. Gbp-Dch: Short
2020-04-23tidy up grub bootloader compatibility checkingLyndon Brown
- add a validation check where an error will be printed - replace the check done in the grub scripts with one that simple exits if executed bypassing the validation check Gbp-Dch: Short
2020-04-23--binary-images can support only a single typeLyndon Brown
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-04-23grub-efi: fix partial broken boot capabilityadrian15
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
2020-03-17stagefiles: s/Require_stagefile/Require_stagefiles/Lyndon Brown
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-17stagefiles: further robustify with auto filenamesLyndon Brown
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-17stagefiles: simplify & robustifyLyndon Brown
- avoid all need to pass ".build/" path in stage file names into the functions - add a helper to remove a stage file (required to complete the above properly) - avoid duplicating filenames within scripts which makes them prone to mistakes (some instances of which I've actually encountered and had to fix) Gbp-Dch: Short
2020-03-15Add grub EFI support for armhf arch.Steven Shiau
2020-03-13fix comment typoLyndon Brown
Gbp-Dch: Ignore
2020-03-13locks: tidy lock acquisitionjnqnfe
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
2020-03-12grub-efi: fix image type check orderingLyndon Brown
this should take place before working on efi related stuff Gbp-Dch: Short
2020-03-12grub-efi: fix incorrect error handlingLyndon Brown
2020-03-11amend copyright & licensing blocksLyndon Brown
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-10help/usage: remove pointless varsLyndon Brown
build scripts never call Help() and so the empty HELP strings are pointless. (when called with --help they call Man()). Closes: #952859 Gbp-Dch: Short
2020-03-10tidy script init (1/4) - arg and config processingjnqnfe
Partial fix for #952919 Gbp-Dch: Short
2020-03-05cache: clarify and simplify package cache save/restorejnqnfe
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
2020-03-05help/usage: fix overly complex script description handlingjnqnfe
Closes: #952887
2020-03-05fix indentationLyndon Brown
including: - spaces replaced with tabs for consistency - alignment of `;;` in some case statements changed for consistency Gbp-Dch: Short Closes: #952857
2018-09-19UEFI: remove the EFI/debian/grub.cfg, not necessary anymoreLuca Boccassi
Turns out gcd works fine after adding /boot/grub/grub.cfg in the img, as that's the path that gets hardcoded, and adding the EFI/debian/ grub.cfg was not necessary, so remove it.
2018-09-19Use gcd{x64.aa64}.efi.signed for amd64/arm64 arch.Steven Shiau
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-06-07UEFI: parse vendor from Grub package metadataLuca Boccassi
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-03-09UEFI: use uppercase EFI directory name for TianocoreLuca Boccassi
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-03-09UEFI: add support for Secure Boot on amd64 and arm64Luca Boccassi
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-03-09UEFI: add minimal grub.cfg to fat32 partitionLuca Boccassi
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-03-02Add grub-based UEFI boot support for ARM64Steven Shiau
Closes: #885692 Fixes: !2 Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2017-09-01Check all dependencies independent of LB_BUILD_WITH_CHROOTMatthijs Kooijman
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.
2016-12-02Drop useless code in binary_grub-efiRaphaël Hertzog
2016-07-31Added EFI support by the means of grub-efiAdrian Gibanel Lopez
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.