summaryrefslogtreecommitdiff
path: root/config/grub
AgeCommit message (Collapse)Author
2024-06-27trees: don't hardcode use of mkpayload_grubLeah Rowe
instead, make it a helper function, defined in target.cfg this means that we can also do the same with other projects in the future, and it is expected that we will have to. these helper functions are used in cases where we want additional actions to be performed. actually, the helper could be anything. for example, you could write: mkhelper="./build foo bar" and it would do that (at the point of execution, PWD is the root directory of the build system) Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-27trees: avoid kconfig make commands genericallyLeah Rowe
don't hardcode the check based on whether the current project is grub. instead, define "btype" in target.cfg if unset, we assume kconfig and permit kconfig commands e.g. make menuconfig, make silentoldconfig, etc this is to avoid the deadliest of sins: project-specific hacks Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-19roms: don't insert timeout.cfgLeah Rowe
this is bloat, because it's something the user can already do at runtime configuration anyway. set it to a reasonable default of 8 seconds instead of 5, and don't honour the timeout variable in target.cfg. this will be documented in the next release. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-15grub: insert background in memdisk insteadLeah Rowe
the background is only a few kb. the whole rationale before was to limit the space used in memdisk, but this decision was made when the background was much bigger; it has since been optimised greatly, and the grub modules were heavily reduce, so it should be safe. grub's memdisk breaks when you add too much data to it. as part of simplifying the rest of lbmk, this change removes some more bloat from the rest of lbmk. handling this in the memdisk is much simpler than handling it with cbfstool. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12Libreboot 20240612 release20240612Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12grub: only enable nvme if needed on a boardLeah Rowe
remove nvme support from the "default" grub tree now there are three trees: * default: no xhci or nvme patches * nvme: contains nvme support * xhci: contains xhci and nvme support this is in case a bug like lbmk issue #216 ever occurs again, as referenced before during lbmk audit 5 there is no indication that the nvme patch causes any issues, but after previous experience i want to be sure Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-06handle build.list from config/data/, not config/Leah Rowe
certain code checks for build.list, to skip it, for example in items() we already use config/data/grub to store grub config data that applied to all trees create these directories too: config/data/coreboot config/data/u-boot config/data/seabios move the respective build.list files in here, and also to config/data/grub now multi-tree projects contain, per directory, just the target.cfg file and the patches directory. this is much cleaner, because some of the logic can be simplified more Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-02make GRUB multi-tree and re-add xhci patchesLeah Rowe
Re-add xHCI only on haswell and broadwell machines, where they are needed. Otherwise, keep the same GRUB code. The xHCI patches were removed because they caused issues on Sandybridge-based Dell Latitude laptops. See: https://codeberg.org/libreboot/lbmk/issues/216 The issue was not reported elsewhere, including on the Haswell/Broadwell hardware where they are needed, but the build system could only build one version of GRUB. The older machines do not need xHCI patches, because they either do not have xHCI patches, or work (in GRUB) because they're in EHCI mode when running the payload. So, the problem is that we need the xHCI patches for GRUB on Haswell/Broadwell hardware, but the patches break Sandybridge hardware, and we only had the one build of GRUB. To mitigate this problem, the build system now supports building multiple revisions of GRUB, with different patches, and each given coreboot target can say which GRUB tree to use by setting this in target.cfg: grubtree="xhci" In the above example, the "xhci" tree would be used. Some generic GRUB config has been moved to config/data/grub/ and config/grub/ now looks like config/coreboot/ - also, the grub.cfg file (named "payload" in each tree) is copied to the GRUB source tree as ".config", then added to GRUB's memdisk in the same way, as grub.cfg. Several other design changes had to be made because of this: * grub.cfg in memdisk no longer automatically jumps to one in CBFS, but now shows a menuentry for it if available * Certain commands in script/trees are disabled for GRUB, such as *config make commands. * gnulib is now defined in config/submodule/grub/, instead of config/git/grub - and this mitigates an existing bug where downloading gnulib first would make grub no longer possible to download in lbmk. The coreboot option CONFIG_FINALIZE_USB_ROUTE_XHCI has been re-enabled on: Dell OptiPlex 9020 MT, Dell OptiPlex 9020 SFF, Lenovo ThinkPad T440p and Lenovo ThinkPad W541 - now USB should work again in GRUB. The GRUB payload has been re-enabled on HP EliteBook 820 G2. This change will enable per-board GRUB optimisation in the future. For example, we hardcode what partitions and LVMs GRUB scans because * is slow on ICH7-based machines, due to GRUB's design. On other machines, * is reasonably fast, for automatically enumerating the list of devices for boot. Use of * (and other wildcards) could enable our GRUB payload to automatically boot more distros, with minimal fuss. This can be done at a later date, in subsequent revisions. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: scan /boot/grub.cfg lastLeah Rowe
very unlikely to exist. in fact, should i remove it? Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: scan grub2/ lastLeah Rowe
it's very unlikely that someone would use this directory name nowadays, and i had half a mind to remove it altogether Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: search a reduced list of devs/partitionsLeah Rowe
in practise, the machines we support don't have the option of including so many disks; 8 seems like the most reasonable default. additionally, it's unreasonable to expect *20 partitions* this hardcoding is done to avoid using *, which is slow in grub on some machines (the grub kernel always re-enumerates the devices during every operation, without caching any of it) yet, the hardcoding is also slow; balance it a bit better by searching fewer permutations, but not so few that it would likely break a lot of setups Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: scan grub.cfg from ESPLeah Rowe
we already supported syslinux but not grub support grub by scanning for the most common paths, based on the most popular distros we don't hardcode this with * because it slows down the boot, and in practise many distros still use the same grub.cfg location as in BIOS systems (the EFI one is often just a link to the BIOS one) Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: split up try_user_configLeah Rowe
in the next revision, i will add ESP paths Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: don't search for *_grub.cfgLeah Rowe
this is a relic from the old days when we didn't automated the grub.cfg logic as much. these days, the grub.cfg logic is able to boot almost all distros without any manual intervention or override. removing these entries will speed up the boot in general Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: remove unnecessary path for isolinuxLeah Rowe
the path "/boot/EFI" is unnecessary because the ESP is always a FAT32 partition, so we don't need to scan it as a subdirectory within a subdirectory. the ESP is always mounted as its own partition, FAT32, and EFI/ is always at the root of it Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: don't scan EFI on btrfs subvolsLeah Rowe
the esp is always a fat32 partition so this makes no sensgrub.cfg: don't scan EFI on btrfs subvols the esp is always a fat32 partition so this makes no sense Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-28grub.cfg: actually support setting boot orderLeah Rowe
replace variables ahcidev/atadev/nvmedev with a single one named bootdev the for loop goes through grub_scan_disk, so now it is effectively a bootorder configuration Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27grub.cfg: add spdx headerLeah Rowe
it has always been gpl 3 or later, but it helps to have the license declaration within the file there's a copying file anyway. put spdx in the config Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27grub.cfg: use grub_scan_disk to set boot orderLeah Rowe
Previously, grub_scan_disk could set ata, ahci or "both", which would make both be tried (ahci first). This worked when we only dealt with ata and ahci devices, but now we support nvme devices so the logic is inherently flawed. Instead, use grub_scan_disk to store the boot order, e.g.: grub_scan_disk="ahci nvme ata" grub_scan_disk="nvme ata" In the first example, it would make GRUB scan ahci first, then nvme and then ata. In the secontd example, it would make GRUB scan nvme first, and then ata. If "both" is set, or anything other than ahci/ata/nvme, grub_scan_disk is now changed to "nvme ahci ata". Actual grub_scan_disk entries in target.cfg files will now be modified, to match each machine. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27GRUB: remove XHCI patches for now (will re-add)Leah Rowe
Fixes this bug: https://codeberg.org/libreboot/lbmk/issues/216 Well, fix is the wrong word. We want xHCI ideally. Mate is working on it as I write this. I've also: * Disabled CONFIG_FINALIZE_USB_ROUTE_XHCI on Haswell boards (coreboot) * Disabled the GRUB payload on HP 820 G2 for now We will need to re-add the xHCI patches once fixed. If Mate/we can't fix it, I'll contact Patrick Rudolph who originally wrote the xHCI patches. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-21Merge pull request 'Also try unlocking encrypted volume on NVMe' (#213) from ↵Leah Rowe
mkukri/lbmk:master into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/213
2024-05-21Also try unlocking encrypted volume on NVMeMate Kukri
2024-05-21Merge pull request 'Add NVMe support to GRUB2 payload' (#212) from ↵Leah Rowe
mkukri/lbmk:master into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/212
2024-05-20Add NVMe support to GRUB2 payloadMate Kukri
Tested on OptiPlex 3050 (via injecting grub2.elf into WIP coreboot port).
2024-05-18Add pt qwerty keymap to lbmksamuraikid
Signed-off-by: samuraikid <samuraikid@noreply.codeberg.org>
2024-05-04Libreboot 20240504 release20240504Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03Merge pull request 'Implemented failsafe options at boot and inside menus ↵Leah Rowe
for enabling/disabling serial, spkmodem and gfxterm' (#203) from livio/lbmk:failsafe into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/203
2024-05-02Merge pull request 'Fixed boot selection menu' (#204) from ↵Leah Rowe
livio/lbmk:livio_290424 into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/204
2024-05-01Fixed boot selection menulivio
2024-04-29Implemented failsafe options at boot and inside menus for enabling/disabling ↵livio
serial, spkmodem and gfxterm
2024-04-28build/roms: simplified seagrub handlingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-05grub xhci supportLeah Rowe
see: https://github.com/9elements/grub/commits/xhci-module-upstreaming-squash_v4/ grub only supports xhci on bios/uefi targets, but not coreboot. some newer machines don't have ps/2 controllers, and boot in a way where ehci isn't available at startup; the controller can't be used by ehci code, there must be xhci support. the code is from Patrick Rudolph working on behalf of 9elements. the code was also sent here for review: https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00111.html however, upstream never merged these patches. libreboot will have to maintain these from now on. the patches have been rebased for use with grub 2.12. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-02-25Libreboot 2024022520240225Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-26Libreboot 2024012620240126Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-21grub/target.cfg: move --disable-werrorLeah Rowe
i meant to push it in configure args, not bootstrap Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-21grub: use --disable-werror on ./configureLeah Rowe
work around build issues on very bleeding edge distros Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-18GRUB: insert only 1 keymap per board, in cbfsLeah Rowe
There is no need to add multiple keymap files, because GRUB can load keymaps from CBFS. The current build logic is designed to avoid building multiple GRUB binaries, which are expensive computationally because each one would then have to be compressed for each board. This patch provides the best of both worlds: less space used in flash like in the old lbmk design (1 keymap per board), but retaining the current build speeds and therefore not re-introducing the slowness of lbmk's previous GRUB build logic. The grub.cfg file has been modified, accordingly. It now only loads a keymap.gkb file from CBFS, by default. It does this, only if that file exists; if not, GRUB already defaults to US Qwerty layout anyway. ALSO: compress all keymap gkb files with xz -6 GRUB automatically decompresses files when accessed. This results in about 2KB of flash space saved in CBFS. Here is real-world data, showing the increased flash space: < fallback/payload 0x3eb80 simple elf 548821 none < keymap.cfg 0xc4bc0 raw 16 none < (empty) 0xc4c00 null 11633316 none --- > fallback/payload 0x3eb80 simple elf 546787 none > keymap.gkb 0xc43c0 raw 344 none > (empty) 0xc4540 null 11635044 none This was taken by diffing the cbfstool "print" output, both before and after. The *after* result is with this change. 11633316. In this example, 1728 bytes have been saved. Therefore, with compression taken into account, this patch saves about 1.7KB of space in CBFS. This change means that lbmk can now scale to support hundreds of keymaps, without increasing the amount of flash space used, in each given image. Since the keymap files are compressed in lbmk.git, in advance, we spend no additional time on compression at build time. The resulting change in build speed in negligible. Adding your own keymap.gkb file was already possible, for changing the keymap in libreboot images, if you didn't want to change the memdisk (and thus re-compile grub.elf). Now, this is the default behaviour, and the only way to do it. It's much more efficient. The original keymap files can be restored, by running unxz. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-30update/trees: support custom make/autogen argumentLeah Rowe
this is now used in grub, for the FS_PAYLOAD_MODULES option in the make command lbmk should generalise as much logic as possible. in some parts of it, logic is hurrently hardcoded, specific to a given project that lbmk uses, but lbmk is essentially a source-based package manager, like what you might find on a small linux distro, so we need to try to be as generic as possible. lbmk is the "build system of build systems", so it has to work generically with as many of them as possible Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-30update/trees: dont hardcode autoconf/bootstrap argLeah Rowe
at present, the bootstrap and configure script is only directly executed for grub, because grub is the only project that uses them in lbmk however, when i start adding linuxboot support, i will have to start building a lot of projects, some of which make use autoconf and bootstrap scripts e.g. ./bootstrap --foo ./configure --bar the "bootstrap" script is often used on GNU programs, because they like to over-engineer absolutely everything Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg syslinux: support scanning /boot/EFI/Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: fix pathLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: handle btrfs subvols for extlinux.confLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: scan extlinux/extlinux.confLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: support grub and extlinux on ata/ahciLeah Rowe
there are special menuentries just for loading configs, without handling luks, lvm and whatnot. it's intended for users of cd/dvd drives. well, now we support both extlinux and grub, with this patch. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: merge isolinux/grub usb menuentriesLeah Rowe
many modern distros use grub in their installer images, so scan for grub.cfg first. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: handle extlinux in the default menuentryLeah Rowe
isolinux/syslinux/extlinux config files should all work, using the syslinux parser function in grub the current behaviour is to only search for grub.cfg, so extlinux users can't use the default libreboot setup. with this change, their systems should hopefully work. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg syslinux: support ESP and extlinux.confLeah Rowe
the so-called EFI System Partition (ESP) is used on many UEFI-based setups. some users may be migrating to libreboot, so let's support it. on BIOS setups, it would be e.g. /boot/syslinux/syslinux.conf on UEFI setups, it would be e.g. /boot/EFI/syslinux/syslinux.conf additionally, support scanning for extlinux.conf Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: don't boot linux without a grub.cfgLeah Rowe
the fallback code in the main menuentry is potentially unsafe, depending on user config. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: scan lvm volumes lastLeah Rowe
lvm/* is slow to resolve in grub, on some machines, because grub enumeration is very slow in general. however, many people will install distros with any number of lvm configurations, so we should try to support them. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18Revert "grub.cfg: try luks2/crypto-lvm before non-crypto"Leah Rowe
This reverts commit 20389655e42e62ebf6d96dd106c91fbe74282557. If the user actually has encryption, but has /boot unencrypted, this will considerably slow down the boot, so the patch has been reverted. The patch was originally meant to favour encrypted /boot setups, but the old behaviour also still works there.